+

Search Tips   |   Advanced Search

SCA programming model support in OSGi applications

Several features of the Service Component Architecture (SCA) programming model can be used with OSGi applications.


Annotations

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.


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.


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

intents in OSGi applications. Use valid transaction intents
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.


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

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:

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


Related concepts

  • SCA transaction intents


    Related tasks

  • Use OSGi applications as SCA component implementations
  • Access default HelperContext objects in SCA applications