Hi Ate,
Thanks for your very detailed and positive feedbacks.
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
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
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.
>
>
> 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.
>
>
>
>> 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]
>
