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.
Section | Not supported |
---|---|
1.3 Component |
|
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 |
|
1.6.2 Reference |
|
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. |
Section | Not supported |
---|---|
1 Policy Framework |
|
1.9 Miscellaneous Intents | The following miscellaneous intents are not
supported:
|
Section | Not supported |
---|---|
<operation> element |
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. |
Section | Not supported |
---|---|
2.1 Web Service Binding Schema |
|
2.1.1 Endpoint URI resolution |
|
Section | Not supported |
---|---|
2.1 Session Bean Binding Schema | /binding.ejb/@session-type
|
2.3.1 Conversational Nature of Stateful Session Beans | Lines 197-229 |
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.
Section | Not supported |
---|---|
1.4 JMS Binding Schema |
|
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. |
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:
|
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:
|
The product supports the SCA Spring Component Implementation specification except for the specification sections, or parts of sections, listed in the table.
Section | Not supported |
---|---|
1.2. Spring Application Context as Composite Implementation |
|
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. |