Hi Matthew, Thanks for your comments.
I'm glad that the feature about MongoDB persistence is in the shorter-term roadmap of Rave. Today I had some more time to continue the research about the most optimal (longer-term) integration strategy with Apache Rave. I really don't like such approaches as HMVC or other tightly coupled integrations. Because they will definitely lead to maintenance nightmare in the future... even for the first upgrade to the next release of Rave. And also the current implementation of Rave will need to go through major reworks to support such tight integrations and customizations. I would rather let Rave stay more focused on its key features than applying some large efforts to make it a universally pluggable library for anything. For my case I'm thinking about the following architecture: 1. Deploy Rave as a separate web app 2. Use proxy-style integration using Databinder Dispatch code running in another web app (Lift app for my case), which will render Rave dashboard in a separate <div> on its web page. With Lift this is done with the regular bind() method in a snippet, which will map Lift's HTML tag to the invocation of Dispatch proxy code. 3. For sure, JavaScript of Rave dashboard will invoke REST API of Rave server directly, no proxying. 4. Setup SSO infrastructure for authentication and identity federation across Lift web app and Rave - Apache Shiro seems to be a good option here. 5. Minor updates in Rave Portal to work with Shiro (already used now for Rave-Shindig integration) + removals of the unnecessary JSP and UI parts to keep the dashboard only, I've done this one already. Benefits of this approach: 1. Easy long-term maintenance - no tight coupling with the internals of Rave, painless upgrade process. 2. Pluggable and flexible architecture: - Rave dashboard can be embedded into any required UI part with <div> - Good separation between the roles of Rave and other web apps - on all levels: data, services, UI - Straightforward customization options - Several Rave instances per single web app are possible I'm not 100% sure whether all pieces will fit together on practice, but I hope that these midnight fantasies are not too far away from the reality :-) Regards, Oleg On Wed, Apr 4, 2012 at 4:47 AM, Franklin, Matthew B. <[email protected]>wrote: > On 4/1/12 6:37 PM, "Oleg Puzanov" <[email protected]> wrote: > > >Hi Ate, > > > >Thanks for your very detailed and positive feedbacks. > > I want to echo Ate's thanks for your feedback. We definitely want to > support your use case and the suggestions/feedback you have provided are > important to consider as we work toward our goal of being flexible & > customizable. I have some additional comments inline. > > > > >I've added some comments inline below. Plus some other ones here. > > > >For now I've come up with the following phase #1 integration plan - around > >3 man-weeks of effort: > > > >1. Target approach for UI construction: > > > > - Master Page - rendered by Lift > > - Widget Dashboard area - included into Master Page, rendered by Rave, > > placed into <iframe> > > - Widget Contents (actual app UI) - rendered again by Lift > > > >2. Integration approach: > > > > - Rave is used as a rending engine for Dashboard area only, everything > > else is handled by Lift, including "Widget Store" functionality. > > - Rave and Lift are running as separate server instances - no such > > things as HMVC to present Lift and Rave as a single web application, at > > least for now. > > - Slightly modified default JPA implementation of Repository interfaces > > - Separate PostgreSQL instance to be introduced for Portal UI > > configuration data - pages, layouts, regions, widgets etc. > > - MongoDB to be used for the actual data of applications / gadgets > > > >3. Important refactoring for better layering and module separation in > >Rave: > > > > - Better separation between "rave-core" and "rave-web" modules - some > > parts are specific to the demo web application and should not be > >present in > > "rave-core". For example: Person and Address classes. > > - Repository interfaces and their usage to be aligned across all Rave > > modules > > - JavaScript changes - the same here: core and demo app parts should be > > Separated > > All good points > > > > >For now I see the following modules in Rave and their roles: > > > > - Portal Rendering Engine: > > - Page Container - JavaScript libraries to draw the widget > >dashboards > > - Portal Builder - invokes Portal Configuration Repository to build > > the portal pages > > - Widget Container - dialog to draw the actual widget contents and > > toolbars with minimize, maximize, delete buttons > > - Portal Configuration Repository - data model and persistence for > > pages, layouts, regions, widgets etc. > > - Widget Providers Framework - integrations with Shindig and Wookie > > - Demo portal application - current web app bundled with Rave > > Distribution > > We are going to start some heavier discussions soon on the dev list > regarding architectural decisions (project organization being one of > them). You are more than welcome to join in, if you like. > > > > >Portal Rendering Engine and Portal Configuration Repository will be the > >default integration points for 3rd-party web applications. Demo portal > >parts should be kept separately for not messing with the core sources. > > > >Regards, > >Oleg > > > > > >On Sun, Apr 1, 2012 at 5:34 PM, Ate Douma <[email protected]> wrote: > > > >> On 03/31/2012 11:25 PM, Oleg Puzanov wrote: > >> > >>> Hi all, > >>> > >>> After playing with Rave for ~1 week I would like to provide some > >>>feedbacks > >>> and questions, which may become mutually useful. > >>> > >> > >> Thanks Oleg, valuable feedback it is! > >> > >> Comments below. > >> > >> > >>> My goal - to integrate "portal like" behavior for the existing Lift web > >>> application, which is written in Scala. Some features are presented as > >>> OpenSocial gadgets, which have the following primary use cases: > >>> > >>> - Gadget Dashboard - main screen where the gadgets are presented, > >>> > >>> dragged all around, minimized, maximized etc. > >>> - Gadget Repository - list of gadgets, which are available for > >>> > >>> installation / usage > >>> > >>> Gadgets will consume the available REST API from Lift app + some of > >>>them > >>> will have more real-time UI behavior (e.g. Activity Feed), so Comet > >>> support > >>> in Lift will be utilized heavily. > >>> > >>> High-level view on the original Lift application stack: > >>> > >>> - HTML, CSS, JS > >>> - Lift snippets for UI logic > >>> - Service layer - thin wrapper API over MongoDB and Redis, which is > >>> > >>> implemented with Typed Actors of Akka framework > >>> - MongoDB for application data > >>> - Redis instances - one for cache, one for message queue > >>> > >>> > >>> I don't want to cover all details of the target architecture here, I > >>>just > >>> want to mention the key points and problems: > >>> > >>> 1. What I tentatively plan to drop from Rave: > >>> > >>> - All JSP files and SpringMVC sources - HTML and Lift snippets to be > >>> > >>> used instead. But it looks like an effort of several weeks... > >>> - All JPA implementations for Repository interface of Rave - > >>>MongoDB to > >>> > >>> be used via service layer API > >>> - Domain model classes from Rave Core - JPA entities won't be used > >>>here > >>> - Service implementation classes from Rave Core > >>> > >>> > >>> 2. What I tentatively plan to keep and to customize: > >>> > >>> - JavaScript files - to be modified for a new domain model > >>> - Some code and interface classes from Rave Core and all interfaces > >>>for > >>> > >>> Shinding and Wookie integrations. But I have one big question > >>>here... > >>> - Spring core - to be used for binding interfaces to implementations > >>> > >>> > >>> So the main problem is - all repository interfaces and model classes > >>>are > >>> directly dependent upon JPA. Is this a temporary issue or an original > >>> design? > >>> > >> That is a temporary issue. When we started with Rave last year the first > >> goal was to get something quickly working. JPA was chosen as persistence > >> layer at that time, but then we already recognized this would need > >> revisiting later when to support other persistence layers over time. > >> I think that time has come, not just (only) for your questioning about > >>it, > >> but because we're starting to introduce other persistence layers and > >> engines pretty soon. One of those is adding JCR based content > >>integration, > >> but others will come up pretty quickly as well. I know of at least one > >> participant in Rave who wants to add support for MongoDB as well... > >> > > > > > >> [Oleg] JCR is a brilliant idea. It will enable a data-driven portal UI, > >> which can be built with any JCR-compliant CMS. The only major concern > >>here > >> - performance and scalability of JCR. For enterprise-scale deployments > >>of > >> Rave it may be suitable. But for web-scale deployments of Rave with > >> millions of users and billions of data records it may become a real > >> bottleneck. MongoDB based Repository is a better option for such needs. > > I am working on a MongoDB persistence layer that I would like to have in a > working state by June. > > >> > > > > > >> > >> Logically, if there is a separation between interfaces and > >>> implementations, then JPA implementations should encapsulate all > >>> JPA-depedendent code. And interfaces should deal with neutral POJO > >>>classes > >>> only. Right? The same for model classes... > >>> > >> Yes. That will require some major abstraction work to be done in the > >>Rave > >> core. > > Major, but doable. > > >> > >> > >> > >>> Global question - what is the current roadmap for customization > >>>features > >>> of > >>> Apache Rave? Will it allow a quick and painless integration of the > >>> customized data models and 3rd-party data providers? > >>> > >> There is no exact roadmap (yet) on this, other than it a fundamental > >>goal > >> for Rave to support such customizations. So in general I'd say: yes. > >> Concretely this has to be fleshed out yet. > >> > >> > >> The same question > >>> about MongoDB integration. > >>> > >> See also above, support for MongoDB, and others, is in scope. > >> > >> > >> > >>> As I see this problem - every portal will need to have its own > >>>customized > >>> UI, data model and legacy integrations. On the side of UI > >>>customizations > >>> Apache Rave is almost acceptable, moving to the right direction. > >>> > >> Thanks :) > >> > >> Note though, even on the UI customizations layer I think there is much > >> more needed. For one thing (and I think you've pointed that out above > >>too), > >> the current 'plain' Spring MVC solution doesn't scale well IMO. > >> > >> Right now the Spring Controllers are strictly tied to a specific view as > >> well as fixed/annotation driven request mapping. Re-usability and > >> customization is hampered because of that (assuming you'd want to use > >> Spring MVC at all). > >> > >> Part of a proposal I recently made, http://t.co/lbwHngXQ , is to > >> introduce a better separation of concerns for this by adding HMVC > >>support, > >> where the request mapping resolves in a hierarchical (abstract) view > >> *structure* which then drives the processing of one or more > >>(hierarchical) > >> controllers and resulting in an aggregated resulting response (view). > >>The > >> (Spring) Controllers then become reusable components which can be > >> 'assembled' and 'injected' in truly customizable front-end usage. > >> > >> This might look a bit like how Lift or Wicket use *html* templates to > >>wire > >> components to a page, but my goal is to separate the page > >>model/structure > >> from the actual view rendering itself. Lift, Play, Wicket, as well as > >> Spring MVC, etc. are IMO too narrow-scoped web frameworks in this > >>respect... > >> > >> Anyway, this is something we'll start working on shortly, and might not > >> directly fit your interest (yet), but I thought it good to mention :) > >> > >> [Oleg] I've read through this e-mail thread about JCR and HMVC > >suggestions. Both of them are very interesting and correct approaches. > >Especially the view on integrating Spring MVC controllers and other > >frameworks like Lift or Play. It will be also very useful to architect the > >integrations when Rave is a child web app, which is hosted in a parent web > >app - like my case about Lift app. I think that such cases will be more > >frequent than having Rave as a parent web app. > > > > > > > >> Customization of Data Access Layer and Service Layer to fit into the > >>new > >>> domain model is very very hard. Looks like a complete rewrite from > >>> scratch... > >>> > >> It most certainly will require a higher abstraction layer within Rave, > >>but > >> we're pretty agile :) > >> A complete rewrite from scratch however is definitely not the goal. > >> Rave does have some general goals, an out-of-the-box usable > >> front-end/portal being one of them. That goal stands and a lot of people > >> are already building on top of it. So, while I expect some large > >>internal > >> changes coming up, we do intend for these to be gradual and incremental > >>as > >> much as possible, and if needed provide some way of migrating to a newer > >> architectural infrastructure. > >> But we are certainly not ready to declare our current stack 'stable', so > >> not ready yet for an Apache Rave v1.0 release either. > >> > >> > >> > >>> For now I'm in the middle between these two options: > >>> > >>> 1. To apply heavy customizations to Rave > >>> 2. To use Shindig directly and to implement the logic for presentation > >>>and > >>> management of OpenSocial gadgets from scratch > >>> > >>> Bottom line - what will you suggest by default? Considering my above > >>> inputs. > >>> > >> My suggestion is to go for option 1 and work with us to see how we can > >> accommodate your customization requirements. Contributions in this > >>respect > >> will be very much appreciated. > >> As I said above: customization support is a primary goal for Rave so > >>we're > >> eager to hear about and, if feasible, accommodate other requirements and > >> use-cases. > >> > > > > [Oleg] Yes, this is what I'm trying to do now - option #1. And overall > >it looks like the integration effort is not that much tremendous. For > >sure, > >using <iframe> for Gadget Dashboard is not that kind of integration, which > >will cover 100% of requirements. But it will be more than fine for phase > >#1. > > > > > > > >> How far we can accommodate your requirements I can't say upfront, and > >> support for our current core technologies like JPA and Spring MVC are > >> definitely here to stay, but need not be a per-requisite for using > >>Apache > >> Rave. > >> > >> > >>> Thanks a lot in advance. And sorry for all these critics - I'm just > >>>trying > >>> to be practical here. > >>> > >> Thanks a lot for that. I prefer pragmatism any time, and your critics > >>are > >> welcome as well. We're very open to discuss them and see how we can > >>solve > >> it. > >> > >> Regards, Ate > >> > >> > >>> Regards, > >>> Oleg > >>> > >>> > >> [1] > >> > >
