Hi Heshan, On Wed, Aug 31, 2011 at 9:39 AM, Heshan Suriyaarachchi < [email protected]> wrote:
> Hi All, > > First of all I will explain what I initially started doing. I was going to > parse the XML Schema using Axiom and extract the important information from > the schema. Then a template will be created with the use of JET[1]. When > generating POJOs the extracted information from the XML Schema will be > inserted to the generated class. > > While working on the above implementation I came across some concerns. > i) The initial objective of doing this was to create the POJO object from > the XML Schema and the current POJOs that GFac is using does not contain > all > the information in the XML Schema. eg. Consider the schema > HostDescription[2] and the POJO for the HostDescription[3]. > > ii) Since we are extracting only some elements from the schema, we need to > know what elements that we are going to extract. > > iii) The code generation will be based on the template that we create. So > if > the Schema is changed or some additional property should be added to the > POJO, then the template should be updated. Therefore, the code generation > will not be that dynamic. So, the concern that I am having is that if we > are > to move ahead in this path, why go through the pain of generating > templates, > just to modify them down the line. It’s better off to write the POJO by > hand. I think we are trying to introduce unnecessary complexity in this > approach. Please correct me if I am wrong. > I am +1 for this approach, I do not think the schema will change very often so in general we will not having to change the templates often. Somehow we need to switch to the correct approach of actually using gfac-schema and get rid of manually written POJOs. I think this approach is having less complexity. Regards Lahiru > > iv) One other suggestion is, instead of having manually written POJO > classes > written for the Schema, why not use the POJOs created by XMLBeans? May be > there was a decision taken to move ahead with that approach. I would > appreciate if someone can shed some light into it. > > Following are some other observations: > > XML Beans > According to the current gfac-schema module, XML Beans is used to generate > the POJO objects from the GFac XML Schema. I went through the generated > classes and did not find a way to extract the list of properties stored in > a > particular POJO. It’s only exposing methods to get or set values certain > properties. Since we can not extract the list of properties, it’ll be > difficult to generate a class from it because I need those information to > be > inserted into the template. > > XJC (JaxB) > I tried out XJC as well. It’s also generating some POJOs as XML Beans. I > came across some issues while generating POJOs for Schema’s which is having > imports. The approach to overcome that was to go ahead with XML Catalogs. > Inorder to do that I had to modify the Schema. I did not want to modify the > Schema and I stopped it there. > > Axis2Code generator > As you might know Axis2Code generator too, uses it’s WSDL to Java tool to > generate Java code. One other option is to look into whether we can use > that > in here. According to my initial understanding, it will take sometime to > understand that code base and try to extract the logic that we want. > Furthermore, we might have to write XSLTs to generate the code as well. > > Your feedback is much appreciated. > > [1] - http://www.eclipse.org/modeling/m2t/?project=jet#jet > [2] - > > https://svn.apache.org/repos/asf/incubator/airavata/trunk/modules/commons/gfac-schema/schemas/HostDescription.xsd > [3] - > > https://svn.apache.org/repos/asf/incubator/airavata/trunk/modules/commons/gfac-schema/src/main/java/org/apache/airavata/core/gfac/type/HostDescription.java > > > On Mon, Aug 29, 2011 at 3:57 PM, Heshan Suriyaarachchi < > [email protected]> wrote: > > > Hi Raminder, > > > > I have not used JAXB before. I will invest some time and look into JAXB > as > > well. > > > > Thanks for the suggestion. > > > > On Mon, Aug 29, 2011 at 3:29 PM, Raminderjeet Singh < > > [email protected]> wrote: > > > >> I will still recommend to look into JAXB or some library which can > handle > >> complex types of XSD. POJO's generated using JAXB was simple enough and > its > >> easy to parse the request also. > >> > >> Here is a simple schema i am working with and generated POJO's but this > is > >> very simple one > >> > >> > >> > https://ogce.svn.sourceforge.net/svnroot/ogce/gateway-staging/ultrascan/US3RestServices/schema/GfacMessage.xsd > >> > >> > https://ogce.svn.sourceforge.net/svnroot/ogce/gateway-staging/ultrascan/US3RestServices/src/main/java/org/ogce/gram/job/message/ > >> > >> > >> Thanks > >> Raminder > >> > >> On Aug 29, 2011, at 3:18 PM, Heshan Suriyaarachchi wrote: > >> > >> > Hi Raminder. > >> > > >> > Thanks for the feedback. > >> > > >> > In fact in the current GFac Schema implementation; XMLBeans is used to > >> > generate java objects from the XML Schema. This is done using > >> > xmlbeans-maven-plugin. The main reason for opting for writing > something > >> > custom was that the generated POJO classes are complex and hard to > work > >> > with. The generated POJO should look something like [1]. > >> > > >> > [1] - > >> > > >> > https://svn.apache.org/repos/asf/incubator/airavata/trunk/modules/commons/gfac-schema/src/main/java/org/apache/airavata/core/gfac/type/ApplicationDeploymentDescription.java > >> > > >> > On Mon, Aug 29, 2011 at 3:04 PM, Raminderjeet Singh < > >> > [email protected]> wrote: > >> > > >> >> Heshan, > >> >> > >> >> You can look into JAXB[1] where you can use some thing like below to > >> >> convert the schema to POJO. I have not tried this with hierarchical > >> XSD's or > >> >> XSD with extension which will be good thing to explore > >> >> > >> >> xjc schema/GfacMessage.xsd -p org.xxx.message -d src/main/java/ > >> >> > >> >> Thanks > >> >> Raminder > >> >> > >> >> [1] : > >> >> > >> > http://download.oracle.com/docs/cd/E17802_01/webservices/webservices/docs/1.6/jaxb/xjc.html > >> >> > >> >> On Aug 29, 2011, at 2:12 PM, Heshan Suriyaarachchi wrote: > >> >> > >> >>> Hi Devs, > >> >>> > >> >>> Please see my inline comments. > >> >>> > >> >>> On Sun, Aug 28, 2011 at 9:30 AM, Suresh Marru <[email protected]> > >> wrote: > >> >>> > >> >>>> Hi All, > >> >>>> > >> >>>> Looking through the JIRA tickets I see we have addressed some of > the > >> >> issues > >> >>>> mentioned below and working on few others. Once we capture current > >> >> status, > >> >>>> as Alek mentioned, lets clearly layout a roadmap for this release > and > >> >> also > >> >>>> for the graduation. Please add/modify to the list. > >> >>>> > >> >>>> On Jul 31, 2011, at 11:37 PM, Suresh Marru wrote: > >> >>>> > >> >>>>> Great to see all the progress in the last few weeks. As I see it, > >> here > >> >>>> is a recap here are the next steps before a release: > >> >>>>> > >> >>>>> * Standardize WS Messenger clients and integrate the axis2 ported > >> >> clients > >> >>>> to XBaya and GFac. > >> >>>> --Seems like mostly done, but I think we still need to integrate > and > >> >> test > >> >>>> this with rest of Airavata. Some TODO's as I see it: > >> >>>> • Verify and test Tracking Library > >> >>>> • Provide notification Publish, Subscribe with tracking > schema. > >> >>>> • Change XBaya to use new tracking schema > >> >>>> • Add notification to Gfac using new tracking schema > >> >>>> • create a notification interface inGFac with Tracking as one > of > >> >> the > >> >>>> implementation (if gfac is used outside workflow context) > >> >>>>> * Discuss, standardize and update GFac application and service > >> >>>> deployment description schema. > >> >>>> * The POJO schema is good for current development, but as per > >> the > >> >>>> discussion in mailing list, we still need to have XML schemas. May > be > >> we > >> >> can > >> >>>> write utility classes to convert from xml schema to POJO? > >> >>>> > >> >>> > >> >>> I would like to work on Converting XML Schema of GFac to POJO. In > >> fact, I > >> >>> have already started working on this. > >> >>> > >> >>> Currently we have XML Schema defined in the GFac-Schema. The idea > here > >> is > >> >> to > >> >>> create POJO's from the above XML Schema. Currently the POJO which we > >> are > >> >>> using are not generated. ie. these POJOs are not generated > dynamically > >> >> from > >> >>> the XML Schema. > >> >>> > >> >>> Following is the way in which I am going to move ahead with the > >> >>> developement. > >> >>> > >> >>> I will write a parser to parse the Schema and extract the arguments > >> >> needed > >> >>> to create the POJO. Then with the use of JET [1] I will be > generating > >> the > >> >>> POJOs. > >> >>> > >> >>> [1] - http://www.eclipse.org/modeling/m2t/?project=jet#jet > >> >>> > >> >>>> * Integrate Axis2 based service interface to GFac-Core > >> >>>> * I see the basic axis2 interface is done and tested with SOAP > >> UI. > >> >>>> But I think we we still need to test with XBaya. > >> >>>> > >> >>>>> * Upgrade XBaya WSIF clients from XSUL to Axis2 based WSIF > clients. > >> >>>> * I think XSUL WSIF clients are working well, may be we can > >> defer > >> >>>> AXIS2 clients for future? > >> >>>>> * Upgrade GSI Security libraries > >> >>>> * I think we should focus on the integrated all moving > >> components > >> >> of > >> >>>> Airavata and defer any individual component upgrades. > >> >>>>> * Provide simple to use samples to try out Airavata. > >> >>>> * We need to provide lot of samples and associated > documentation > >> >>>>> * Package, document and release airavata incubating release v 0.1 > >> >>>> * The builds have evolved, but we still need to have one click > >> >>>> integrated build and deploy > >> >>>> * The weakest point I think is documentation, once we get a > >> >> feature > >> >>>> freeze, should we pause development and run a sprint of > >> documentation? > >> >>>> > >> >>>> Thanks, > >> >>>> Suresh > >> >>>> > >> >>>>> > >> >>>>> Please correct/update to the list. > >> >>>>> > >> >>>>> Cheers, > >> >>>>> Suresh > >> >>>>> > >> >>>>> On May 13, 2011, at 8:37 AM, Suresh Marru wrote: > >> >>>>> > >> >>>>>> Hi All, > >> >>>>>> > >> >>>>>> All of us clearly know what Airavata software is about in varying > >> >>>> details, but at the same time I realize not every one of us on the > >> list > >> >>>> have a full understanding of the architecture as a whole and > >> >> sub-components. > >> >>>> Along with inheriting the code donation, I suggest we focus on > >> bringing > >> >>>> every one to speed by means of high level and low level > architecture > >> >>>> diagrams. I will start a detailed email thread about this task. In > >> >> short, > >> >>>> currently the software assumes understanding of e-Science in > general > >> and > >> >>>> some details of Grid Computing. Our first focus should be to bring > >> the > >> >>>> software to a level any java developer can understand and > contribute. > >> >> Next > >> >>>> the focus can be to make it easy for novice users. > >> >>>>>> > >> >>>>>> I thought a good place to start might be to list out the high > level > >> >>>> goals and then focus on the first goal with detailed JIRA tasks. I > am > >> >>>> assuming you will steer us with a orthogonal roadmap to graduation. > I > >> >> hope I > >> >>>> am not implying we need to meet the following goals to graduate, > >> because > >> >>>> some of them are very open ended. Also, please note that Airavata > may > >> >> have > >> >>>> some of these features already, I am mainly categorizing so we will > >> have > >> >> a > >> >>>> focused effort in testing, re-writing or new implementations. > >> >>>>>> > >> >>>>>> Airavata high level feature list: > >> >>>>>> > >> >>>>>> Phase 1: Construct, Execute and monitor workflows from > pre-deployed > >> >> web > >> >>>> services. The workflow enactment engine will be the inherent > Airavata > >> >>>> Workflow Interpreter. Register command line applications as web > >> >> services, > >> >>>> construct and execute workflows with these application services. > The > >> >>>> applications may run locally, on Grid enabled resources or by > ssh'ing > >> to > >> >> a > >> >>>> remote resource. The client to test this phase workflows can be > >> Airavata > >> >>>> Workflow Client (XBaya) running as a desktop application. > >> >>>>>> > >> >>>>>> Phase 2: Execute all of phase 1 workflows on Apache ODE engine by > >> >>>> generating and deploying BPEL. Develop and deploy gadget interfaces > >> to > >> >>>> Apache Rave container to support application registration, workflow > >> >>>> submission and monitoring components. Support applications running > on > >> >>>> virtual machine images to be deployed to Amazon EC2, EUCALYPTUS and > >> >> similar > >> >>>> infrastructure-as-a-service cloud deployments. > >> >>>>>> > >> >>>>>> Phase 3: Expand the compute resources to Elastic Map Reduce and > >> >> Hadoop > >> >>>> based executions. Focus on the data and metadata catalog > integration > >> >> like > >> >>>> Apache OODT. > >> >>>>>> > >> >>>>>> I will stop here, to allow us to discuss the same. Once we narrow > >> down > >> >>>> on the high level phase 1 goals, I will start a detailed discussion > >> on > >> >> where > >> >>>> the code is now and the steps to get to goal1. > >> >>>>>> > >> >>>>>> Comments, Barbs? > >> >>>>>> > >> >>>>>> Suresh > >> >>>>> > >> >>>> > >> >>>> > >> >>> > >> >>> > >> >>> -- > >> >>> Regards, > >> >>> Heshan Suriyaarachchi > >> >>> > >> >>> http://heshans.blogspot.com/ > >> >> > >> >> > >> > > >> > > >> > -- > >> > Regards, > >> > Heshan Suriyaarachchi > >> > > >> > http://heshans.blogspot.com/ > >> > >> > > > > > > -- > > Regards, > > Heshan Suriyaarachchi > > > > http://heshans.blogspot.com/ > > > > > > -- > Regards, > Heshan Suriyaarachchi > > http://heshans.blogspot.com/ > -- System Analyst Programmer PTI Lab Indiana University
