This topic describes the features of the Service Component Architecture (SCA) programming model that can be used with OSGi applications.
The following annotations from the org.osoa.sca.annotations package are supported within the interface classes in an OSGi application:
No annotations from the org.osoa.sca.annotations package are supported within the implementation classes in an OSGi application.
You can attach an SCA policy set containing authorization policy statements to an implementation.osgiapp component. The policy set applies to all services of the component. It applies only when the services are started through SCA service bindings, and not when the OSGi application internally uses its services.
SCA does not support the use of the org.osoa.sca.annotations.PolicySet annotation or the annotations in the javax.annotation.security package in Blueprint implementation classes.
The configuration of role-based security for SCA components is independent of the configuration of role-based security for a Web application bundle (WAB). In other words, the roles and role mappings used for SCA components and for WABs are separate.
Use the transaction metadata in the Blueprint component definition to define the transactional environment of an implementation.osgiapp component
You can use the propagatesTransaction, suspendsTransaction, transactedOneWay, and exactlyOnce intents with the services and references of an implementation.osgiapp component. Use the correct intents for the transaction metadata in the Blueprint component definition. SCA does not detect mismatches. The following table shows valid combinations of Blueprint transaction metadata and transaction intents.
Transaction definition in Blueprint component | Valid service intents | Valid reference intents |
---|---|---|
Required |
|
|
Mandatory |
|
|
RequiresNew | suspendsTransaction |
|
Supports | propagatesTransaction |
|
NotSupported | suspendsTransaction | |
Never |
The managedTransaction.global, managedTransaction.local, and noManagedTransaction intents do not apply for implementation.osgiapp components.
Not all service bindings support all intents. For information about each intent, consult the SCA Transaction Policy specification.
The SCA run time does not effect the propagatesTransaction or suspendsTransaction behavior on an SCA service. Use the correct transaction definition in the Blueprint component to achieve the wanted behavior. The main purpose of using an intent is to document a requirement to use a binding that supports it.
It is not required to specify an interface element on a component service or component reference. You can specify an interface to enforce a given contract with the implementation. In this case, the interface must be compatible with the implementation as stated in the SCA specification. The SCA run time cannot validate that the interfaces are compatible until the business-level application is started.
If you specify an interface.java or interface.wsdl element, it must refer to a Java class or WSDL file that is packaged in the SCA asset, or that is imported from a shared asset.
The JMS binding enables you to provide classes that customize its function. The classes can provide:
You can package these classes in a bundle within the enterprise bundle archive (EBA). This is necessary to have access to Java packages inside the EBA bundles. For example, if a wire format handler needs to transform the content of a JMS Message into user-defined types defined within the EBA, the handler must be packaged in the EBA. To indicate that the handler is packaged in the EBA, you must use the deferLoad attribute; for example:
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0" xmlns:scafp="http://www.ibm.com/xmlns/prod/websphere/sca/1.0/2007/06" targetNamespace="http://www.example.com" name="MyOSGiComposite"> <component name="MyOSGiComponent"> <scafp:implementation.osgiapp ...> <service name="MyOSGiService"> <binding.jms> <activationSpec ...> <scafp:wireFormat.jmsCustom class="example.WireHandler" deferLoad="true"/> <scafp:operationSelector.jmsCustom class="example.OpSelector" deferLoad=="true"/> </binding.jms> </service> </component> </composite>
You can use Service Data Objects version 2.1.1 over SCA default, Web service, JMS and HTTP bindings for an implementation.osgiapp component service. Package schema definition (XSD) files in an SCA asset, or import XSD files from a shared asset.
The following limitations apply when you use SDO with an implementation.osgiapp component:
Import-Package: commonj.sdo;version="[2.0.0,3.0.0)"trns