For those of us following with interest this issue of service methodology, I'd be interested in more information such as:
- what is CPS
- what is IOC
- what is POJO.
- picocontainer?
- hivemind?
I'll probably start searching, but if you have a brief definition or link to more info I'd appreciate it.
Also, I'm real interested in Avalon Framework - has this been evaluated for a Service framework for jetspeed 2?
Thanks.
- Glenn
On Tuesday, September 23, 2003, at 03:22 PM, Weaver, Scott wrote:
-----Original Message----- From: David Le Strat [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 23, 2003 2:33 PM To: [EMAIL PROTECTED] Subject: J2 - Service Architecture Question
All,
I have been playing around with J2's code for a little while (though without Pluto it is a bit challenging ;o)). I am looking for the Jetspeed developers' advice on the 2 following topics:
- What is the recommended way to implement/expose services in J2? Is it the purpose of the CPS base services to provide a service framework for the rest of the application (will this eventually use Avalon?) or are plugins assuming this responsibility (see point below)?
CPS is the way to do it in the jetspeed 2 core. I talked to David yesterday and we are also going to evaluate picocontainer and Hivemind as possible replacements for Fulcrum, which is currently CPS' backbone. I really like the how picocontainer has simplified IOC and that all components are POJOs.
- What is the recommended way to use a persistence layer? I noticed that there is an OJB plugin. Should all persistance leverage the plugin to persist data through OJB? I read a little bit about the thrust architecture in Jetspeed. To which extent should plugins be used?
The whole idea behind the plugin was to allow developers to "plug in" their own persistence mechanisms. We used OJB because I have a lot of experience with it. I had thought about Hibernate, but it was LGPL. Plus, Matthew Baird of the OJB project has been a huge help with the more esoteric aspects of OJB. He uses Jetspeed in some of his projects and drops into the Jetspeed IRC from time to time.
For instance, should the underlaying profile management implementation be exposed as a plugin? Let's say EJB profile, JDO profile, LDAP profile, OJB profile and have a "universal" interface in front that assembles the plugins and manages the interaction with the various plugins?
Profile management should be exposed through a service or component. There should really be no need to touch persistence mechanism of the profile system.
Thanks for your input.
Regards,
David Le Strat.
__________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
*===================================* * Scott T Weaver * * Jakarta Jetspeed Portal Project * * [EMAIL PROTECTED] * *===================================*
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
