This topic lists the sections of Service Component Architecture (SCA) specifications not supported in Feature Pack for SCA.
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 in Feature Pack for SCA v1.0 |
---|---|
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. Feature Pack for SCA 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 Feature Pack for SCA 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 in Feature Pack for SCA v1.0 |
---|---|
1 Policy Framework |
|
1.9 Miscellaneous Intents | The following miscellaneous intents are not
supported:
|
Section | Not supported in Feature Pack for SCA v1.0 |
---|---|
<operation> element |
Section | Not supported in Feature Pack for SCA v1.0 |
---|---|
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 in Feature Pack for SCA v1.0 |
---|---|
2.1 Web Service Binding Schema |
|
2.1.1 Endpoint URI resolution |
|
Section | Not supported in Feature Pack for SCA v1.0 |
---|---|
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 in Feature Pack for SCA v1.0 |
---|---|
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 in Feature Pack for SCA v1.0 |
---|---|
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 feature pack 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 feature
pack supports dependency injection. The feature pack 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 in Feature Pack for SCA v1.0 |
---|---|
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. |