In certain circumstances it may prove advantageous to have a grid service wizard as part of the phgrid software stack. For instance a PH entity may have analytical tool that they want to convert into an analytical grid service or a database that they want to convert into a data grid service.
Currently the easiest way to wrap an existing analytical tool in a grid service is to use the gRAVI extension to Introduce. In the case of phgrid many of of the fields for gRAVI/Introduce could be automatically assigned or taken a step further one may be able to make use of the gRAVI/Introduce API to make wrapping an existing analytical tool on phgrid an automated task.
Wrapping an existing DB into a grid service in a fairly automated way is more challenging than wrapping an existing analytical tool. In the case of a DB some sort of automated Object Relational Mapping (ORM) needs to take place and the two ORM tools I'm familiar with are caCORE and the Java Persistence API (JPA). caCORE works well with Introduce and is a reasonable way to create a DCQL based grid service while JPA can be used outside of a Java EE container it may require some effort to connect JPA to a data grid service. An experienced developer could probably make use of the caCORE and Introduce APIs to create a partially automated way for a health entity to wrap an existing data base into a data grid service.
The success of the ideas above depend on the maturity of the caCORE/Introduce/gRAVI APIs and there relevance.
Any thoughts?
Monday, March 16, 2009
Subscribe to:
Post Comments (Atom)
Posts
2 comments:
Thank you for this post - this issue really needs to be discussed.
Vaughn and I have had a few discussions about this type of capability. Basically really easy installation and deployment of services. As PHGrid grows up, this is going to be a required feature. If you look at what caBIG and EPA's Exchange Network have done, I think this is definitely possible.
Post a Comment