Hi Devs,

Airavata trunk contains XML Schemas for HostDescription,
ApplicationDescription and ServiceDescription. XMLBeans is used to generate
POJOs out of those XML Schemas. Although these POJOs are generated,
according to current implementation, these are not used. Instead of using
them, some POJOs named HostDescription, ApplicationDeploymentDescription,
ServiceDescription are used. (A diagrammatic view of the class structure of
theses POJOs are displayed in the attached diagram. I did not draw a class
diagram for this. If it is required, I can send it later).

These were done to overcome some limitations in the current schema. The main
intention/s of this mail thread is to discuss how to improve the existing
Schema or improve the hand written POJOs to overcome the limitations.

A downside of this approach is that the XML Schema is not directly used
within the codebase. Therefore if the Schema changes we might have to change
the codebase. Bottom-line is that the POJOs are not in par with the XML
Schema.

I have attached a patch to the jira [1], in which HostDescription,
ApplicationDescription and ServiceDescription are improved to use the
generated XMLBeans.

Following are some questions that I have.
1) Although there are setters() and getters() in the above mentioned(see the
diagram) POJO classes, the setters are not used inside the Airavata codebase
(except in some test cases). Why is that?
2) If you have a look at the diagram; there are GlobusHostDescription,
ShellApplicationDeployment and GramApplicationDeployment. The XML Schema
definitions inside the GFac does not mention of these and has no elements to
support some attributes. So my question is, should we improve the existing
Schema to support these or keep the POJOs as it is?
3) As you might see there is a Parameter class and it is having a set of
subclasses (diagram). The schema does not mention of these. Should we
incorporate these to the Schema or keep them as it is?
4) In the ApplicationDeploymentDescription there are methods called
getInputDir(), getOutputDir(). Is it alright to assume the getWorkingDir()
will return a unix based file path or is that assumption incorrect?

Your feedback is appreciated.

[1] - https://issues.apache.org/jira/browse/AIRAVATA-105
[2] - https://issues.apache.org/jira/browse/AIRAVATA-106

-- 
Regards,
Heshan Suriyaarachchi

http://heshans.blogspot.com/

Reply via email to