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/
