You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@rave.apache.org by René Peinl <re...@hof-university.de> on 2012/07/12 15:01:41 UTC
JPA pros and cons (Re: Rave on MySQL)
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: rene.peinl@hof-university.de
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)
RE: JPA pros and cons (Re: Rave on MySQL)
Posted by "Franklin, Matthew B." <mf...@mitre.org>.
>-----Original Message-----
>From: René Peinl [mailto:rene.peinl@hof-university.de]
>Sent: Thursday, July 12, 2012 12:04 PM
>To: dev@rave.apache.org
>Cc: 'Florian Holzschuher'
>Subject: AW: JPA pros and cons (Re: Rave on MySQL)
>
>Thanks for your suggestions Matthew.
>If you state that the current implementation is "not optimal" and the
>project is still young, why does it work in that way?
>Once you have a lot of other projects using Rave it will become harder and
>harder to change things.
We recently just extracted interfaces for all of our model objects. Next on the list is to begin re-evaluating each one and moving toward a stable model that meets everyone's requirements for version 1.0. Short answer is we are actively fixing it :)
>
>Regarding the "alternative repositories": does that mean you are suggesting
>not to use SpringData JPA abstraction for neo4j?
You most certainly can, though SDN (Spring Data for Neo4J) is different than JPA. The programming model is similar, but the annotations and the way it works are different. You will need to define models and annotate them appropriately with the spring neo4j annotations anyway.
>What's the reason for that?
>Are there benefits of using two different databases for "person and group"
>and the rest instead of putting all in one database? Sounds like a lot of
>administrative overhead to me.
For the project I was using as an example, we get person information from one REST service, connection & group info from another. What I was attempting to state was that you should have the flexibility to use whatever set of backend systems you want by implementing custom repositories and marking them primary in the spring context.
For your context, I would think that using Neo4J for person, group and other "social" data and using SQL or other DB for persistence of pages probably makes the most sense, since you just want to keep things simple.
>
>-----Ursprüngliche Nachricht-----
>Von: Franklin, Matthew B. [mailto:mfranklin@mitre.org]
>Gesendet: Donnerstag, 12. Juli 2012 17:12
>An: dev@rave.apache.org
>Cc: Florian Holzschuher
>Betreff: RE: JPA pros and cons (Re: Rave on MySQL)
>
>>-----Original Message-----
>>From: René Peinl [mailto:rene.peinl@hof-university.de]
>>Sent: Thursday, July 12, 2012 9:02 AM
>>To: dev@rave.apache.org
>>Cc: Florian Holzschuher
>>Subject: JPA pros and cons (Re: Rave on MySQL)
>>
>>Dear Rave developers,
>>
>>I've just discovered the Rave project a week ago and therefore have not
>>yet fully understood all of its concepts and decisions, but I'm
>>currently preparing a project, where Rave could be very helpful and
>>wanted some suggestions on how to proceed there.
>>
>>
>>
>>I'm 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.
>>
>
>The Rave implementation abstracts the Shindig implementation and shares
>the
>person definition across the portal & shindig code bases. The current
>implementation is not optimal, but what you can do currently is define all
>of the OpenSocial field values as PersonProperties. The
>FieldRestrictingPerson then converts these to the values that Shindig
>expects.
>
>>
>>
>>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 that's 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.
>
>What my company does internally for one of our projects is replace the
>Person & Group Repositories and implementation of the model interfaces
>with
>ones that hit a different data source. We then inject these implementations
>into the Spring context as primary beans and run them in both the portal and
>Shindig. This would allow you to define everything that you want in Neo4J
>(which is what I intend to use long term for person connections), while
>still keeping JPA for the other objects.
>
>You of course have the option of completely overriding the guice binding for
>the Shindig Person service with your own, but then you won't be able to use
>the same code as easily in the Rave portal side.
>
>>
>>
>>
>>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.
>
>We, of course, welcome suggestions & enhancements :)
>
>>
>>Any suggestions?
>>
>>Regards
>>
>>René
>>
>>
>>
>>P.S.: I'm 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: rene.peinl@hof-university.de
>>
>>
>>
>>
>>
>>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
>>haven't 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 it's 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)
>>
>>
>>
>>
>>
>>
AW: JPA pros and cons (Re: Rave on MySQL)
Posted by René Peinl <re...@hof-university.de>.
Thanks for your suggestions Matthew.
If you state that the current implementation is "not optimal" and the
project is still young, why does it work in that way?
Once you have a lot of other projects using Rave it will become harder and
harder to change things.
Regarding the "alternative repositories": does that mean you are suggesting
not to use SpringData JPA abstraction for neo4j?
What's the reason for that?
Are there benefits of using two different databases for "person and group"
and the rest instead of putting all in one database? Sounds like a lot of
administrative overhead to me.
-----Ursprüngliche Nachricht-----
Von: Franklin, Matthew B. [mailto:mfranklin@mitre.org]
Gesendet: Donnerstag, 12. Juli 2012 17:12
An: dev@rave.apache.org
Cc: Florian Holzschuher
Betreff: RE: JPA pros and cons (Re: Rave on MySQL)
>-----Original Message-----
>From: René Peinl [mailto:rene.peinl@hof-university.de]
>Sent: Thursday, July 12, 2012 9:02 AM
>To: dev@rave.apache.org
>Cc: Florian Holzschuher
>Subject: JPA pros and cons (Re: Rave on MySQL)
>
>Dear Rave developers,
>
>I've just discovered the Rave project a week ago and therefore have not
>yet fully understood all of its concepts and decisions, but I'm
>currently preparing a project, where Rave could be very helpful and
>wanted some suggestions on how to proceed there.
>
>
>
>I'm 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.
>
The Rave implementation abstracts the Shindig implementation and shares the
person definition across the portal & shindig code bases. The current
implementation is not optimal, but what you can do currently is define all
of the OpenSocial field values as PersonProperties. The
FieldRestrictingPerson then converts these to the values that Shindig
expects.
>
>
>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 that's 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.
What my company does internally for one of our projects is replace the
Person & Group Repositories and implementation of the model interfaces with
ones that hit a different data source. We then inject these implementations
into the Spring context as primary beans and run them in both the portal and
Shindig. This would allow you to define everything that you want in Neo4J
(which is what I intend to use long term for person connections), while
still keeping JPA for the other objects.
You of course have the option of completely overriding the guice binding for
the Shindig Person service with your own, but then you won't be able to use
the same code as easily in the Rave portal side.
>
>
>
>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.
We, of course, welcome suggestions & enhancements :)
>
>Any suggestions?
>
>Regards
>
>René
>
>
>
>P.S.: I'm 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: rene.peinl@hof-university.de
>
>
>
>
>
>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
>haven't 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 it's 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)
>
>
>
>
>
>
RE: JPA pros and cons (Re: Rave on MySQL)
Posted by "Franklin, Matthew B." <mf...@mitre.org>.
>-----Original Message-----
>From: René Peinl [mailto:rene.peinl@hof-university.de]
>Sent: Thursday, July 12, 2012 9:02 AM
>To: dev@rave.apache.org
>Cc: Florian Holzschuher
>Subject: JPA pros and cons (Re: Rave on MySQL)
>
>Dear Rave developers,
>
>I've just discovered the Rave project a week ago and therefore have not yet
>fully understood all of its concepts and decisions, but I'm currently
>preparing a project, where Rave could be very helpful and wanted some
>suggestions on how to proceed there.
>
>
>
>I'm 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.
>
The Rave implementation abstracts the Shindig implementation and shares the person definition across the portal & shindig code bases. The current implementation is not optimal, but what you can do currently is define all of the OpenSocial field values as PersonProperties. The FieldRestrictingPerson then converts these to the values that Shindig expects.
>
>
>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 that's 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.
What my company does internally for one of our projects is replace the Person & Group Repositories and implementation of the model interfaces with ones that hit a different data source. We then inject these implementations into the Spring context as primary beans and run them in both the portal and Shindig. This would allow you to define everything that you want in Neo4J (which is what I intend to use long term for person connections), while still keeping JPA for the other objects.
You of course have the option of completely overriding the guice binding for the Shindig Person service with your own, but then you won't be able to use the same code as easily in the Rave portal side.
>
>
>
>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.
We, of course, welcome suggestions & enhancements :)
>
>Any suggestions?
>
>Regards
>
>René
>
>
>
>P.S.: I'm 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: rene.peinl@hof-university.de
>
>
>
>
>
>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 haven't
>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 it's 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)
>
>
>
>
>
>