Exploring the WebSphere Application Server Feature Pack for SCA, Part 8: Java EE support in the Feature Pack for SCA

This article describes the integration of Java™ EE support in the IBM® WebSphere® Application Server Feature Pack for Service Component Architecture (SCA). The feature pack supports use of Java EE archives as SCA component implementations, the consumption of SCA exposed services from Java EE components, and the exposure of stateless session EJB services as SCA services with support for rewiring those services. This content is part of the IBM WebSphere Developer Technical Journal.


Anbumunee Ponniah (aponnia@us.ibm.com), Software Engineer, IBM

Anbumunee Ponniah is a developer/tester involved in implementing JavaEE support in SCA Feature pack. Anbu has a rich background covering many technical areas ranging from Unix internals to application programming. He has previously been a technical lead for Java class libraries in IBM's Java technology center.

Chao M Beck, Software Engineer, IBM

Chao Beck is a technical lead for the feature pack for Service Component Architecture (SCA) early program. She has long been a member of the Application Integration Middleware early programs team responsible for the execution of early programs for IBM WebSphere Application Server products. She handles the development and delivery of education for new product functions and the provision of customer support during pre-GA (early) programs and post-GA (customer acceleration) programs.

Vijai Kalathur (kalathur@us.ibm.com), Software Engineer, IBM  

Vijai Kalathur is part of the SCA Feature Pack QoS team. Since joining IBM in 2005 he has worked on the WebSphere Application Server for z/OS security team and the SCA Feature Pack team. He has worked on various components of the SCA Feature Pack including admin, security, transactions, and JMS binding.

06 October 2010

Also available in Chinese


Java Platform, Enterprise Edition (Java EE) is the most prevalent and widely adopted standard for enterprise application development using the Java programming language. While the Java EE specification provides a rich set of technologies, it lacks support for extensible component implementation technologies, for extensions to abstract transport and protocol assembly, and for deploying components that transcend application boundaries. As such, it falls somewhat short of supporting a true service-oriented architecture (SOA).

The IBM WebSphere Application Server Feature Pack for Service Component Architecture (SCA) extends its own assembly, implementation type, deployment, and quality of service concepts to a Java EE application within that application's context. This enables the use of Java EE components as service component implementations, and also makes it possible to consume SCA artifacts, such as services and properties, from Java EE modules using SCA annotations. Additionally, it enables the ability to expose Enterprise JavaBean™ (EJB) services as SCA services, and to rewire EJB references.

Java EE archives as SCA component implementations

There are two basic scenarios for using Java EE archives as SCA component implementations:

  • The first is a non-SCA-enhanced scenario, in which a Java EE archive is made available in an SCA domain for use by SCA components using other implementation technologies.
  • The second is an SCA-enhanced scenario, in which Java EE modules can make use of the benefits of an SCA, such as rewiring, defining SCA properties, defining references to other SCA services in the domain, and using dependency injection.

These two types of integration scenarios are illustrated in Figure 1.

Figure 1. Java EE integration scenarios
A diagram illustrating two Java EE integration scenarios

Non-SCA-enhanced scenario

A Java EE archive representing a Java EE application and containing Java EE modules (such as EJB and Web modules) can be used as an SCA component implementation participating in an SCA composite. The SCA feature pack supports an external EAR contribution, in which the Java EE archive is packaged and deployed outside of the SCA contribution.

In the simplest scenario, if you have a Java EE archive named HelloJeeEar.ear and an SCA contribution JAR named HelloJeeSca.jar with a deployable composite, then the Java EE archive can be used as a component implementation in the SCA contribution by means of the syntax shown in Listing 1.

Listing 1. Sample SCA composite
<<?xml version="1.0" encoding="UTF-8"?>
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
targetNamespace="http://foo" name="HelloJeeScaServiceComposite">

	<component name="HelloJeeComponent">
	    <implementation.jee archive="HelloJeeEar.ear"/>

	<component name="MyScaComponent">
	    <implementation.java class=”sca.jee.HelloJeeScaServiceImpl”/>
	    <service name="HelloJeeScaService">
	        <interface.java interface="sca.jee.HelloJeeScaService"/>

In accordance with the OSOA (Open Service Oriented Architecture) Java EE Integration specification (see Resources), the derived component type will contain these services and references:

  • Each EJB 3 business interface with the unqualified name intf of a session bean bean translates into a service by the name bean_intf.
  • Each EJB 3 reference with the name ref of a session bean bean translates into an SCA reference with the name bean_ref.

In the above example, if HelloJeeEar.ear contains an EJB module HelloJeeEjb.jar that has a session bean HelloJeeEjb with a remote business interface HelloJeeSBeanRemote, then the name of the derived service will be HelloJeeEjb_HelloJeeSBeanRemote. The service interface derived will consist of all the methods of the EJB business interface.

The derived services can be referred to in other SCA components, just as with any other SCA service. It is important to note that the service interface will be remotable if and only if it is derived from the bean's remote business interface. Thus, without any need to change the implementation code, the EJB services and EJB references from a Java EE archive can become part of a SCA composite.

SCA-enhanced scenario

The SCA feature pack does not support the use of a Java EE archive as an SCA contribution, but does support the use of such an archive as a component implementation within a deployable composite in an SCA contribution; such an implementation is an SCA-enhanced scenario. In such an implementation, the Java EE archive must include a distinguished composite file named application.composite in its META-INF directory, as illustrated in Figure 2.

Figure 2. application.composite
A screen capture showing the application.composite file in a directory tree

When such a Java EE archive is used as an SCA component implementation within the implementation.jee directive, the SCA runtime automatically includes the artifacts specified in such a composite when deriving the component type. In order to expose any EJB services as SCA services, or to consume SCA services, application.composite needs to include components with EJB or Web implementation types using the deployable EJB and Web modules packaged in the same archive.

For example, consider a Java EE archive named HelloJeeEnhancedEar.ear containing an EJB module named HelloJeeEnhancedEjb.jar, which in turn contains a stateless session bean named HelloJeeEnhancedSBean and a Web module named HelloJeeEnhancedWeb.war. The archive might have the application composite shown in Listing 2.

Listing 2. application.composite
<?xml version="1.0" encoding="UTF-8"?>
<composite xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
	xmlns="http://www.osoa.org/xmlns/sca/1.0" xmlns:foo="http://foo" 
	targetNamespace="http://foo" autowire="false">
  <service name="HelloJeeEnhancedSBean_HelloJeeEnhancedSBeanRemote" 
  <reference name="sbean2" promote="EnhancedSbeanComponent/sbean2" 
      <interface.java interface="sca.jee.HelloJeeScaService" />

  <property name="propertyejb"   type="xsd:string">EJBIBM</property>
  <property name="propertyweb"  type="xsd:string">WEBIBM</property>
  <component name="EnhancedSbeanComponent">
  <implementation.ejb ejb-link="HelloJeeEnhancedEjb.jar#HelloJeeEnhancedSBean"/>
  	<service name="HelloJeeEnhancedSBean_HelloJeeEnhancedSBeanRemote"> 
  		<interface.java interface="sca.jee.HelloJeeEnhancedSBeanRemote" />
  	<reference name="sbean2">
  	    <interface.java interface="sca.jee.HelloJeeScaService" />
   <property name="propertyejb" type="xsd:string">IBMEJB</property>
  <component name="EnhancedWebComponent">
    <implementation.web web-uri="HelloJeeEnhancedWeb.war"/>
    <property name="propertyweb"  type="xsd:string">IBMWEB</property>

In Listing 2, the individual components specify the SCA services and references. If any of the services and references defined in the components in the application composite need to be exposed to the SCA domain via the component that implements this Java EE archive, they must be promoted from within the application composite. Any properties needed by individual modules must also be defined at the composite level. In the above example, the SCA property named propertyweb will have a value of WEBIBM and not IBMWEB in the derived component.

The use of application.composite enables the EJB services exposed as SCA services to now be rewired to SCA-compatible bindings such as binding.ws and binding.jms. The external SCA contribution using this Java EE archive as an SCA component implementation would look similar to Listing 3.

Listing 3. An external SCA contribution in application.composite
  <component name="HelloJeeEnhancedComponent">
    <implementation.jee archive="HelloJeeEnhancedEar.ear"/>
    <service name="HelloJeeEnhancedSBean_HelloJeeEnhancedSBeanRemote"> 
      <interface.java interface="sca.jee.HelloJeeEnhancedSBeanRemote" />
    <reference name="sbean2" target="HelloJeeScaComponent/HelloJeeScaService">
      <interface.java interface="sca.jee.HelloJeeScaService" />

Figure 3 illustrates how these components fit together in a typical Java EE implementation.

Figure 3. Java EE as an SCA implementation
A diagram showing various Java EE components as an SCA implementation

The SCA references and properties can be accessed in EJB and Web modules through annotations that are injected with the defined values at run time. Listing 4 provides an example.

Listing 4. Accessing SCA references and properties through annotations
import javax.ejb.Stateless;
import org.osoa.sca.annotations.*;

@Stateless                                                  // EJB annotation
public class AccountServiceImpl implements AccountService {
@Reference protected Brokerage backend;                     // SCA reference
@Property protected String currency;                        // SCA property
@Context protected SCAContext context;                      // SCA context

public AccountReport getAccountReport(String customerId) {
acctValue BigDecimal = Brokerage.getAccountValue(customerID,“IBM”;
                                                            // use injected reference
  if (currency != “S DOLLARS” {                             // use injected property
  moneyChangerService = context.getService(moneyChanger.class,”oneyExchange”;
                                                            // use injected context
  acctValue = moneyChangerService(current,acctValue);       // invoke SCA service
return backend(customerId, acctValue);

Another interesting aspect of defining SCA references through the application.composite file is the ability to override EJB references with compatible SCA references. As long as the interface of the SCA reference matches that of the EJB reference, the SCA run time injection will override that EJB. For example, as shown in Listings 5 and 6, the EJB reference sbean2 can be overridden by an SCA reference defined in application.composite. The bean class includes the annotation in Listing 5, and the application.composite file includes the <reference> tag in Listing 6.

Listing 5. Annotation for overriding EJB references
public class HelloJeeEnhancedSBean implements HelloJeeEnhancedSBeanRemote,
	HelloJeeEnhancedSBeanLocal {

	@EJB HelloJeeReferencedBeanRemote sbean1;
	@EJB HelloJeeReferencedBeanRemote sbean2;
		//This will be overridden with a SCA reference offering same operation
Listing 6. <reference> tag for overriding EJB references
  <reference name="sbean2" promote="EnhancedSbeanComponent/sbean2" 
      <interface.java interface="sca.jee.HelloJeeScaService" />

In the above example, the injected value for sbean2 would be that of the SCA reference sbean2 and not the EJB reference of the same name. Notice that SCA treats references as unique across the composite when handling promoted references. You should therefore pay attention to cases where EJB references with the same name resolve to different EJB modules.


If you intend to expose EJB services and references as SCA services and references, and are happy with the auto-generated names of the services and references, no changes are needed in your current implementation.

If, however, you want to limit the services exposed or want to rewire EJB references and services, then the Java EE archive should at minimum have an application.composite file. Only the services and references promoted in that composite file would then be used when the SCA runtime derives the component type. If you want the Java EE modules to access SCA artifacts, only then would the implementation need to be changed.

For a user with a Java EE archive, the assembly and deployment steps in a WebSphere Application Server environment would be:

  1. Create a new SCA JAR with a deployable composite that uses the Java EE archive as its component implementation using implementation.jee.
  2. Import both the Java EE archive and the SCA JAR as assets.
  3. Create a business-level application (BLA) and add the Java EE archive and SCA JAR to the BLA as deployed assets. The order is important: all Java EE archives used in an SCA contribution as SCA component implementations must be deployed before the SCA contribution is deployed.
  4. Start the BLA.


The Java EE platform supports authorization and security identity policies. The support security QoS is enforced by the underlying Java EE container. The use of authorization is supported in both SCA-enhanced and non-enhanced Java EE archives. The authorization and security identity policies for EJBs that are referenced by the implementation.jee element are enforced by specifying the security constraints in the EJB deployment descriptor (ejb-jar.xml) in the EAR. These are used in conjunction with the interaction policies on the bindings to authenticate and authorize access to the Java EE components. Administrative and application security both need to be enabled in order for security roles be enforced. Any SCA policy sets attached to an implementation.jee component with security and run-as polices will be ignored.


Transaction support for services defined in an implementation.jee component are handled by the Java EE container. Transaction attributes for the service are specified in the EJB deployment descriptor (ejb-jar.xml) in the EAR. To find a description of how SCA intents map to Java EE transaction attributes, see section 5.3 of the SCA Java EE Integration Specification, titled Mapping of EJB Transaction Demarcation to SCA Transaction Policies (see Resources). To propagate or suspend transactions for references in an implementation.jee component, specify the required SCA transaction intents in the composite file.


There are a number of benefits to integrating Java EE with SCA.

  • EJB services can be exposed as SCA services and then re-wired over various wire formats.
  • EJB module EJBRefs can be rewired using SCDL without changing the underlying Java EE artifacts.
  • An SCA programming model can be used to invoke business services in Java EE components.
  • Remotable services can be made available as SCA services over the SCA default binding without the need for defining an SCDL.
  • Services can be intermixed using other implementation types, such as implementation.java and implementation.wsdl.

In summary, the WebSphere Application Server Feature Pack for SCA enables Java EE programmers and architects to transcend differences in implementation technologies and leverage a service component architecture with little or no changes to their implementation, making it easier for them to take advantage of existing code while exploring an SCA.



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into WebSphere on developerWorks

ArticleTitle=Exploring the WebSphere Application Server Feature Pack for SCA, Part 8: Java EE support in the Feature Pack for SCA