Browse Prior Art Database

Mapping of the SCA Service Component Model to J2EE Disclosure Number: IPCOM000149881D
Original Publication Date: 2007-Apr-11
Included in the Prior Art Database: 2007-Apr-11
Document File: 6 page(s) / 51K

Publishing Venue



The invention defines and implements a mapping of the Service Component Architecture (SCA) programming model artifacts to the Java 2 Platform Enterprise Edition (J2EE) programming and packaging model. The mapping covers a number of aspects: - the packaging and deployment of SCA modules (mapped to J2EE Enterprise Archive (EAR) modules) - the creation of J2EE artifacts to support SCA imports and exports (artifacts responsible for the communication with external services in the SCA programming model) - the mapping of SCA Quality Of Service (QoS) such as transaction and security to the required J2EE artifacts (session beans with transaction and security attributes) - the on-demand creation of J2EE resource to support the SCA programming model such as asynchronous invocation - naming rules for deriving J2EE artifact names from SCA artifacts

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 35% of the total text.

Page 1 of 6

Mapping of the SCA Service Component Model to J 2EE


An Service Component Architecture (SCA) module is deployed as a Java 2 Platform Enterprise Edition (J2EE) application. A J2EE Enterprise Archive (EAR) file is created to host the SCA module and enable deployment to a J2EE application server.

The J2EE EAR contains the following modules:
an Enterprise Java Bean (EJB) Module
an EJB client module
a Web module
the SCA module Java Archive (JAR) file, packaged as a utility JAR

Optionally, the SCA module can use a META-INF/ file to declare dependencies on other JARs, as specified in the Java JAR Manifest file specification. In this case, the JAR dependencies are packaged in the J2EE EAR as utility JARs as well.

EJB artifacts are generated as necessary to support SCA exports as follows:

An EJB session bean with a remote interface is generated for each SCA export. The home and remote interfaces are generated in the EJB client module.

A Web Service endpoint is generated for each Web Service export. The Web Services runtime is configured to expose the EJB session bean generated for the export as a Simple Object Access Protocol (SOAP) web service.

A generic Module session bean is also added to the EJB module. This generic session bean is provided by SCA and used by the SCA runtime to dispatch SCA interactions to the components and imports in the module as necessary.

This session bean is not used to dispatch all SCA interactions. It is used only in the following cases:

To dispatch synchronous invocations of SCA components from a JavaServer Page

(JSP) or servlet residing in the same SCA module, but deployed in a separate Web module. This is to ensure that the execution of the invoked component or import is taking place with the correct J2EE and WebSphere context.

To facilitate transaction and activity session behavior when such qualifiers are specified at the reference, interface, or implementation level.

The Module session bean is not used to dispatch synchronous interactions between components and imports inside a module.


Page 2 of 6

The Module session bean is also used to reference resources or external services (EJB session beans and Web Services) required by the SCA imports and exports present in the module:

EJB Resource References are generated for the resources required by SCA J2EE Connector (J2C) and Java Message Service (JMS) imports and exports.

EJB References are generated for use by the SCA EJB imports present in the module, and bound to the external EJB session beans specified in the EJB import bindings. Java Specification Request (JSR) 109 Web Service References are generated to access the external Web Services represented by SCA Web Service imports.

A Message-driven Bean (MDB) is also added to support the asynchronous invocations. The MDB listens on all incoming requests to the module and disp...