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. You cannot mix OSOA and
OASIS SCA artifacts, such as .composite files
or sca-contribution.xml files, within the same
asset. However, you can wire OASIS and OSOA SCA components together
when both SCA composites are running in a single product cell.
Before you begin
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.
About this task
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.
Procedure
- Create an OSOA SCA application.
- 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>
- 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);
}
- 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;
}
}
- Create an OASIS SCA application and wire a component reference
to the service that is defined in the OSOA application.
- 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>
- Create a reference interface that has a Java interface
marked as remotable.
The reference interface is compatible
with the HelloWorld service interface that is 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);
}
- 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);
}
}
- 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 Java archive (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, you 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).