The intention of this page is to document the differences between the Tuscany(OSOA) and OASIS versions of SCA on a spec by spec basis. I intend initially just to highlight those features that differ and have an impact on Tuscany without confirming those features that remain the same but we'll see how it goes.
This page is under construction so please feel invited to add any differences that you are aware of
http://www.osoa.org/jira/secure/BrowseProjects.jspa
General
Feature |
OSOA Ref |
OSOA Description |
OASIS Ref |
OASIS Description |
---|---|---|---|---|
Schema namespace |
|
|
Assembly
OSOA - Tuscany 1.x (SCA_AssemblyModel_V100 +)
OASIS - sca-assembly-1.1-spec-cd01-rev3 + Current JIRA
http://www.osoa.org/jira/browse/ASSEMBLY
|
OASIS JIRA |
Description |
Tuscany TODO |
Tuscany JIRA |
Conformance |
---|---|---|---|---|---|
|
Is binding.sca always present? |
If a component service is configured with binding.ws, can be accessed by a component reference in the same composite with binding.sca? Reference side is different now. When no bindings it dervies them from service |
|
|
|
|
Is interface.java specification normative in SCA-Assembly spec? |
No action is required |
|
|
|
|
component type allows to specify wire targets on references |
Push teh getTargets() method from Reference to ComponentReference |
|
|
|
|
usage of not promoted references |
Make sure the reference resolution follows what's described by the assembly spec |
|
|
|
|
SCDL artifact resolution underspecified |
Adjust the artifact resolution based on the proposal in this JIRA |
TUSCANY-3079 |
|
|
|
Conflicting Specification of Values for Many-Valued StringProperties |
Adjust the property value processing to conform to the new syntax, Can't have multiple properties with the same name |
|
|
|
|
Component URI is not well described |
Tuscany needs to support the structural URI based on this proposal |
|
|
|
|
Need to define Namespace handling for included Composites |
Tuscany needs to adjust how the composite include is aggregated based on the proposal in this JIRA |
|
|
|
|
XSD definitions of Component Service and Component Referencehave unintended features |
|
|
|
|
|
WSDL extension should not be required for conversations |
Make sure conversational intent is supported at interface and service |
|
|
|
|
SCA <anyAttribute.../> declarations should use namespace ##other rather than ##any |
Update the xsd from OASIS, can we support OSOA and OASIS xsds? |
|
|
|
|
Can Implementation change property values after instantiaion |
No action is required |
|
|
|
|
SCA Composite Visibility |
This seems to be a clarification by the spec |
|
|
|
|
Missing XSD for contributions |
Update the xsd from OASIS. Update the Import/Export model to |
|
|
|
|
Incorrect description of <Operation/> child elements inAssembly |
I see this conflicts with http://www.osoa.org/jira/browse/POLICY-58 Policy-58 did win and operation elements are no longer required |
|
|
|
|
"SCA schema fixes requested for sca-core.xsd (based on OSOA site versions that may be copied to OASIS site)" |
|
|
|
|
|
Long-Running Request-Response Operations |
Tuscany needs to support the proposal |
|
|
|
|
Confusing words in Section 5.3 relating to ConversationalIntent , Conversational support has gone |
|
|
|
|
|
Compatability of component type side files |
Each implementation type has to decide how to support the componentType file |
|
|
|
|
Clarify whether a Default Value for a Property must appear inthe componentType of an implementation |
No action is required |
|
|
|
|
Permit intents and PolicySets on <interface/> elements |
The policy model needs to be changed so that interface can have intents/policySets attached. |
|
|
|
|
Autowire at the domain level |
Tuscany needs to decide if/how it will support the domain-level autowiring |
|
|
|
|
Conflicting domain-level <wire> deployments |
Tuscany needs to implement the proposal |
|
|
|
|
Autowire value for the logical domain composite |
I think Tuscany is OK here as the autowire=false for the domain composite |
|
|
|
|
for implentations.*'s fix attributes that should show qnames as values |
|
|
|
|
|
Allow multiple definitions.xml files |
Tuscany should allow META-INF/definitions.xml from SCA contributions. These definitions become visible to the SCA domain |
|
|
|
|
some smaller things we need to fix in the assembly specification |
|
|
|
|
|
Composite Completeness |
Tuscany needs to add more validations to ensure the completeness of the composite for implementaiton.composite |
|
|
|
|
No schema or extension model definitions for contributions |
|
|
|
|
|
Need to clarify definition of Bidirectional Interfaces |
Make sure Tuscany is consistent with the specified behavior |
|
|
|
|
Unresolved bindings on references |
Add the support for "componentName/serviceName/bindingName" as the wire target |
|
|
|
|
Description elements in SCDL |
Support documentation element in the model and processors |
|
|
|
|
What is the default value for many and mustSupply on Properties? |
remove "mustSupply" from <component> |
|
|
|
|
Specification wording unclear on how local and remoteable interfaces are specified |
Remotable is IDL specific |
|
|
|
|
Constraining Type talks about non-optional references but does not define what they are |
|
|
|
|
|
Component Type file name is too restrictive Assembly has washed itself somewhat of ComponentType files Up to C&I to define what to do, BPEL has got rid of them, Tuscany should ignore for 2.x |
|
|
|
|
|
ComponentType Properties should not have a source |
|
|
|
|
|
Language neutrality edits |
|
|
|
|
|
Implementation.composite pseudo-schema incorrect |
|
|
|
|
|
Do we need appendix A (pseudo-schema)? |
No action is required |
|
|
|
|
Corrections to the contributions schema, sca-contribution.xml specify what is deployable We should use in our samples |
See ASSEMLY-28 |
|
|
|
|
"Section on ""Wire"" in Appendix is Incorrect" |
Tuscany already has the correct model, No action is required |
|
|
|
|
How to map WSDL 1.1. portType to WSDL 2.0 interface and vice versa? |
Remove the wsdl2.0 specfics from sca namespace. Potentially add interface.wsdl2 under tuscany ns |
|
|
|
|
Identifying wire format and operation selection |
add "wireFormat" and "operationSelector" for bindings |
|
|
|
|
Duplicated atributes in sca-binding-sca.xsd and sca-implementation-composite.xsd |
No action is required |
|
|
|
|
Need for a Callback annotation for WSDL interface files |
Tuscany needs to handle sca:callback extensibility elements in WSDL |
|
|
|
|
Assembly Specification should not state what marks a Javainterface as Local |
|
|
|
|
|
Add a Section documenting naming conventions to the start ofthe SCA Assembly Specification |
No action is required |
|
|
|
|
No @replace attribute for <wire> in OSOA spec |
No action is required |
|
|
|
|
No <value> subelement for property in OSOA spec, so ASM50028,ASM50029 in OASIS spec couldn't be tested for vtest code. |
No action is required |
|
|
|
|
Top level composite services/references are not included in the virtual domain composite |
Adjust logic and tests |
|
|
Policy
OSOA - Tuscany 1.x (SCA_Policy_Framework_V100 +)
OASIS - sca-policy-11.1-spec-wd-10
http://www.osoa.org/jira/browse/POLICY
|
OASIS JIRA |
Description |
Tuscany TODO |
Tuscany JIRA |
Conformance |
---|---|---|---|---|---|
|
Implicit addition of intents based on a service or reference's @requires list |
|
|
|
|
|
Include definition on 'conversational' intent as mentioned in SCA Assembly |
|
|
|
|
|
External mechanism for attaching intents or policySets |
|
|
|
|
|
Need Transaction Policy Spec |
|
|
|
|
|
Should qualifiable intents have a default qualifier |
|
|
|
|
|
Profile intent extension - provides other intents |
|
|
|
|
|
More direct, structural qualifier definition |
|
|
|
|
|
Security implementation policy should be validate-able by schema |
|
|
|
|
|
Need more precision on when policies in a policySet are in effect |
|
|
|
|
|
The URL for the location of the ws-policy.xsd is incorrect. |
|
|
|
|
|
Improve description of the overides available to the two different hierarchies in SCA |
|
|
|
|
|
Need Support for Mutually exclusive intents |
|
|
|
|
|
Fix SCA Policy schema complex types for Qualifier and PolicySet |
|
|
|
|
|
Infoset for policySet/@appliesTo |
|
|
|
|
|
Need a clear way to distinguish Implementation Intents from Interaction Intents |
|
|
|
|
|
How to configure policySets |
|
|
|
|
|
Policy algorithm gets required intents from what interfaces definitions/declarations? |
|
|
|
|
|
How do we tell what a policySet @provides? |
|
|
|
|
|
Wire validation rules have changed |
|
|
|
|
|
Clarify the handling of Intents |
|
|
|
|
|
Intents which conflict with binding configuration |
|
|
|
|
|
Remove <operation/> elements from the specification |
|
|
|
|
|
Limit policySet attachment to bindings |
|
|
|
|
|
Clarify scope of ordered intent |
Add "ordered" intent support |
|
|
|
|
How are mayProvide intents on bindings satisfied |
|
|
|
|
|
intents names defined by SCA should be defined using camel case |
|
|
|
Implementations
Implementation-java
OSOA - Tuscany 1.x (SCA_JavaAnnotationsAndAPIs_V100 +)
OASIS - sca-javacaa-1.1-spec-cd01
http://www.osoa.org/jira/browse/JAVA
|
OASIS JIRA |
Description |
Tuscany TODO |
Tuscany JIRA |
Conformance |
---|---|---|---|---|---|
|
EJB remove method on EJBHome |
|
|
|
|
|
annotations on parameters |
@Reference, @Property can only be used for constructor parameters. Tuscany |
|
|
|
|
Clarify Request Scope lifetime |
Remove the Request scope |
|
||
|
Incorrect generated service name |
|
|
|
|
|
Inconsistent method description for @Init and @Destroy annotations |
Tuscany already validates the pattern |
|
|
|
|
Incorrect examples of methods annotated @Init and @Destroy |
|
|
|
|
|
@Reference annotation can also be used on a constructor parameter. |
|
|
|
|
|
Missing description of what the @EagerInit annotation does |
|
|
|
|
|
@Callback annotation does not feature in section on Interfaces |
|
|
|
|
|
Version requirements for SDO, JAXB and JAX-WS |
|
|
|
|
|
SCA Java Specifications do not Adequately Define the ComponentType of a Java implementation |
Check the compontType to see if it matches the rules defined by this proposal |
|
|
|
|
When more than one interface with the same unqualified name used in the @Service annotation |
|
|
|
|
|
SCA Spring Client and Implementation Specification uses an unacceptable namespace |
Update the namespace based on the OASIS spec |
|
|
|
|
Describe the concurrency model for each scope |
|
|
|
|
|
SCA Spring C & I specification does not state the purpose of sca:composite element |
Remove the sca:composite |
|
|
|
|
Incorrect code in section 6.7.2 example |
|
|
|
|
|
Should not say callback ID is passed in reference parameters |
|
|
|
|
|
Incorrect reference to "original request" |
|
|
|
|
|
Incorrect description of @Scope annotation default |
Make sure the scope is default to "COMPOSITE" if there is an @Conversational |
|
|
|
|
Missing word "type" for "return type" in CAA spec - sec 3.1 |
|
|
|
|
|
Normative references to SCA Spec docs point to v1.00 docs |
|
|
|
|
|
Inconsistent use of a and an when referring to annotations |
|
|
|
|
|
Incorrect definition of the SCA JEE JSP Tag library |
|
|
|
|
|
Java CAA spec does not contain the interface.java schema |
|
|
|
|
|
Spurious cast() method definition in ComponentContext interface |
|
|
|
|
|
Constructor name information may not be available |
Adjust the @Property/@Reference processor on CDI |
|
|
|
|
N/A |
Support for @Remote attribute in in <interface.java/> |
|
TUSCANY-3290 |
|
|
N/A |
Illegal annotations in a service interface class |
|
TUSCANY-3289 |
|
|
N/A |
Support JAX-WS Client Asynchronous API for a Synchronous Service as described in Java CAA |
|
TUSCANY-3294 |
|
|
N/A |
Update SCA Annotation definitions in sca-api to match the OASIS 1.1 Java CAA Specification |
|
TUSCANY-3293 |
|
|
N/A |
Verify @Service compliance with latest OASIS Java 1.1 draft spec |
|
TUSCANY-3300 |
|
|
N/A |
Verify @Property compliance with latest OASIS Java 1.1 draft spec |
|
TUSCANY-3301 |
|
Bindings
http://www.osoa.org/jira/browse/BINDINGS
Binding-jms
|
OASIS JIRA |
Description |
Tuscany TODO |
Tuscany JIRA |
Conformance |
---|---|---|---|---|---|
|
JMSDeliveryMode, JMSTimeToLive and JMSPriority defined as types different from what the JMS specification uses. |
|
|
|
|
|
JMS bindingType and atLeastOne intent overlaps with setting JMSDeliveryMode |
|
|
|
|
|
JMS bindingType and conversation intent |
|
|
|
|
|
JMS bindingType and ordered intent - clarification needed |
|
|
|
|
|
Are JMS message selectors supported? |
|
|
|
|
|
What namespace(s) do we use for each binding? |
|
|
|
|
|
Rules for Binding compatibility |
|
|
|
|
|
Clarify the rules on which queues are used for responses and callbacks |
|
|
|
|
|
JMS binding URI should follow JMS IRI scheme submitted to IETF |
|
|
|
|
|
JMS binding pseudo-schemas inconsistent with assembly |
|
|
|
|
|
Properties on Bindings |
|
|
|
|
|
Normative reference consistency |
|
|
|
|
|
What is a "plain name" for a connection factories or activation specs, and how is one distinguished from a JNDI name? |
|
|
|
|
|
Document the attributes inherited from the base definition provided by SCA Assembly specification. |
|
|
|
|
|
Correlation property names are odd, and the space of options is not extensible. |
|
|
|
|
|
Clarify default function selection and data binding behavior |
|
|
|
|
|
Allow topics anywhere that queues can be used |
|
|
|
|
|
Clarify use of URI vs. uri |
|
|
|
|
|
Clarify rules around combination of destination, CF and AS elements |
|
|
|
|
|
How are mayProvide intents on bindings satisfied |
|
|
|
|
|
Conformance statement numbering |
|
|
|
Binding-ws
|
OASIS JIRA |
Description |
Tuscany TODO |
Tuscany JIRA |
Conformance |
---|---|---|---|---|---|
|
How should SCA callback semantics be carried over Web Services? |
|
|
|
|
|
portType referred to inconsistently throughout specification |
|
|
|
|
|
No bindingType for binding.ws |
|
|
|
|
|
Use of wsdli:wsdlLocation does not match WSDL 2.0 specification |
|
|
|
|
|
Rules for WSDL generation create invalid WSDL by using "/" where it is not allowed. |
|
|
|
|
|
What namespace(s) do we use for each binding? |
|
|
|
|
|
Namespace/location for WS-Addressing is incorrect in WebService binding spec/XSD |
|
|
|
|
|
binding.ws reference to assembly spec for interface mapping is incorrect |
|
|
|
|
|
Rules for Binding compatibility |
|
|
|
|
|
Web Service binding should allow #wsdl.binding with reference targets |
|
|
|
|
|
@wsdlElement definition needs clarification on "equivalent" and use of WSDL 2.0 constructs |
|
|
|
|
|
Properties on Bindings |
|
|
|
|
|
Normative reference consistency |
|
|
|
|
|
Document the attributes inherited from the base definition provided by SCA Assembly specification. |
|
|
|
|
|
Does WSDL binding take precedend over policy intents |
|
|
|
|
|
Clarify use of URI vs. uri |
|
|
|
BPEL
http://www.osoa.org/jira/browse/BPEL
|
OASIS JIRA |
Description |
Tuscany TODO |
Tuscany JIRA |
Conformance |
||||||
---|---|---|---|---|---|---|---|---|---|---|---|
|
support for BPEL4WS 1.1 |
|
|
|
|
Does the spec allow a componentType side file |
|
|
|
||
|
Correlation disagreement between SCA and BPEL |
|
|
|
|||||||
|
SCA-BPEL XML Namespaces |
|
|
|
|||||||
|
test issue please ignore |
|
|
|
|||||||
|
ComponentType should not contain implementation.bpel |
|
|
|
|||||||
|
Allow sca-aware processes to specify everything that can be specified in a CT side file |
|
|
|
|||||||
|
Allow Component Type side file to override defaults for service/reference |
|
|
|
|||||||
|
SCA-BPEL XML Schema |
|
|
|
|||||||
|
SCA-BPEL spec can not require bpel:mustUnderstand to be true |
|
|
|