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/
