Service component model based runtime
Original Publication Date: 2007-Apr-11
Included in the Prior Art Database: 2007-Apr-11
The Service Component Architecture (SCA) programming model defines programming artifacts and a language, Service Component Definition Language (SCDL), for describing service components. Instead of generating code or other runtime specific artifacts from SCDL, SCA defines a logical model for SCDL and implements it using the Eclipse Modeling Framework (EMF) technology. The SCA tooling, deployment function, and runtime all work with the same metadata logical model. Having the runtime work directly on a logical model representing the development artifacts greatly simplifies the develop / build / run process. It also allows for a better integration of tooling, deployment, and runtime. Finally, having this model allows components of the runtime (as well as extensions of the SCA runtime) to introspect the metadata representing an SCA application, SCA components, imports, exports, etc. The SCA metadata logical model is an abstraction of the concepts and classes used to describe SCA modules, imports, components, exports, etc. The SCA metadata model is implemented as an EMF model (registered with EMF under the SCDL namespace). The Application Programming Interface (API) to navigate the model is provided in the form of EMF generated interfaces. SCA also provides the serialization/deserialization of this model to and from SCDL Extensible Markup Language (XML) files using the standard EMF XMLResource mechanism. The SCA runtime populates the model and makes it available to SCA runtime components, SCA component implementation handlers, and binding handlers. The SCA runtime uses instances of this model directly to execute SCA service invocations.
Service component model based runtime
The Service Component Architecture (SCA) metadata logical model is an abstraction of the concepts and classes used to describe SCA modules, imports, components, exports, etc.
The SCA metadata model is implemented as an Eclipse Modeling Framework (EMF) model. The Service Provider Interface (SPI) to navigate the model is provided in the form of EMF generated interfaces in package com.ibm.websphere.sca.scdl.
The EMF model namespace is the same as the SCDL schema namespace: http://www.ibm.com/xmlns/prod/websphere/scdl/v6.0.0/ .
The SCA container runtime populates the model and makes it available to SCA qualifier handlers, component implementation handlers, and binding handlers (we will see later in the SPI section that the message passed to these handlers contains pointers to instances to the logical model classes).
SCA also provides the serialization/deserialization of this model to/from Service Component Definition Language (SCDL) Extensible Markup Language (XML) files, using the standard EMF XMLResource mechanism.
The following class diagram shows the SCA metadata model classes and relationships representing the structure of an SCA module, SCA exports, components, and imports.
Here's a description of the main classes shown in this diagram:
The Module class represents an SCA module. A Module is a specialization of the Aggregate abstract class. A Module contains zero or more components, imports, and exports (these relationships are inherited from the Aggregate class).
A module references zero or more required modules. Components in the module will be able to communicate with components in its required modules without going through an import or export (a module has its required modules on its classpath).
The Bus class represents the SCA bus. Bus is a specialization of the Aggregate abstract class. An Bus contains zero or more components, representing the modules installed on the bus.
The Aggregate class extends Implementation and abstracts a container for parts, which can be components, imports or exports. An aggregate has a name.
Module and Bus are subclasses of Aggregate.
The Part class abstracts a part of an Aggregate. A part has a name. Component, import, and export are subclasses of Part.
The Component class represents an SCA component. A Component has a name and contains an Implementation.
The Implementation class abstracts the implementation of a component. Subclasses are provided for the supported SCA component implementation types, such as JavaImplementation for Java components.
IBM WebSphere Process Server implements a specific component implementation type for business process components. Additional component implementation types can be added by...