Going by the current trend it seems that OpenSocial might replace current server side portal standards like Portlets and WSRP for good. OpenSocial gadgets can be considered the Web 2.0 equivalent of portlets
While portlets are server-side components that depend on aggregation at the server, OpenSocial gadgets are lightweight, javascript/DHTML/Ajax components that aggregate on the client (i.e the web browser). Portlets are expected to be deployed and maintained by administrators whereas OpenSocial gadgets can be pulled, on the fly, from just about any given source. And there is nothing much that you can do with portlets that cannot be done with a OpenSocial gadget and a servlet backend.
Time to say goodbye to all Portal Servers out there ?
Friday, April 18, 2008
Will OpenSocial replace existing portal standards ?
Subscribe to:
Post Comments (Atom)
This work is licensed under a
Creative Commons Attribution-NonCommercial-NoDerivs 2.5 License.
7 comments:
Yes
I think doing the aggregation on the client is an issue, because one of the sources may not be directly reacheable by the client. For example, let's say a company has a portal in its extranet, which is reacheable from the internet, and a portal on its intranet, which is not reacheable from the internet. Very controlled connections are allowed from the extranet to intranet.
In this case you can expose an intranet portlet on the extranet by using WSRP. I do not believe you could do that with OpenSocial.
I'm not too familiar with OpenSocial, so I have the following questions related to your piece:
Can OpenSocial gadgets cooperate with one another similar to the manner of JSR 168 and 286 portlets? i.e. can they share data and work together?
If aggregation is done on the client side, how does that affect the security model? Portal Servers decide which users see which pages/portlets when the page is generated on the server...
Customization and Personalization seem like they could be easily implemented on the client...
How are the phases of Portal (action-theme-render) handled by an all-client model?
I appreciate the post, and look forward to the discussion!
Erik,
The OpenSocial architecture uses a gadget server to proxy the sources to the client. So the gadget sources need to be accessible only to the gadget server. However, I am not sure how this might work in an intranet/extranet scenario.
Roller,
Inter-gadget communication is planned in future but not currently available.
http://code.google.com/apis/gadgets/docs/pubsub.html
Re: security & aggregation, this is achieved by introducing a gadget server which is separate from the Opensocial container. I plan to blog about my understanding of this in my next post.
Intergadget Communication: A more current link on the inter-gadget communication is here: http://wiki.opensocial.org/index.php?title=Incorporate_Open_Ajax_Hub_as_Pub-Sub_Mechanism_for_OpenSocial_1.next
This represents work that is based on the OpenAjax Hub, which provides a secure mechanism to do the eventing. Here's an article that shows how to do this as well: http://blog.opensocial.org/2010/02/using-ibm-mashup-center-to-build.html
Portlets and Gadgets: On the surface, they look very similar. Keep in mind that gadgets have the ability to access, via a standard API, the social context of the container they are deployed in. Portlets can't do this. As we begin to view "social networks" in a business context, e.g. I have a connected graph of people I work with in a specific context, then the ability to seamlessly weave that context into applications (aka gadgets) that can then be embedded into a situational application is extremely powerful.
Both are good tools. It's important to pick the right one for the right job.
Nice poost thanks for sharing
Post a Comment