Network Deployment (Distributed operating systems), v8.0 > Develop and deploying applications > Develop SCA composites > Use OSGi applications as SCA component implementations

SCA programming model support in OSGi applications

This topic describes the features of the Service Component Architecture (SCA) programming model that can be used with OSGi applications.

• Annotations
• Authorization policy
• Map of Blueprint transaction metadata to SCA service and reference transaction intents
• Use intents in an OSGi application
• Interface definition
• Custom wire format and operation selector
• Service Data Objects (SDO) version 2.1.1 with OSGi applications

Annotations

The following annotations from the org.osoa.sca.annotations package are supported within the interface classes in an OSGi application:

• @OneWay
• @Remotable

  When an OSGi application is used as an SCA component, its service and reference interfaces are automatically treated as remotable. The @Remotable annotation is not required. However, to use the same Java source interface in other contexts, it might need to contain the @Remotable annotation:

  • If you copy the interface to the SCA asset and specify it in an interface.java element for an implementation.osgiapp service or reference, the interface must contain the @Remotable annotation. Otherwise, an interface incompatibility error occurs.

  • If you wire implementation.java and implementation.osgiapp components to each other, the interface must contain the @Remotable annotation. Otherwise, the implementation.java component considers the interface to be local and an interface incompatibility error occurs.

No annotations from the org.osoa.sca.annotations package are supported within the implementation classes in an OSGi application.

Authorization policy

We 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.

Map of Blueprint transaction metadata to SCA service and reference transaction intents

Use the transaction metadata in the Blueprint component definition to define the transactional environment of an implementation.osgiapp component

We 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.

Valid combinations of transaction intents in OSGi applications. Use valid transaction intents for services and references of an implementation.osgiapp component.

Transaction definition in Blueprint component	Valid service intents	Valid reference intents
Required	propagatesTransaction transactedOneWay exactlyOnce	propagatesTransaction suspendsTransaction transactedOneWay
Mandatory	propagatesTransaction transactedOneWay exactlyOnce	propagatesTransaction suspendsTransaction transactedOneWay
RequiresNew	suspendsTransaction	propagatesTransaction suspendsTransaction transactedOneWay
Supports	propagatesTransaction	propagatesTransaction suspendsTransaction
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.

Use intents in an OSGi application

A Blueprint service can require a policy intent by using the service.exported.intents service property as shown in the following example:

<service ref="componentImplementation"
   interface="example.MyTransactionalServiceInterface">
<service-properties>
<entry key="service.exported.intents" value="propagatesTransaction"/>
</service-properties>
</service> 

Use the service.exported.intents property has the same effect as putting the intent in the SCA service definition.

The Application-ImportService header in the OSGi application manifest can filter for a particular policy intent on an imported service:

Application-ImportService: example.Greeting;filter="(&(service.intents=propagatesTransaction))"

If the SCA reference does not provide the intent, no services are imported.

Interface definition

It is not required to specify an interface element on a component service or component reference. We 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.

Custom wire format and operation selector

The JMS binding enables you to provide classes that customize its function. The classes can provide:

• A wire format handler that transforms data between the application interface and a JMS Message
• A custom operation selector to determine the operation name from a JMS Message

We 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, 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> 

Service Data Objects (SDO) version 2.1.1 with OSGi applications

We 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:

• We must invoke the OSGi application over a supported SCA service binding, such as an SCA default, Web service, JMS or HTTP binding. In particular, you cannot use the SDO functionality in your OSGi application when you access the OSGi application over HTTP using the Web container access path that you typically use to access OSGi application code packaged in an OSGi Web application bundle (WAB).
• The product does not support the injection of the SCA-managed default HelperContext object using annotation. However, you can implement an API, which uses the commonj.sdo.helper.SDO class, to access the default HelperContext object. For more information about the HelperContext object, see the documentation about accessing default HelperContext objects in SCA applications
• We cannot use SDO in an OSGi application that is accessed over the SCA service bindings binding.atom or binding.ejb.

For transitioning users: If the application previously used SDO version 1.0.0, change the Import-Package to:

Import-Package: commonj.sdo;version="[2.0.0,3.0.0)"

trns
SCA transaction intents
Use OSGi applications as SCA component implementations
Create wire format handlers
Create and accessing SDO HelperContext objects
Access default HelperContext objects in SCA applications

+

Search Tips   |   Advanced Search