On Mon, May 21, 2012 at 12:10 AM, Ate Douma <[email protected]> wrote: > On 05/18/2012 07:03 PM, Carlucci, Tony wrote: > >> >> -----Original Message----- >>> From: Chris Geer [mailto:[email protected]] >>> Sent: Friday, May 18, 2012 12:29 PM >>> To: [email protected] >>> Subject: Re: [DISCUSS] Rave Architecture >>> >>> On Fri, May 18, 2012 at 8:34 AM, Franklin, Matthew B. >>> <[email protected]>wrote: >>> >>> -----Original Message----- >>>>> From: Chris Geer [mailto:[email protected]] >>>>> Sent: Friday, May 18, 2012 10:00 AM >>>>> To: dev >>>>> Subject: [DISCUSS] Rave Architecture >>>>> >>>>> I wanted to start a conversation regarding the long term architecture >>>>> of >>>>> Rave. I'm primarily interested in how Rave will ultimately be able to >>>>> be >>>>> deployed. >>>>> >>>> >>>> A while back Ate posted ~25 architectural topics[1] to start generating >>>> discussion around. As we go to build out a roadmap, we will need to >>>> make >>>> sure we expand on each of these. >>>> >>>> >>>>> Currently, as you know, Rave is built and deployed as a series of three >>>>> >>>> web >>>> >>>>> apps, ROOT (mostly Shindig), portal (main rave features) and wookie >>>>> (I'm >>>>> not counting demogadgets). This model has it's advantages since all you >>>>> have to do upgrade is replace a war file since it's all self contained. >>>>> However, this model also has some drawbacks. >>>>> >>>>> In a perfect world it would be great if Rave could support multiple >>>>> deployment models. My personal preference would be to see Rave be >>>>> >>>> able to >>> >>>> be deployed modularly in an OSGi container (Rave services advertised as >>>>> OSGi services, etc). This would give a lot of freedom for interacting >>>>> with >>>>> Rave programmatically, for scaling, for incremental upgrades and >>>>> >>>> supporting >>>> >>>>> plug-n-play services (JPA vs JCR for example). >>>>> In looking at the system it wouldn't be horribly difficult to convert >>>>> it >>>>> >>>> to >>>> >>>>> deploy modularly into an OSGI container but I also realize there are >>>>> going >>>>> to be people who want a standard WAR distribution. I didn't have any >>>>> brilliant ideas of how to structure things to support both as different >>>>> build options but I wanted to raise the idea anyway and see if others >>>>> had >>>>> any thoughts. Do others see a need to have a more modular deployment >>>>> model >>>>> in their use of Rave? Have there been other discussions around this >>>>> >>>> already? >>>> >>>> Hadrian was discussing OSGI enabling Rave at some point. I would >>>> recommend putting a detailed proposal in the architecture topics of the >>>> wiki and start getting some discussion around the specifics of how this >>>> would be accomplished. I am sure others will help refine it from >>>> there... >>>> >>>> >>> Before spending a lot of time putting together a detailed proposal I >>> guess >>> I was looking to gather some thoughts on what options people would like >>> to >>> support. That will greatly impact the detailed proposal. >>> >> >> I think there will still be a strong need for the full bundled wars, so >> whatever solution is developed should be able support that scenario. >> > Yes, I agree. > > But I also see and support the need for alternate and possibly more > 'pluggable' solutions. OSGi surely is one of them although personally I am > not much interested in it. > > But there are other alternatives as well. > > For us the Rave portal war as we have today merely is a 'demo'. > Embedding, integrating and merging the Rave portal *functionality* (and > more) within our own web application(s) stack is our goal instead of using > it 'standalone'. >
Exactly. > > In addition, we do have the need to provide pluggable and for some maybe > even runtime deployable components and services. But OSGi 'hot-deployment' > IMO is far less needed than propagated by some OSGi advocates, and for that > I'd prefer an easier and more light-weight solution which isn't so invasive > throughout the whole architecture. > > At any rate, OSGi support very well should be possible I think and has > been discussed before. > I've been researching this a bit and was looking at what Shindig does. They currently use Guice which you are right, isn't very OSGI friendly. However, there is the Peaberry project which supports Guice in an OSGI container and all you have to do is swap out the Binder Module files. That would allow us to lookup service reference either directory (Guice) or through the OSGI registry (Peaberry). > > Side note: AFAIK Shindig so far isn't very OSGi friendly although I know > some managed to wrap it in OSGi. > > Ate > > > >> Tony >> >> >>> >>> >>>> >>>>> Thanks, >>>>> Chris >>>>> >>>> >>>> [1] : >>>> http://wiki.apache.org/rave/**ArchitectureTopics<http://wiki.apache.org/rave/ArchitectureTopics> >>>> >>>> >
