Interoperating between SCA OASIS and OSOA composites

Service Component Architecture (SCA) applications are based on either the Open SOA Collaboration (OSOA) Version 1.0 SCA specifications or the OASIS SCA Version 1.1 specifications. We cannot mix OSOA and OASIS SCA artifacts, such as .composite files or sca-contribution.xml files, within the same asset. However, we can wire OASIS and OSOA SCA components together when both SCA composites are running in a single product cell.

For information about the differences between OSOA and OASIS specifications and about the differences between OSOA and OASIS in SCA applications, see the SCA overview topic.

This topic describes how you might wire OSOA and OASIS components together so that the components, although in separate SCA applications, can interoperate while both applications are running in the same product cell. The procedure provides a simple example that shows how to wire an OASIS component reference to an OSOA component service.

When wiring components for interoperation between OSOA and OASIS in SCA applications, consider the following restrictions:

• OSOA and OASIS components must interoperate over @Remotable interfaces. Local interfaces cannot be used and result in an exception error.

• Interfaces must be annotated in a way consistent with the run time in which they are deployed.

  • For an OASIS component to reference an OSOA component, the OASIS reference type must contain OASIS annotations, such as org.oasisopen.sca.annotation.Remotable.

  • For an OSOA component to reference an OASIS component, the OSOA reference type must contain OSOA annotations, such as org.osoa.sca.annotations.Remotable.

• For a reference in an OASIS component to target an OSOA component, the uniform resource identifier (URI) form must be component or component/service. The component/service/binding URI form is not supported.

• OASIS interfaces marked with the asyncInvocation intent cannot interoperate with OSOA services.

• The product does not perform interface matching between OASIS and OSOA services. Incompatible interfaces result in a runtime exception.

• The product does not perform policy matching between OASIS and OSOA services. Incompatible policies result in a runtime exception.

1. Create an OSOA SCA application.

   1. Define an OSOA composite with a single component for the application.

      <composite xmlns="http://www.osoa.org/xmlns/sca/1.0" name="InteropOSOARemote">
         <component name="HelloWorldService">
            <implementation.java class="interop.osoa.HelloWorldServiceImpl"/>
            <service name="HelloWorld"/>
         </component>
      </composite>

   2. Create a service interface that has a Java interface marked as remotable. The @Remotable annotation comes from the OSOA annotations package.

      package interop.osoa;
       import org.osoa.sca.annotations.Remotable;
       @Remotable
      public interface HelloWorld {
         public String sayHello(String text);
      }

   3. Create a service implementation.

      For this example, the service implementation adds the string "Hello " to the start of the text that it is sent, and then returns the modified text:

      package interop.osoa;
       public class HelloWorldServiceImpl implements HelloWorld {
         public String sayHello(String text) {
            return "Hello " + text;
         }
      }

2. Create an OASIS SCA application and wire a component reference to the service defined in the OSOA application.

   1. Define an OASIS composite with a single component and with a reference to the service in the OSOA application.

      <composite xmlns="http://docs.oasis-open.org/ns/opencsa/sca/200912" name="InteropOASIS">
         <component name="HelloWorldClient">
            <implementation.java class="interop.oasis.HelloWorldClientImpl"/>
            <service name="HelloWorld"/>
            <reference name="helloWorldOSOA" target="HelloWorldService"/>
         </component>
      </composite>

   2. Create a reference interface that has a Java interface marked as remotable.

      The reference interface is compatible with the HelloWorld service interface defined in the OSOA application but it is a different Java interface. The reference interface is in a different Java package; the @Remotable annotation comes from the OASIS annotations package.

      package interop.oasis;
       import org.oasisopen.sca.annotation.Remotable;
       @Remotable
      public interface HelloWorld {
         public String sayHello(String text);
      }

   3. Create a service implementation that implements the HelloWorld interface and uses a reference to the OSOA version of the component.

      For this example, the reference determines the text to return to the caller.

      package interop.oasis;
       import org.oasisopen.sca.annotation.Reference;
       public class HelloWorldClientImpl implements HelloWorld {
          @Reference
         protected HelloWorld helloWorldOSOA;
          public String sayHello(String text) {
            return helloWorldOSOA.sayHello(text);
         }
      }

3. Deploy the SCA applications into the same, or separate, business-level applications in the same cell.

   For OSOA, an sca-contribution.xml file is not required if there is only one default.composite file in the JAR. An sca-contribution.xml file can reside in the META-INF/ directory or in a subdirectory.

   For OASIS, an sca-contribution.xml file is required and must reside in the META-INF/ directory, and not in a subdirectory.

What to do next

To test the applications, we can call the HelloWorld service of the OASIS component (the HelloWorldClient component in step 2) and have the service return the string that it retrieves from the OSOA component (the HelloWorldService component in step 1).

Related concepts

SCA in WebSphere Application Server: Overview

Related tasks

Create SCA business-level applications with the console

Example: Create an SCA business-level application

Specifications and API documentation