-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I agree with Ate's comments about embedding (and extending) Rave. This is what most of the use cases we have will require.
Marlon On 5/21/12 3:10 AM, Ate Douma 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'. > > 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. > > 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 >>>> -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPujEBAAoJEEfVXEODPFIDAvQH/RYpKpLEdBh2UBOq05u8t9cs lOxMW9cKFAJh9DMH1NJ2OAXRGaE2SRjiiZQ93lGqlK27svoJ5pD+Z01CusY5tJOX WbUrInS2CXA8/coXT7J1RvYoNkH9/NjT+/9L/5gBgguuAqb3Oed/QV3ph7urt1Ef Pjydhqo1Ohlmk3nbQjCTcct7fusc1Z/usW1e1SfSLgJnfad5uylomAsPRrbkQ7lT 6AgraO1lHg2bYy+tZhMsFL7RtZqmVJFzLaPeoBSRJJyhP2eweYM3Gwf/PmPjs363 ppaBWxFdyskzfmQBCgWvJn1uXfJQ18U/AY4baVDE1pPVy2HOtH38p1lrkiAoj78= =rebq -----END PGP SIGNATURE-----
