Dear Rave developers, Ive just discovered the Rave project a week ago and therefore have not yet fully understood all of its concepts and decisions, but Im currently preparing a project, where Rave could be very helpful and wanted some suggestions on how to proceed there.
Im replying to the Rave on MySQL thread since my questions are related to the JPA or not discussion. Our project involves developing a social media hub/portal for an intranet scenario and our plan was to build on Shindig. Since it is a research project (not rocket science, just application-oriented research) we are planning on using OpenSocial 2.0 as the API between our portal and the other applications involved (DMS, Groupware, ERP system) and using a graph database (neo4j) as a data backend in order to offer extended functionality like friend suggestion and friend-of-a-friend queries on the portal. Now that we have discovered Rave, we obviously wanted to make use of it, although some things could be done more simple in our intranet scenario (e.g. permissions for gadgets). My main question is regarding the data abstraction layer. We have developed a draft Shindig backend for evaluation purposes that works with neo4j and already has some additional functionality compared to the Shindig JPA backend. Now we tried to make Rave work together with our Shindig version and found out, that it kind of works, mainly because it is often using its own database abstraction and for me it is not clear why. For example there is rave.portal.model.Person which uses JPA to store a (incomplete compared to OpenSocial 2.0 specs) person object in the database using JPA and there is shindig.social.opensocial.jpa.PersonDB which does the same, but seems like a complete implementation of the fields defined in OpenSocial 2.0. For our project, we wanted this to be merged in a single class and reused across the whole portal implementation. Our own Shindig backend currently operates at an even higher level to gain some speed and avoid additional conversions, but thats of course not ideal. What we want to find out is whether it makes sense for us to use Rave or do an own implementation that would be similar in many aspects, reuse Rave and have two databases, one relational for Rave and neo4j for Shindig, or change our Shindig backend so that it covers both Shindig and Rave data. For the latter alternative there are again two ways: building kind of a fork and using a more direct database access layer or use SpringData as a JPA abstraction for neo4j. Our goals are to let the Apache community benefit as much as possible from our efforts, without burdening our project too much with non-project-specific requirements. Below you find a list of requirements for our portal, for those who want to better understand our project. Any suggestions? Regards René P.S.: Im posting a similar question on the Shindig mailing list, just that you are not wondering if you are subscribed on both. ----------------------------------------------------------- Prof. Dr. René Peinl Teaching area: architecture of Web applications University of applied Sciences Hof Alfons-Goppel-Platz 1, 95028 Hof, Bavaria, Germany Tel: +49-9281-409-4820 Email: [email protected] Requirements for OpenSocial Intranet Portal Presentation layer · Portal entry page with admin predefined gadgets, customizable by user (mostly existing in Rave) · Gadget catalog (existing in Rave 0.12) · User profile page with photo, name and other attributes. Admin customizable. All open social fields should be available for display. Gadgets can be used to show additional data like activity stream, friends network, bookmarks/tags, (basic functionality available in Rave 0.12 /portal/app/person) · User directory with overview of existing users (including paging and search) (not present in Rave 0.12 yet) · Ability to add friends/following people to friends network (e.g. on profile page) (not present in Rave 0.12 yet) · Suggestion list for new friends based on common friends, interests, etc. (not present in Rave 0.12 yet) · Ability to set a status message (basic functionality available in Rave 0.12) · Ability to send a personal message to a friend (not present in Rave 0.12 yet, maybe possible with one of the gadgets) Logic layer · Gadget Rendering API (existing in Shindig 2.5 beta2) · Authentication against external identity and access management system (IAM) using OAuth 2.0 and SAML. (some references state that Apache Shiro is able to do that, but we havent seen the code implementing it) · Exposing social media data like friends, activities, as RESTful Web services (available in Shindig 2.5 beta2) · Exposing extended social media data like friend of a friend to portal gadgets as RESTful Web service (draft implementation available at iisys) Data layer · Full support for activitystrea.ms data storage and retrieval at data object layer (draft implementation available at iisys, but not with JPA support) · Storing/retrieving social media data like friends, activities, ratings, bookmarks, tags, in/from a graph database like neo4j (draft implementation available at iisys, it has to be discussed, whether it would be better to use SpringData JPA abstraction instead of direct neo4j access) · Integrating Rave and Shindig person data (not clear why Rave is having its own Person class which seems like a subset of Shindigs PersonDB) · Keeping Rave User and PageUser data consistent with IAM system · Storing Rave authorization data (gadget permissions, user preferences, ) in neo4j (not available yet) · Storing Rave general user data in neo4j. (not available yet)
