> -----Original Message----- > From: Todd Kuebler [mailto:[EMAIL PROTECTED] > Sent: Thursday, September 11, 2003 4:36 PM > To: Jetspeed Developers List > Subject: RE: JAXR for xreg registries? > > > Cool, happy to hear about J2 registries going to rdbms, although I hope > there is some abstract service registry layer on top of the implementation > so it isn't so tied directly to a particular technology or schema. >
There is a registry service abstraction layer and we even have some JMX stuff that interacts with the registry. The registry service relies on what we currently call a "persistence plugin" that is currently a layer over OJB but could be replaced with anything, like Hibernate or even a non-RDBMS persistence mechanism. All it would have to do is properly implement the PersistencePlugin interface. BTW, you can get the current persistence plugin framework to work entirely standalone, it sits under the J2 development tree. In fact David (Taylor) is currently using it within one of his J1 projects. The nice thing about the persistence plugins is that you can have more then one configured and running side by side. So if Jetspeed 2 uses OJB behind a persistence plugin you could still use your own plugin using whatever persistence mechanism for your applications. > JAXR comes in more in the service discovery scenario, which is actually > what I was thinking about, ie discovering local/remote content in > portlets/webservices/rss/etc. I really see the portal as both a consumer > and producer (individual portlet xml, wsrp,etc) of network services (ok, > web services, but I hate that) of all types and was thinking about where > JAXR/xml registries/xml repositories fit in that capacity. > This is a very, very cool idea. However, I see it a more of "nice to have" then a "needed to work" option. A formal proposal on something like this would be nice to have, so it doesn't get lost in the shuffle. > I was thinking of an abstract service layer that can deal with all of > those > service types and map them smoothly in/out of portlets. One of our teams > has something like this we are considering for use here at work, once that > is more tangible I'll try to communicate it again here. > > Sorry for my vagueness and poor communication skills. :( > > Here is something more concrete and less muddled purhaps. > > Imagine the following startup scenario for the portion of jetspeed code > that currently loads the portlet registries. > > 1) ask the service registry for all content producers available to this > portal (JAXR query). > 2) service registry returns 3 nodes > a) local portlets (what is in xreg currently, could still be > stored locally...) > b) remote portlets from portal B this portal has permission to > use > c) web services that have compatible data types for some generic > web services portlet (similar to the current dbbrowser > portlet) > 3) these are all merged into the 'service registry' and portlets are > created for each entry to produce the content > > > -tk *===================================* * Scott T Weaver * * Jakarta Jetspeed Portal Project * * [EMAIL PROTECTED] * *===================================*
