Hi Heshan,
I will try to answer your question. I don't quite get what you mean by
"improve Schema or keep POJO as it is" (in 2,3).
Does it means "to improve XML Schema with a different approach to solve the
problem" or "to improve XML Schema to generated a class as POJO is" ?
However, If we use XML schema, we should not maintain POJOs anymore (we will
use Class which is generated from XMLBean only).
1) Right now, there is no other way to create these descriptions (Host,
Application, Service) except by coding, which is the current test case.
Ideally, these descriptions will created and inserted into "Repository" from
users via some GUI (Swing XBaya, web base, etc.). GFac will loaded these
descriptions from "Repository" and used it to execute application.
2) I think we should extend XML Schema to support those attributes. Either
building a new solution or generating a exact POJO is fine.
The problem, POJO tries to solve here, is we need to determine how to choose
a correct "Provider" to execute an application. Ideally, Gfac uses object
type to decide what and how to do with the service. For example, If actual
type of ApplicationDeploymentDescription is ShellApplicationDeployment, it
will use LocalProvider to execute job on localhost or SSHProvider to execute
job on a remote host. If it is GramApplicationDeployment, it will use
GramProvider to submit a job to a Gram Endpoint.
3) This one is a bigger problem. Right now, Parameter Class is used as
"Actual" Input and Output Definition to GFAC-Service. For example, if we
have a integer array type as input and output, from the POJO, we will
have *IntegerArrayParameter
*Class. This object will be constructed and passed as an input to
GFac-Service. Ideally, user give an input via GUI as a string e.g.
[1,3,4,5,8,10] or (1,2,3,4,5), this input is parsed and converted to *
IntegerArrayParameter* by a method defined in
*IntegerArrayParameter*itself. With the same problem, we also need to
consider how to convert the
output from application package (scientific application) to Java Object, so
that it can be used in GFac. There are many points in the execution flow
where a string and java object is converted back and forth (Serialization).
I think that XML scheme has "pattern" attribute but I don't know if it fits
in this model.
4) I'm not sure. If we want, we can add "OS" as an attribute to Host
Description or we can cut out support for Windows. However, if you change
all data in a test case in GFac-Core (*PropertiesBasedServiceImplTest*) to
Windows format. If your machine running a test case is Windows, It will
work (because Java Class is used to launch a process and it supports
Windows).
For example,
setExecutable("c:\\windows\\echo.bat")
setTmpDir("c:\\temp")
setWorkingDir("c:\\user\\a")
setInputDir("c:\\user\\a\\mydocument\\input")
setOutputDir("c:\\user\\a\\mydocument\\output")
On Mon, Sep 19, 2011 at 10:09 AM, Heshan Suriyaarachchi <
[email protected]> wrote:
> 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/
>
--
Best Regards,
Patanachai Tangchaisin
