Network Deployment (Distributed operating systems), v8.0 > Applications > SCA composites


Unsupported SCA specification sections

This topic lists the sections of Service Component Architecture (SCA) specifications not supported in the product.

The following tables list the unsupported sections of the indicated SCA specifications. The SCA Java Component Implementation specification is fully supported, so does not have a list of unsupported sections.


SCA Assembly Model

Unsupported sections. The product does not support these sections of the SCA Assembly Model specification.

Section Not supported
1.3 Component
  • Component attribute: constrainingType
  • A component element has zero implementation elements
  • Reference attribute wiredByImpl

1.4.1 Component Type constrainingType
1.5 Interface WSDL 2.0 interfaces are not supported.
1.5.2 Bidirectional Interfaces Callback is not supported for EJB binding.
1.5.3 Conversational Interfaces Conversation is not supported.
1.5.4 SCA-Specific Aspects for WSDL Interfaces Conversation is not supported.
1.6 Composite
  • Composite Attribute: local (optional) – whether all the components within the composite must all run in the same operating system process. local="true" means that all the components must run in the same process. local="false", which is the default, means that different components within the composite might run in different operating system processes. The product behavior is that, local or not, all components within the composite are deployed on the same Java virtual machine (JVM).
  • constrainingType

1.6.2 Reference
  • Composite reference attribute: wiredByImpl
  • Autowire only supported for the components within the same composite
  • The bindings defined on the component reference are still in effect for local wires within the composite that have the component reference as their source. The product limits the function wiring reference to outside service using binding specific endpoint URI (or using reference target). Wiring to local componentService is only supported for default binding.

1.6.3 Service The bindings defined on the component service are still in effect for local wires within the composite that target the component service. The product limits this function. Local component service can only be wired through default binding from a local component reference.
1.6.4 Wire Wire is not supported.
1.6.5 Composite Implementations Services defined in an implementing composite must use the <binding.sca> binding type. Non-SCA service bindings are not supported on inner composites. Reference bindings do not have this restriction.

Component implementations defined in an implementing composite must only be either implementation.java or implementation.composite. All other implementation types are not supported.

1.6.8 ConstrainingType ConstrainingType
1.7.2.1 Constructing Hierarchical URIs For the default binding, the product does not support the @uri attribute on the service-side binding. In other words, using a non-default URI on a service exposed over the default binding is not supported. Specifically, the @uri attribute should not be used on a <binding.sca> element that is a child of a component <service> element.
1.10.2 Contributions OSGi bundle as contribution
1.10.2.2 SCA Contribution Metadata Document sca-contribution-generated.xml
1.10.4.2 add Deployment Composite & update Deployment Composite Update Deployment Composite supported through the business-level application updateAssets command.


SCA Policy Framework

Unsupported sections. The product does not support these sections of the SCA Policy Framework specification.

Section Not supported
1 Policy Framework
  • @policySets (except for authorization policy)
  • definitions.xml (except for authorization policy)
  • callbacks
  • <operation> element
  • componentType file

1.9 Miscellaneous Intents The following miscellaneous intents are not supported:

  • SOAP
  • JMS
  • NoListener
  • BP.1_1



SCA Transaction Policy

Unsupported sections. The product does not support this element of the SCA Transaction Policy specification.

Section Not supported
  <operation> element


SCA Java Common Annotations and APIs

Unsupported sections. The product does not support these sections of the SCA Java Common Annotations and APIs specification.

Section Not supported
1 Common Annotations, APIs, Client and Implementation Model Conversation is not supported
1.2.4.2 - 1.2.4.3 Implementation Metadata @SCOPE("COMPOSITE") is not supported in the clustered environment, which means that "All service requests are dispatched to the same implementation instance for the lifetime of the containing composite" is not supported in the clustered environment.


SCA Web Services Binding

Unsupported sections. The product does not support these sections of the SCA Web Services Binding specification.

Section Not supported
2.1 Web Service Binding Schema
  • Line 47: wsdl.endpoint is not supported in /binding.ws/@wsdlElement
  • Line 55: wsdlLocation is not supported in /binding.ws/@wsdli:wsdlLocation

2.1.1 Endpoint URI resolution
  • Lines 71-79: Ordering of implementation in the product is shown below:
    ordering for reference side: reference target-> location in wsdl ->      EndPointReference -> binding.ws uri
    ordering for service side: binding.ws name -> binding.ws uri ->      implicit (component/service)
    
  • Line 73: URI in referenced WSDL (support limited to reference side)
  • Line 76: Explicit URI in binding.ws (support limited to reference side as absolute URI, on service side as relative URI (contextRoot))
  • Line 78: Implicit URI in binding.ws (support limited to service only)



SCA EJB Session Bean Binding

Unsupported sections. The product does not support these sections of the SCA EJB Session Bean Binding specification.

Section Not supported
2.1 Session Bean Binding Schema /binding.ejb/@session-type

  • Because the product does not support conversations, although session-type is set to "stateful", the service still behaves as stateless.

/binding.ejb/@uri

  • Line 91: The product only supports the following formats:

    • For EJB2
      corbaname:iiop:
      <hostName>:
      <port>/NameServiceServerRoot#ejb/sca/ejbbinding
      /
      <componentName>/
      <serviceName>
      

    • For EJB3
      corbaname:iiop:
      <hostName>:
      <port>/NameServiceServerRoot#ejb/sca/ejbbinding/
      
      <componentName>/
      <serviceName>#
      <serviceInterfaceName> Remote or corbaname:iiop:
      <hostName>:
      <port> /NameServiceServerRoot#
      <serviceInterfaceName>Remote
      

  • Line 97: corbaname:rir:#ejb/MyHome

2.3.1 Conversational Nature of Stateful Session Beans Lines 197-229


SCA JMS Binding

The product supports the SCA JMS Binding specification, with the exception of specification sections mentioned in the table. The OASIS Java Message Service (JMS) Binding specification was consulted for clarification of the SCA JMS Binding specification. However, the OASIS specification is not supported.

Unsupported sections. The product does not support these sections of the SCA JMS Binding specification.

Section Not supported
1.4 JMS Binding Schema
  • Line 103: /binding.jms/@uri is not supported.
  • Line 123: /binding.jms/@responseConnection is not supported.
  • Line 141: /binding.jms/destination/property is not supported.
  • Line 143: /binding.jms/connectionFactory is supported for reference bindings only. Request connection factories are not supported for service bindings. Response connection factories are supported for service bindings.
  • Lines 144 and 156: plain connection factory name is not supported. We must provide a JNDI name, and not a plain name.
  • Lines 149 and 161: plain activation spec name is not supported. We must provide a JNDI name, and not a plain name.
  • Line 159: /binding.jms/response/activationSpec is not supported. However, line 155, /binding.jms/response/connectionFactory, is supported.
  • Line 171: /binding.jms/resourceAdapter is not necessary to support JMS adapters. Thus, line 171 is not supported.

1.7 Callback and Conversation Protocol Lines 250, 252, and 254: conversation is not supported.
1.7.3 Conversations Line 267: conversation is not supported.


SCA Java EE Integration

The product supports all Java EE components consuming SCA services over default bindings within the context of annotations. The product supports the following specification sections:

Unsupported sections. The product does not support these sections of the SCA Java EE Integration specification.

Section Not supported
5.1.3 Dependency Injection Lines 241-242: callback and conversation are not supported
5.1.5 Using a ComponentType Side-File Not supported
5.1.6 Creating SCA components that use Session Beans as Implementation Types Supported for components in application.composite within the EAR.

Otherwise, not supported.

5.1.8 Use of Implementation Scopes with Session Beans Conversational is not supported
5.1.9 SCA Conversational Behavior with Session Beans Conversational is not supported
5.1.10 Non-Blocking Service Operations Not supported
5.1.11 Accessing a Callback Service Not supported
5.3 Mapping of EJB Transaction Demarcation to SCA Transaction Policies Not supported
5.4.3 Providing additional Component Type Data for a Web Application Files with .componentType extension are not supported
6.1.1 Java EE Archives as SCA Contributions Not supported because contributions are not supported.
6.1.2 Local Assembly of SCA-enhanced Java EE Applications Not supported
6.1.3 The Application Composite Supported, except for the following:

  • application.composite file as a deployable composite

  • Enterprise archive (EAR) as an SCA contribution

6.1.4 Domain Level Assembly of SCA-enhanced Java EE Applications Not supported
6.1.5 Import and Export of SCA Artifacts Not supported
6.1.6 Resolution of WSDL and XSD artifacts Not supported
7 Java EE Archives as Service Component Implementations The product supports Java EE archives as service component implementations, except the SCA JAR and the EAR must be in separate packages or assets. The EAR can contain an optional application.composite file under its META-INF directory that defines the componentType of the EAR. The product supports dependency injection.

The product does not support the following:

  • application.composite file as a deployable composite
  • web.composite and ejb-jar.composite files within the EAR
  • EAR as an SCA contribution
  • SCA JAR within the EAR



SCA Spring Component Implementation

The product supports the SCA Spring Component Implementation specification except for the specification sections, or parts of sections, listed in the table.

The product also supports Spring Component Implementation beyond what is described in the specification:

See the topic on additional Spring component implementation features.

Unsupported sections. The product does not support these sections of the SCA Spring Component Implementation specification.

Section Not supported
1.2. Spring Application Context as Composite Implementation
  • As to section 1.2, only the SCA (default) binding, web service binding, EJB binding, and JMS binding are supported.
  • Exposing a Spring bean as a service is not supported when the bean implements multiple interfaces. A Specs JIRA is open for this issue; see http://www.osoa.org/jira/browse/JAVA-59.

    To resolve this problem, explicitly define a <sca:service> element in the Spring application context file. If no explicit definition of <sca:service> is available, the problems remains by default when you expose all the beans as defined in the Spring context as services.

  • Callbacks are not supported.
  • Pass by reference is not supported.

1.2.1. Direct use of SCA references within a Spring configuration Under the specification, the <implementation.spring> location attribute can specify the target uniform resource indicator (URI) of a directory that contains the Spring application context files. The META-INF/MANIFEST.MF file is used to locate the Spring application context file. If there is no MANIFEST.MF file or no Spring-Context header within that file, then the default behavior is to build an application context using all the *.xml files in the META-INF/spring directory.

Currently, if there is no MANIFEST.MF file or no Spring-Context header within that file, then the default behavior is to build an application context using the application-context.xml file in the META-INF/spring directory. If the META-INF/spring/application-context.xml file does not exist, then the application does not deploy.

The product cannot support loading of *.xml files because the specification does not describe how to handle multiple spring context files.

The product does not support use of an archive file for the location attribute.


Specifications and API documentation


Related


Additional Spring component implementation features Concept topic

+

Search Tips   |   Advanced Search