Enhanced Manageability with OSGi, SCA, BPEL and Spring

Posted by Jean-Jacques Dubray on Feb 26, 2008

Sections

Enterprise Architecture

Topics

SOA Appliance ,

SOA Platforms ,

SOA

Tags

OSGi ,

BPEL ,

Spring ,

Management ,

Service Component Architecture

Ever since the OpenSOA initiative published the white paper entitled: "Power Combination, SCA, OSGi and Spring", the combination of these three technologies has generated some interest. There is even a commercial implementation of such an infrastructure. Spring Dynamic Modules already combines Spring and OGSi, while Spring Beans can be used as an SCA component implementation. Lately, Tuscany's Java implementation was built on Apache's OSGi framework: Felix.

If William Vambenepe is ready to grant to this new kind of infrastructure the claims of:

• “flexibility” (thanks OSGi),

• “testability” (thanks Spring)

• “reusability” (thanks SCA)

He is a bit more hesitant to concur with the authors of the white paper about:

• “simplicity” ... unless you are one of the handful of people involved in all three efforts.

• “manageability”, let’s call it “manageability potential” and remain friends.

Manageability is an important aspect of SOA. In a private communication, Brian Cowan, Director of Business Architecture in a large insurance company based in Seattle noted:Edit news

SOA seems to be pushing some of the monolithic application model complexity into management and operations. This is the price you have to pay to gain the capability to implement, deploy, scale or secure independent pieces of your solution.

William has already commented on the impact of SCA on manageability in an earlier post:

I see another advantage to SCA: it’s a machine readable description of the logic of the composite application, at a useful level of granularity for application and service management.

[Similarly] like SCA, BPEL wasn’t designed for manageability. It was meant for increased productivity, portability and flexibility. [...] It also provides very useful metadata for application management. Both in terms of highlighting the application flow (through activities) and in terms of clarifying the dependencies and associated policies (through partner links).

SCA, OGSi and Spring also help fill that gap. They provide extra application metadata that can be used by application management tools to provide more application context to management tasks.

In this white paper which that provides a broad introduction to OSGi the authors note:

The OSGi Service Platform is specifically designed for devices that can operate unattended or under control of a platform operator. These are the devices that need remote management.

Managing devices remotely requires a protocol. Selecting an appropriate protocol is difficult because there are so many choices, including SNMP, CMISE, CIM, OMA DM, and more.

The OSGi Alliance decided that no management protocol can be preferred over others because no protocol is suitable for all cases. The OSGi Alliance therefore chose an architecture that provides a management API to be used by an authorized bundle. This authorized bundle can then act as a Management Bundle, where this bundle maps a protocol to API calls.

As a matter of fact, the Departamento de Ingeniería Telemática (DIT) of the Universidad Politécnica de Madrid (UPM), in Spain have developed a JMX-based management agent for OSGi Service Platforms called JMood.

William recommends some caution by concluding:

while this is all exciting, part of me also wonders whether it’s not too early to risk connecting these specifications too tightly. I have seen too many “standards framework” kind of powerpoint slides that show how a bunch of under-development specifications would precisely work together to meet all the needs of the world.

• Older >