OSOA Home

Introduction

This whitepaper captures the current thinking within the Open Service Oriented Architecture (OSOA) collaboration on SCA-enabling a Java EE runtime. This whitepaper may be updated or become obsolete by other documents in the future. This whitepaper should be cited only as work in progress.

Java Enterprise Edition (Java EE) is the standard for Java-based enterprise applications today. While it offers a rich set of technologies, it does not define important concepts that are inherently required in service oriented architectures such as

• Extensibility of component implementation technologies
• Extensibility of transport and protocol abstractions
• a notion of cross-application assembly and configuration

The Service Component Architecture on the other hand provides a standardized but extensible assembly language and methodology that can be layered on top of existing component models and runtimes.

While the Java EE client and implementation specification will focus on the context comprising of Java EE concepts and SCA concepts, it is expected, that combined application assemblies with other technologies for which SCA integration specifications have been completed, such as BPEL and the Spring framework, will be supported by SCA enabled Java EE runtimes in the future. 

SCA integrates with Java EE in several ways. SCA Bindings describe how to expose or consume session beans, Java Message System (JMS) destinations, and more.

This paper scopes the integration of SCA and Java EE within the context of a Java EE application. It addresses Java EE specific implementation types and assembly as well as deployment concerns.

Scenarios

The following scenarios should be readily implementable by Java developers and that must be supported by SCA enabled Java EE runtimes in accordance with the Java EE client and implementation specification.

Consume SCA-exposed services from Java EE components

For example, a web component should be able to easily consume a service implemented by a service component

Consume session beans from service components

Existing EJB session beans should be easily re-usable in service component implementations. For that purpose the EJB Session Bean Binding ([2]) describes an SCA binding that allows to bind SCA references to session beans

Expose SCA services as session beans

Existing EJB session beans can be replaced by service component implementations, so that EJB implemented client components do not need to be rewritten. See the EJB Session Bean Binding specification ([2]) for more details.

Use Session Beans as Service Component Implementations

The recursive assembly model of SCA provides rich means of configuration and re-use of service components that may be implemented as SCA composites or by some other implementation type. Session beans are the Java EE component implementation model and serve also as service component implementations.

Expose enterprise applications into an SCA domain

The SCA Assembly specification describes a deployment model for SCA contributions that provides cross-enterprise application assembly capabilities when layered over Java EE.

Use recursive SCA assembly in enterprise applications

SCA Assembly provides means to define sophisticated application assembly for enterprise applications.

Java EE based Implementation Types

The elementary building block of SCA assembly is the Service Component. In order to provide first class capabilities of exposure of services or consumption of service components, we define implementation types that represent the most prominent application component in Java EE applications: enterprise java beans and web application components.

The intention is to define a convenient implementation model for developers of these components. For example, a web component developer can use SCA annotations, such as @Reference, to declare service component references in the web component implementation.

The EJB Implementation Types

Enterprise Java Session Beans are the Java EE means to encapsulate business logic in an environment that manages remoting, security, and transaction boundaries. Service components in SCA play a similar role and so session beans are the most obvious candidates for service component implementation in a Java EE environment.

In order to define an implementation type, it is essential to describe the SCA component type derived from a session bean. SCA components use the component type as a prototype template for configuration and instantiation.

In this paper, we limit ourselves to session beans programmed in accordance with version 3 of the EJB specification.

The component type of a session bean that does not use any SCA annotation and is not accompanied by a component type side file is constructed by the following loosely described algorithm:

Each business interface of the session bean translates into a service by the unqualified  name of the interface. A remote interface is considered a remotable SCA interface. The component type declares no SCA references and no SCA properties.

For example:

package services.accountdata;

import javax.ejb.Local;

@Local
public interface AccountService {
    AccountReport getAccountReport(String customerId);
}

with a session bean implementation

package services.accountdata;

import javax.ejb.Stateless;

@Stateless
public class AccountServiceImpl implements     AccountService {

    public AccountReport getAccountReport(String customerId) {
        // ...
        return null;
    }
}

would result in the following component type:

<?xml version="1.0" encoding="UTF-8"?>
<componentType xmlns="http://www.osoa.org/xmlns/sca/1.0">
  <service name="AccountService">
    <interface.java interface="services.accountdata.AccountService"/>
  </service>
</componentType>

Further SCA component type information can be provided in a component type side file that follows the naming pattern

META-INF/<bean-name>.componentType

and is located in the ejb module (see also [3] for more details on component type side files).

Using a component type side file or SCA annotations, a service component developer can easily create session beans that imply a more complex component type. The following annotations can be used in session bean implementation and other supported component implementation types:

(see also [4] for a comprehensive list of SCA annotations)

In order to declare a service component instance that is implemented as a session bean, an implementation.ejb declaration can be put in some composite definition (see below). It has the following pseudo schema:

<implementation.ejb ejb-link="<ejb-link-name>"/>

The following example declares a service component of name beancomponent, that is implemented by the bean SimpleBean in the ejb-module module.jar, in the composite beancomposite of the namespace http://www.sample.org. The component service, named with the bean's business interface name, gets promoted to the composite level:

<?xml version="1.0" encoding="UTF-8"?>
<composite name="beancomposite" targetNamespace="http://www.sample.org"
	xmlns="http://www.osoa.org/xmlns/sca/1.0">

	<service name="AccountReporting" promote="beancomponent/AccountService"/>

	<component name="beancomponent">
		<implementation.ejb ejb-link="module.jar#SimpleBean"/>
	</component>
</composite>

Another EJB based implementation type is constructed from message-driven beans. Like a session bean, a message-driven bean has a component type, so that it can have default configuration. In order to apply further SCA configuration for a message-driven bean, an SCA component using the MDB implementation type can be declared. To declare an MDB implementation of a service component the implementation.mdb tag must be used. It has the same schema as the implementation.ejb tag.

Message-driven beans cannot be instantiated arbitrarily often due to their association with non SCA-controlled endpoints (typically JMS). Therefore, within the assembly of the contribution package, a message-driven bean may be used as service component implementation at most once.

Web Components

Web application components are first-class consumers of service components and should hence be able to reference services in a developer-friendly way. As for session beans and message-driven beans, we associate a component type with a web component.
A web component can provide additional component type data in the side file

WEB-INF/web.componentType

in the web module archive. A web component cannot expose a service, but it can have references. And it may use the appropriate annotations listed above in the web component implementation classes such as Servlets, Filters, Event Listeners, Tag lib Listeners, Taglib Tag Handlers, and Managed Beans.

The implementation.web tag can be used to declare a service component that is implemented by the web component. It has the following pseudo-schema.

<implementation.web module="<module name>"/>

As for message-driven beans, a web component can be configured at most once per assembly of the contribution package.

Assembly of Enterprise Applications

The Java EE specification defines assembly of Java EE Enterprise Applications in terms of Application Components and System Components, such as Application Clients, Applets, Servlets and JSP pages and other web components, Enterprise Java Beans, and Resource Adapters.
Application components may be explicitly wired by virtue of declaring references in various deployment descriptor formats or by use of Java annotations. For example, an EJB-module deployment descriptor may declare a reference between two session beans by an <ejb-ref> XML element. See [1] for more details.
On an SCA-enabled Java EE runtime SCA assembly extends Java EE assembly by providing a framework for additional implementation types, bindings, and wiring capabilities.
SCA assembly uses composites as scoping mechanism. An SCA-enabled Java EE runtime associates an enterprise application with a logical composite called the application composite. This composite serves two purposes:

• It provides a scope for resolution of defaults in component type definitions of web components, session beans, and message-driven beans.
• It provides an entry point to application assembly in terms of making declared bindings effective (i.e. it is runnable).

The application composite is defined by a SCDL file called

META-INF/application.composite

in the enterprise application package. The following example application.composite file would configure a property of a session bean RemotableBean and expose its remote interface service using a default web service binding:

<?xml version="1.0" encoding="UTF-8"?>
<composite name="accounting_application"
	targetNamespace="http://www.sample.org"
	xmlns="http://www.osoa.org/xmlns/sca/1.0">

	<service name="AccountReporting" promote="beancomponent/AccountServiceRemote">
		<binding.ws/>
	</service>

	<component name="beancomponent">
		<implementation.ejb ejb-link="module.jar#RemotableBean"/>
		<property name="currency">EUR</property>
	</component>
</composite>

The application composite can be further extended by re-using assembly definitions contained in the application package using SCA assembly mechanisms such as composite inclusion and additional component declarations.
Enterprise applications are assembled from modules, such as EJB modules and Web modules. Modules can provide composite definitions for inclusion into other composite or for use as implementation by the assembler.

Single Module Assembly

The Java EE specification supports deployment of single application modules. This method of deployment is particularly popular for web application modules but also used for EJB modules and Resource Adapter modules. We treat single modules as a simplified application package. We define special composites defined in

WEB-INF/web.composite

for Web modules, and in

META-INF/ejb-jar.composite

for EJB modules, that serve as root of assembly in case of single module deployments, just like the application composite does for the enterprise application package.

Deployment of Enterprise Applications

The SCA assembly specification (see [3]) describes a deployment model for SCA in terms of domains and domain contributions. This section describes the projection of the Java EE integration with SCA onto that model.

The domain contribution of an enterprise application is the enterprise application archive, as defined by the .ear file format, or the single module archive, as .war or .jar files, in the case of a single module deployment. In order to indicate that the package represents an SCA contribution, the package may provide an SCA Contribution Metadata Document at

META-INF/sca-contribution.xml

By specifying deployment composites in the contribution metadata document, the package can contribute to the domain composite.
For example, the composites below and the following contribution metadata document would lead to exposure of a contribution of a service component org.sample.Accounting to the domain composite.

<?xml version="1.0" encoding="UTF-8"?>
<composite name="AccountingToDomain"
		   targetNamespace="http://www.sample.org"
		   xmlns:sample="http://www.sample.org"
		   xmlns="http://www.osoa.org/xmlns/sca/1.0">

	<component name="org.sample.Accounting">
		<implementation.composite name="sample:AccountingForDomain"/>
	</component>
</composite>

<?xml version="1.0" encoding="UTF-8"?>
<composite name="AccountingForDomain"
		   targetNamespace="http://www.sample.org"
		   xmlns="http://www.osoa.org/xmlns/sca/1.0">

	<service name="AccountReporting" promote="beancomponent/AccountServiceRemote">
		<binding.sca/>
	</service>

	<component name="beancomponent">
		<property name="currency">USD</property>
		<implementation.ejb ejb-link="module.jar#RemotableBean"/>
	</component>
</composite>

<?xml version="1.0" encoding="UTF-8"?>
<contribution xmlns="http://www.osoa.org/xmlns/sca/1.0"
	xmlns:sample="http://www.sample.org">

	<deployable composite="sample:AccountingToDomain"/>
</contribution>

Another enterprise application, can wire to the provided service by providing a suitable deployment composite. In the example below assume the following contribution metadata document:

<?xml version="1.0" encoding="UTF-8"?>
<contribution xmlns="http://www.osoa.org/xmlns/sca/1.0"
	xmlns:here="http://www.acme.com">

	<deployable composite="here:LinkToAccounting"/>
</contribution>

Where

<?xml version="1.0" encoding="UTF-8"?>
<composite name="LinkToAccounting"
		   targetNamespace="http://www.acme.com"
		   xmlns:here="http://www.acme.com"
		   xmlns="http://www.osoa.org/xmlns/sca/1.0">

	<component name="com.acme.TicketSystem">
		<implementation.composite name="here:ticketing_application"/>
		<reference name="AccountReporting"
                       target="org.sample.Accounting/AccountReporting"/>
	</component>
</composite>

And the application composite is defined as:

<?xml version="1.0" encoding="UTF-8"?>
<composite name="ticketing_application"
	targetNamespace="http://www.acme.com"
	xmlns="http://www.osoa.org/xmlns/sca/1.0">


	<component name="web">
		<implementation.web module="web.war"/>
	</component>

	<reference name="AccountReporting" promote="web/AccountReporting"/>

</composite>

Note that the application composite is used as a component implementation of a composite that is included into the domain. This way, the application composite can participate in domain assembly.

The example above results in the wiring of a reference AccountReporting of the web component web.war to the domain level service org.sample.Accounting/AccountReporting. This assembly example has the following graphical representation:

SCA artefacts are referenced using XML qualified names. In general all SCA artefacts provided in META-INF folders of the application package and within application modules will be resolved automatically. For other artefacts, import declarations in the SCA contribution metadata document of the application package can be used to define hints for runtime specific resolvable paths to required artefacts.

References

1. Java ™ Platform, Enterprise Edition Specification Version 5
2. EJB Session Bean Binding
3. SCA Assembly Specification
4. SCA Java Common Annotations and APIs
5. SCA Java EE Client and Implementation Specification (to be completed)