shindig-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Baxter <rbaxte...@apache.org>
Subject Re: AW: Shindig neo4j backend
Date Fri, 13 Jul 2012 13:34:36 GMT
On Fri, Jul 13, 2012 at 8:32 AM, Franklin, Matthew B.
<mfranklin@mitre.org> wrote:
>>-----Original Message-----
>>From: Stanton Sievers [mailto:ssievers@us.ibm.com]
>>Sent: Friday, July 13, 2012 8:26 AM
>>To: dev@shindig.apache.org
>>Cc: 'Florian Holzschuher'
>>Subject: Re: AW: Shindig neo4j backend
>>
>>Hi René,
>>
>>Shindig doesn't use encrypted tokens by default.  I can't speak for what
>>Rave is doing by default, but I can point you to some more information
>>about Security Tokens in Shindig [1].  This documentation is not complete
>>but should help as a starting point.  Any questions about the materials
>>there can be directed back to the dev list or as comments on the wiki page
>>(which I follow).
>
> Right.  Rave does enable security tokens by default using the Shindig infrastructure.

Just as an FYI, in a production environment Shindig would encrypt the
security tokens, by default that is turned off.

>
>>
>>Thanks,
>>-Stanton
>>
>>[1] https://cwiki.apache.org/confluence/display/SHINDIG/Security+Tokens
>>
>>
>>
>>From:   René Peinl <rene.peinl@hof-university.de>
>>To:     <dev@shindig.apache.org>,
>>Cc:     "'Florian Holzschuher'" <fholzschuher2@hof-university.de>
>>Date:   07/13/2012 08:12
>>Subject:        AW: Shindig neo4j backend
>>
>>
>>
>>Hi Matthew,
>>the puzzle pieces start to fit together for me.
>>As you mention security tokens. This is one of the major problems we still
>>have with Shindig/Rave integration. It seems like Rave has a much more
>>evolved security architecture and Shindig is currently only evaluating the
>>tokens Rave is generating against some non-encrypted demo-tokens which
>>fails
>>for obvious reasons.
>>Any hints on how to overcome this problem?
>>Regards
>>René
>>
>>-----Ursprüngliche Nachricht-----
>>Von: Franklin, Matthew B. [mailto:mfranklin@mitre.org]
>>Gesendet: Freitag, 13. Juli 2012 13:56
>>An: dev@shindig.apache.org
>>Cc: 'Florian Holzschuher'
>>Betreff: RE: Shindig neo4j backend
>>
>>
>>
>>>-----Original Message-----
>>>From: René Peinl [mailto:rene.peinl@hof-university.de]
>>>Sent: Friday, July 13, 2012 1:46 AM
>>>To: dev@shindig.apache.org
>>>Cc: 'Florian Holzschuher'
>>>Subject: AW: Shindig neo4j backend
>>>
>>>Thanks Ryan,
>>>to clarify things: Rave allows to have your own backend, it just has
>>>its own additional database abstraction and partly has persistence
>>>classes that are a subset of Shindig classes on the one hand, but add a
>>>few additional things on the other hand.
>>
>>Rave's common data abstraction is built for data that needs to be accessed
>>from both Shindig & Rave.  To be clear, these are convenience classes and
>>you could absolutely use a pure Shindig implementation, so long as you are
>>careful to manage the properties yourself and put encryption keys where
>>the
>>Rave instance can find them (for security token).
>>
>>>Dependency injection was also recommended on the Rave mailing list. I'm
>>>no expert of DI and have used it up to now only for things like
>>>authentication or logging. Therefore, I was not considering that
>>>option. I will have a look into how that might be an option for us. On
>>>the Rave mailing list they also recommended having two databases, a
>>>relational one for portal data like which pages exist and which users
>>>have permissions on them and the graph db for social media data.
>>
>>Rave offers a Spring/Guice bridge so that the components defined as Spring
>>beans can be bound to Guice injectors.  There is documentation on the Rave
>>website for how to override beans in the context so that your own
>>implementations could be used.
>>
>>As for the database, I wouldn't restrict it completely to Relational for
>>the
>>portal data.  You *could* use a Neo4j instance, but I don't really see the
>>value in storing that data in a graph...  I do see the value in storing
>>portal data in MongoDB as it is pretty much document oriented anyway.
>>However, Rave already has a relational DB implementation done in JPA, so
>>it
>>is the shortest route.  I hope to work some on a MongoDb impl at the
>>Apache@OSCON Social & Widgets hackathon.
>>
>>>
>>>Regarding the OpenSocial 2.0 missing features in Shindig it seems, that
>>>you have integrated patches from version 3.0 in current Shindig releases.
>>>I saw an open issue that already had a patch, but was scheduled for
>>>Shindig 3.0. The roadmap also stated that OpenSocial 2.0 support is
>>>scheduled for Shindig 3.0. It seems that changed in the last couple of
>>>weeks. I was specifically missing support for events
>>>http://activitystrea.ms/specs/json/schema/activity-schema.html#event
>>>But maybe I'm not up to date anymore. Sorry for that.
>>
>>I think having 3.0 code is OK so long as it is  not a breaking change for
>>2.5 compliance.  Other thoughts?
>>
>>>
>>>Regards
>>>René
>>>
>>>
>>>-----Ursprüngliche Nachricht-----
>>>Von: Ryan Baxter [mailto:rbaxter85@apache.org]
>>>Gesendet: Freitag, 13. Juli 2012 03:28
>>>An: dev@shindig.apache.org
>>>Cc: Florian Holzschuher
>>>Betreff: Re: Shindig neo4j backend
>>>
>>>Welcome Rene :)
>>>
>>>Let me preface this by saying I have little knowledge of how Rave is
>>>implemented.  I have been meaning to look at it more in depth but
>>>haven't had the time.
>>>
>>>I am kind of surprised Rave does not allow you to still use your own
>>>persistence mechanism if you so choose.  I would think they would still
>>>keep that option available to consumers since there are endless
>>>possibilities for persisting data.  If you really can't inject your own
>>>persistence model into Rave it sounds like option 1 is your best bet,
>>>but as you list out in your requirements Rave offers a ton of other
>>>functionality you want.  If you chose options 1 are you really forking
>>>Shindig, or just injecting your own implementations?  The two are very
>>different.
>>>
>>>I am a little confused about your comments about the activity stream
>>>implementation.  As far as I know it is a complete implementation, do
>>>you have specifics on what you think is missing?
>>>
>>>Between the Rave and Shindig community I am sure we can help you figure
>>>out which project is best for your use cases.  The Shindig community
>>>will welcome any contributions you want to make in order to help
>>>Shindig fit your use cases better and we would be glad to help explain
>>>any of the current features you have questions about.  A lot of us have
>>>gone through some extensive implementations and we realize the
>>>documentation around some of the feature is lacking.
>>>
>>>As far as the OpenSocial spec your contributions will be welcomed there
>>>as well, especially if you provide an implementation for it :)
>>>
>>>-Ryan
>>>
>>>On Thu, Jul 12, 2012 at 11:25 AM, René Peinl
>>><rene.peinl@hof-university.de>
>>>wrote:
>>>> Dear Shindig developers,
>>>>
>>>> I'm working together with my colleague Florian on a systems
>>>> integration research project that brings together a DMS, a groupware
>>>> system, an ERP system in an Intranet scenario and adds social media
>>>> capabilities under the hood of a central lightweight portal (see
>>>> requirements overview at the end of the email).
>>>>
>>>>
>>>>
>>>> For the portal, we are planning to use Shindig as the central
>>>> component and maybe Rave as a basis  for the presentation layer.
>>>> Since social media data is inherently graph-oriented, we are planning
>>>> to use neo4j as the storage engine for Shindig (and maybe Rave as
>>well).
>>>> Florian has already implemented a draft of this neo4j storage layer
>>>> which works well for some sample data that we have generated (if
>>>> anyone is interested we can provide the sample data and the generator
>>>> for it), but due to simplicity reasons and to avoid additional
>>>> conversion operations in between the storage layer is currently not
>>>> using JPA, but directly writing the objects to the database
>>>> (replacing
>>>e.g. both PersonImpl and PersonDB).
>>>>
>>>>
>>>>
>>>> Lately, we have discovered Rave and found out that despite its close
>>>> integration with Shindig it uses its own database abstraction and
>>>> partly competing implementations for classes that are already present
>>>> in
>>>Shindig.
>>>> 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 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.
>>>>
>>>>
>>>>
>>>> My goal is to better understand the decisions behind the current
>>>> implementation of both Shindig and Rave (I've posted a similar
>>>> question on the Rave mailing list) in order to find a solution for
>>>> our project that lets the Apache community benefit as much as
>>>> possible from our efforts, without burdening our project too much
>>>> with
>>>non-project-specific requirements.
>>>>
>>>>
>>>>
>>>> The options we have (from my perspective) are as follows
>>>>
>>>> 1)      Kind of forking the Shindig project and using our own neo4j
>>>backend
>>>> and not using Rave
>>>>
>>>> 2)      Going one step further and integrating Rave with our own neo4j
>>>> Shindig backend and eliminate the duplicate classes
>>>>
>>>> 3)      Trying to use SpringData JPA abstraction layer for neo4j and
>>>> providing some extended functionality in own classes (e.g. a
>>>> friend-of-a-friend query could be implemented with relational DBs as
>>>> well, but doesn't make too much sense due to performance reasons) and
>>>> hoping that the Rave and Shindig community are helping us to
>>>> eliminate the duplicate implementations on JPA level.
>>>>
>>>>
>>>>
>>>> All options have their pros and cons and I'd really like to hear your
>>>> opinion on that. If you have the feeling that our project idea is
>>>> very specific and you don't see any use for the results in your
>>>> scenarios than it may be better for both sides if we are building a
>>>> fork. On the other hand, if you think that the principle idea behind
>>>> our project would be beneficial for your scenarios as well, we would
>>>> be happy to work
>>>together on that.
>>>> We need e.g. some of the missing OpenSocial 2.0 features like full
>>>> activitystrea.ms support on the data layer, which is currently not
>>>> given in Shindig 2.5 beta2
>>>> (https://issues.apache.org/jira/browse/SHINDIG-1536), but we do not
>>>> want
>>>to interfere with your roadmap and release plans.
>>>> We also found several common scenarios that e.g. MS SharePoint is
>>>> supporting, but that are not feasible with OpenSocial 2.0
>>>> specification (mainly due to its focus on Internet scenarios).
>>>> Examples are: User has checked-out a document in a DMS. For this kind
>>>> of check-out operation, there is no post verb in the activitystrea.ms
>>>> standard.  We would be happy to bring these finding into the ongoing
>>>> discussion about future Open Social versions.
>>>>
>>>>
>>>>
>>>> Summed up, we wanted to know how we could best cooperate with the
>>>> existing Shindig (and Rave) community in order to quickly achieve our
>>>> goals and let the Apache community benefit the most from our efforts.
>>>>
>>>> Any suggestions?
>>>>
>>>> Regards
>>>>
>>>> René
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> -----------------------------------------------------------
>>>>
>>>> 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 0.12)
>>>>
>>>> ·         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 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)
>>>>
>>>>
>>>>
>>>>
>>>>
>>
>

Mime
View raw message