Browse Prior Art Database

Service component model based runtime

IP.com Disclosure Number: IPCOM000149883D
Original Publication Date: 2007-Apr-11
Included in the Prior Art Database: 2007-Apr-11
Document File: 4 page(s) / 35K

Publishing Venue

IBM

Abstract

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.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 45% of the total text.

Page 1 of 4

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:

Module

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

1

[This page contains 51 pictures or other non-text objects]

Page 2 of 4

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

Bus

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.

Aggregate

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.

Part

The Part class abstracts a part of an Aggregate. A part has a name. Component, import, and export are subclasses of Part.

Component

The Component class represents an SCA component. A Component has a name and contains an Implementation.

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