This is a short post on some very long discussions that we(me & Rajvel) had on how OpenSocial fits in the Enterprise world.
First, here are the resources we referred to -
The OpenSocial specification
The OpenSocial Gadgets specification
To start with I'd like to debunk the 'Portability of Gadgets across containers' concept for OpenSocial containers in the Enterprise world.
Assertion: Outside of pure social networking, portability of Open Social Widgets has no meaning. Portability only comes into play when using Open Social Javascript API's to get People, Friends, etc. This ensures a social networking widget written using OpenSocial features of the container will run on any other OpenSocial container & more importantly work in the context of that container without any code change.
In the enterprise world, where it is more likely that each provider will create non-standard extensions/features to the container to solve their business case, portability has no meaning at all. We're not after OpenSocial API's. We're mostly after a platform to enable widget developers.
Packaging: The Hidden Benefit?
Moving on, according to us, one of the hidden benefits of the use of an OpenSocial container in the enterprise is - Packaging.
As per the OpenSocial Gadget specification, there are two distinct delivery mechanisms for a OpenSocial gadget. The more often used one, where the gadget is defined in the of the Gadget XML & is processed by the container.
The other where one provides a URL to the content (HTML + CSS + Javascript) somewhere. In this case interestingly, the responsibility of packaging & hosting the application/gadget is one that the Gadget Developer must take on. The container simply uses the content from the URL, wraps it in an IFRAME and passes it on.
Constrast this with the pure OpenSocial Gadget case where the Gadget Developer knows the target container & it's (probably proprietary features). He develops & tests his gadget against this container in his test setup. Thereafter, he simply shares with the world one XML file and everything else is gloriously managed by the container! How do you like that for convenience? :-)
This also brings in a counter-argument to our assertion of Portability of Gadgets across containers being nonsensical in the enterprise context. But we would like to point out that, while the Gadget Developer relies on the portability of his gadget & therefore is comfortable in publishing the XML confident that it will run on a container that is similar to his, the gadget is NOT portable across ANY OpenSocial container in the way that true social gadgets using the core OpenSocial API's are.
You may want to think of the analogy of a Java programmer who develops an application on an X86 machine, confident (at least reasonably) that this same program will run just fine on a Mainframe that has a Java VM.
Exposing Jazz Services as Javascript API's
This is perhaps the obvious next step in the thought process. Think of a Jazz Open Social container, that has implemented a Jazz Foundation feature that exposes all of the JFS services as Javascript API's.
Is that a good idea? Or worthwhile?
Or would it be better to just ask gadgets/widgets to simply use the existing REST API's?
I can only argue that it would be convenient for widget developers if all the complexity of making the REST requests were abstracted away.
This would be like the Jazz Java SDK that is available today that does this on the server side.
The question of why we should not just provide this as a simple Javascript library comes up again. Let the widget developer use the library in whatever way they seem fit & deal with the packaging.
But then you miss out on the benefits of the pure HTML deliver of OpenSocial, as argued above. So we think this is a good idea too. It would enable rapid development of widgets for the Jazz platform, using the power of the Jazz services to any one using the JTS (which would probably have a OpenSocial container bundled in & have special features implemented).
