OpenSocial In The Enterprise

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

http://www.opensocial.org/Technical-Resources/opensocial-spec-v09/OpenSocial-Specification.html

The OpenSocial Gadgets specification

http://www.opensocial.org/Technical-Resources/opensocial-spec-v09/Gadgets-API-Specification.html

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).

PonderPoint #2: ExRel with OSLC

This is a rather technical one. My thoughts on how ExRel's as they exist in Webtop could be done using basic OSLC (Open Services For Lifecycle Collaboration) concepts.

My first argument is that ExRel's in Webtop are essentially a correlation mechanism. The idea is to say some object, say a Model Element, is related to another object, say a Work Item. The intention is never to understand the underlying data at the other end of a link.

My second argument is that this fits with the Level 1 definition of OSLC where you can link objects simply by using URL's given that each resource/object has a URL.

My third argument is that each side of the ExRel must store the URL of the other side. Now that brings up a question of who stores all these mappings of objects -> related object URL's?

My argument here is that given that we're trying to enable Collaborative ALM here, and avoid brittle point to point integrations, we cannot ask tools to store this data. 

The counter argument that just occurred to me when typing this out, is that if each tool were to store objects -> related object URL's mapping then we could have ALM without really using any Jazz services simply relying on REST. That's really a Level 1 kind of idea.

The other way, which I find more appropriate is this. Given that we're speaking of solving ALM, we're definitely talking about more than one tool. So if we're linking objects it must be from the context of a new application (such as RTC/Webtop). Therefore, the objects -> related object URL's mapping storage and maintenance should be done by that application using several Jazz Foundation Services. 

We'd obviously store mappings both ways to enable navigation to related objects both ways given that ExRel's are not directional.

Classifying Twitter

I mean to expand on this later. But I was wondering how to 'label' Twitter?

I was hearing the TWiT podcast (http://twit.tv/twit)

which is an excellent podcast by the way and as is customary, there's a social media update from Leo Laporte.

Here's the first update. Lance Armstrong, avid twitterer, refused to speak to the press and instead updated his Twitter and initmated fans about a broken arm. Is this bypassing of conventional media? Is Twitter the ultimate ether, where anyone with a radio station can broadcast news? And your twitter account is exactly a mechanism to do that?

http://www.google.com/hostednews/afp/article/ALeqM5hqaYvaKXPG6ygYt1V_VSjpj5xz1w

Here's the second story, about corporate use of Twitter.

http://mashable.com/2009/05/21/twares/

An airline bypassing all conventional media for advertising vis-a-vis : radio, tv, print media, the traditional internet web ad's and going straight to the users.

PonderPoint #1 : The Losers of Tennis

We know the winner and the first runner up in a tournament of tennis gets prize money. Ever wonder what happens to the hundreds who are not one of those two fortunate ones? They still have to buy racquets, hire coaches, travel to tournaments. How do they sustain themselves?

Thinking....

PonderPoints

What are those? They are things that I'm pondering about. My next post would be the start. Watch out.