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/
