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).
1 comment:
I actually disagree with your assertion that portability has no meaning in the enterprise world. On the contrary, I think it's one of the most interesting things about it!
It's important to make a distinction between container services — which relate to the context that the application is displayed in — and application provider services — which relate to what the application displays. Containers IMO should only be concerned with things such as the current viewer, the page owner, etc. The interesting content of the gadget should be fetched from a remote server using REST APIs, often the one that hosts the gadget XML.
The benefit here is that you will be able to easily integrate information from heterogenous enterprise applications — which in the past have often operated as independent silos, or have taken a great deal of coding effort to integrate — and display it all in a single container. For that to work, portability is paramount.
So I think your last section about JavaScript APIs is actually spot on. I think that's the best way to deliver gadgets that can be portable, and I don't think it has to sacrifice the simplicity of the gadget. A clever JavaScript API could bind XML or JSON data to HTML elements that appear in the gadget spec file. We've written a similar JavaScript API for our gadgets, and it has actually made them quite a bit simpler, as we've been able to extract duplicated content and logic into the library. The gadgets themselves are reduced to declarative descriptions of their capabilities and data sources, with markup templates that are filled in with data at load time.
While I appreciate your analogy with Java code that is expected to run on different architectures, I think a more apt metaphor is HTML running in different browsers. Yes, they have different capabilities and quirks, and yes, sometimes you can add some extra polish to your applications by taking advantage of proprietary extensions to the standard. The goal, however, should always be cross compatibility, with graceful degradation to handle the lowest common denominator. So while I wouldn't go so far as to discourage custom features (they can be useful, and we use them ourselves) I think you should strive to make them optional in your gadgets, and provide JavaScript libraries that can detect the absence of a feature and fall back on default behavior.
Anyway, very interesting post! I'm glad I stumbled into it, and I'd be happy to discuss this kind of thing more. If you're interested in what we're doing with OpenSocial in the enterprise, we put a site up at http://www.atlassian.com/opensocial/ that describes our vision.
Cheers,
Tim Moore
Developer, Atlassian Integration Team
Post a Comment