I’m writing this blog post while waiting for innojam teams get to technical implementation of their ideas. InnoJam is a preconference event at teched Las Vegas. For the first time portal is an available technology for InnoJam participants thanks to simplicity and openness of SAP NetWeaver Cloud Portal, as well as support for server-technology-neutral component model Open Social. My colleague Alon Peled and myself are on site experts to help participants create great looking, customizable and personalizable UIs for their winning projects.
After having two years experience of applying Open Social in various enterprise areas with SAP development teams, partners and customers I decided to write few posts on that topic.
In the first post I would like to set a stage for discussion of OpenSocial, as a component model for composite enterprise applications. Originally introduced, as gadgets standard for consumer-oriented socially-reach internet services, this standard finds its way to enterprise and definitely embraced by SAP.
First, let me get back to early millennium years.
Concept of composite applications was led by the rise of the portals and SOA in the enterprise applications space. Earlier UI component models were bound to particular server technology and required deployment of application on the server. In most cases, event mechanisms, as well as integration of services were implemented on the server side. To name a few Java Portlets (JST 186 and JSR 286), MOSS WebParts, SAP Portal iViews and later Enterprise Workspaces modules and more. While industry tried to address interoperability of component models with WSRP standard, from my personal experience with this protocol it was very hard to develop vendor interoperable content even when vendors declared WSRP support.
Don’t get me wrong, those component models worked great when there was one team/group/customer developing apps and components on the particular runtime container, having all necessary skills and having little integration requirements. For the more sophisticated integrations full SOA stacks were applied making the solution quite complex even when it wasn’t necessary.
What didn’t work well with server side component models?
- Required particular technology stack and many times it wasn’t the mainstream technology adopted by IT department of particular enterprise.
- Deployed components were bound to the application lifecycle of the container, if runtime container allowed hot deployment you were lucky, otherwise entire server restart required.
- Interoperability with other stacks was always an issue
- Components were either fully trusted or sandbox was required, which wasn’t a case in many runtime containers
The way of widgets and gadgets
In the middle of last decade more and more internet services allowing 3rd party apps and widgets were introduced. Yahoo, MySpace, Google and later Facebook, LinkedIn and many more targeted to create huge developers community to enhance their platforms with new apps, service and components. Solutions for simple development model, out of the box authentication and authorization mechanisms, secured runtime environment, independent lifecycle for components were required. Open and proprietary standards were introduced. Open Social became leading open standard in this space.
What’s in Open Social?
Open Social consists of runtime container, where components are processed and running, set of client side JS APIs with dependency injection, extension model for the APIs and finally Open Social gadgets.
Open Social component model requires very little from the developer of gadgets, that’s the beauty of it. It doesn’t require implementation of particular interfaces, it doesn’t require particular way of web app development, in a matter of fact, it even doesn’t require gadget to be deployed where container is, it could be placed, just as a set of static files anywhere in the internet.
Is Open Social right UI component model for composite enterprise applications?
SAP, IBM, SF.COM, Atlassian and more enterprise software vendors investing a lot in this area. The standard is emerging and closing gaps. So the answer depends on particular needs and runtime container vendor.
However, same as many other open standards it standardizes only common functionality and the way functionality is extended, while every vendor has its own extensions, which hurts portability of Open Social gadgets. Second, client side integration, while has many benefits has also drawbacks: we’ll discuss them in the follow up blogs.
What are the benefits of Open Social
1. Lightweight, lightweight, lightweight: You may be productive virtually in minutes
2. Integration of your enterprise content with internet services: maps, translations, social feeds is easy
3. Open Social gadgets could be deployed anywhere thus disconnecting their lifecycle from the container
4. Choice of platforms supporting Open Social is rich and growing
SAP and Open Social
There are many efforts across SAP to support Open Social in various ways, runtime containers, gadgets, some in roadmap and some already available to customers. This may require a separate post. In my next post I will concentrate on how SAP NetWeaver Cloud Portal uses and enables Open Social component model. If you are in TechEd Las Vegas you may also try it, as a hands on experience in TechEd CD360 session on Wed 14:00 or Friday 8:00 or discuss with me in expert networking sessions on Thu 13:00 Lounge 2. Same sessions available also in TechEd Madrid and Bangalore.