En busca de cuadros

The OSGi framework, whose specification is managed by the OSGi Alliance, was ini- tially formed with an emphasis on embedded devices and appliances. However, it rap- idly has become adopted within regular and even enterprise, applications. There are currently three excellent implementations: Apache Felix, Knopflerfish, and Equinox (the basis for the Eclipse OSGi implementation). Many of the Apache-based projects are beginning to incorporate the OSGi framework.

Arriving a bit later was the Service Component Architecture (SCA) and its companion technology, Service Data Objects (SDO). The 1.0 specification was delivered in fall 2005 and included such notable sponsors as IBM, Oracle/BEA, and IONA. SCA positions itself as an architecture for building applications and systems using a SOA. It defines a declarative XML-based mechanism for creating components and for exposing those components as services that can be invoked through any number of different proto- cols. Components can be wired together in a fashion similar to Springs “inversion-of- control” feature, and are written in a way that is communication protocol neutral (that is, the components have no awareness as to which protocol will be used to invoke them, such as SOAP, JMS, or EJB). Given that a lot of folks are probably not yet familiar with SCA, let's examine some of its core concepts in more detail.

2.7.1 Examining the Service Component Architecture

In SCA parlance, a composite is a collection, or assembly, of components or services. A service can be thought of simply as a component that’s exposed through an external protocol (for example, SOAP). A component, like a composite itself, can contain properties and references to other components or services. You can see the relation- ship between these items in figure 2.8 (which is a simplified view of SCA).

As figure 2.8 shows, a binding is how you define through what communica- tions protocol to expose a given compo- nent as a service.

SDO is a companion specification that defines a standard for exchanging data graphs or sets. What’s unique about the standard is that it supports the notion of

change logs. This allows for offline modifi-

cations to be captured and recorded.

The graphs themselves can be serialized into XML, and class-generation tools exist to create SDO objects from an XML Schema (alternatively, they can be created dynami- cally, and the metadata describing the structure can be gleaned dynamically as well).

What’s the relationship between OSGi and SCA? In a sense, they’re competing tech- nologies, as they both define a component framework for creating services. However,

OSGi primarily was designed for running within a single JVM and doesn’t inherently support exposing of services through a wide range of protocols. SCA, on the other hand, was developed with the goal of supporting a multilanguage distributed environ- ment. There’s an initiative to bridge the two so that you can, for instance, easily deploy

54 CHAPTER 2 Defining the Open SOA Platform

OSGi services within SCA. In that respect, the technologies can nicely complement each other, and indeed, the next major release (2.0) of Tuscany is being internally rewritten to run within an OSGi container. For purposes of our SOA Platform, we won’t specifically address OSGi, but we strongly encourage further research on the subject if you aren’t already familiar with it. Apache Tuscany, an SCO and SDO open source implementation, will be addressed in great detail starting in chapter 3.

Upon first examination of SCA, many Java developers are led to believe that it’s a substitute for Spring (as many of you are aware, Spring is a popular Java application framework). In part this confusion arises because SCA, like Spring, enables references (or other components) to be injected at runtime. Spring, like SCA, also supports the notion of properties, which can be declaratively defaulted in the XML configuration. Spring-WS even supports exposing Spring-based beans as web services, so that’s another similarity. That said, important distinctions exist, such as SCA’s aforemen- tioned multiprotocol and multilanguage support. In addition, SCA more intuitively supports asynchronous and conversational programming models. Like OSGi, Spring integration is also available for SCA.

Because of the reasons cited, and SCA’s integrated support for SDOs, it’s the service and component framework technology of choice for the Open SOA Platform. Let’s now further explore Apache Tuscany, the open source implementation for SCA and SDO.

2.7.2 Introducing Apache Tuscany

Apache Tuscany is a fairly new project, with its first beta releases in 2006 followed by the 1.0 release in fall 2007. The development team appears well staffed and is likely funded by the likes of IBM. The project recently was anointed as a top-level Apache Project from its prior incubator status, which corresponded with the 1.3 release in August 2008. Version 1.4 was released in January 2009, and is the basis for the code samples used in this book. The SCO and SDO standards have been transferred to the aegis of the OASIS organization. This is a significant development, as it lends great credibility to the project and removes the cloud that the combined specification was just a product of a few select vendors. OASIS has also set up a special website called Open Service Ori- ented Architecture (www.osoa.org) dedicated to advancing the standards.

The Tuscany and OASIS websites collectively contain extensive documentation. The specification documents for SCA and its related technologies are well written and com- prehensive. There are also a burgeoning number of SCA-related articles and some upcoming books dedicated to the standard. The demo and code samples that come with the Tuscany distribution are also very solid and a wonderful source of information. Commercial support for SCA and SDO has become realized by product releases by

IBM (WebSphere), Oracle/BEA (WebLogic, AquaLogic, Workshop) and Oracle (SOA

Suite 11g). Clearly, the momentum for SCA and SDO continues unabated.

The last remaining technology that helps form the basis for the Open SOA Plat- form is web service mediation.

55