>-----Original Message----- >From: Oleg Puzanov [mailto:[email protected]] >Sent: Wednesday, April 04, 2012 6:19 PM >To: [email protected] >Subject: Re: Customization options: data model, service layer and UI > >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 :-)
At first blush, it seems like this strategy should work. Please let us know how it goes! > >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] >> >> >> >>
