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
Feature |
OSOA Ref |
OSOA Description |
OASIS Ref |
OASIS Description |
|---|---|---|---|---|
Schema namespace |
|
|
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? |
|
|
|
|
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 |
|
|
|
|
Conflicting Specification of Values for Many-Valued StringProperties |
Adjust the property value processing to conform to the new syntax |
|
|
|
|
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 |
|
|
|
|
|
SCA <anyAttribute.../> declarations should use namespace ##other rather than ##any |
Update the xsd from OASIS |
|
|
|
|
Can Implementation change property values after instantiaion |
No action is required |
|
|
|
|
Missing XSD for contributions |
Update the xsd from OASIS. Update the Import/Export model to |
|
|
|
|
"SCA schema fixes requested for sca-core.xsd (based on OSOA site versions that may be copied to OASIS site)" |
|
|
|
|
|
Confusing words in Section 5.3 relating to ConversationalIntent |
|
|
|
|
|
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 |
|
|
|
|
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 |
|
|
|
|
|
Unresolved bindings on references |
Add the support for "componentName/serviceName/bindingName" as the wire target |
|
|
|
|
Component Type file name is too restrictive |
|
|
|
|
|
ComponentType Properties should not have a source |
|
|
|
|
|
Description elements in SCDL |
Support documentation element in the model and processors |
|
|
|
|
No schema or extension model definitions for contributions |
|
|
|
|
|
Assembly Specification should not state what marks a Javainterface as Local |
|
|
|
|
|
Implementation.composite pseudo-schema incorrect |
|
|
|
|
|
WSDL extension should not be required for conversations |
Make sure conversational intent is supported at interface and service |
|
|
|
|
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 |
|
|
|
|
|
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 |
|
|
|
|
Language neutrality edits |
|
|
|
|
|
some smaller things we need to fix in the assembly specification |
|
|
|
|
|
Need to clarify definition of Bidirectional Interfaces |
Make sure Tuscany is consistent with the specified behavior |
|
|
|
|
Conflicting domain-level <wire> deployments |
Tuscany needs to implement the proposal |
|
|
|
|
Identifying wire format and operation selection |
add "wireFormat" and "operationSelector" for bindings |
|
|
|
|
What is the default value for many and mustSupply on Properties? |
remove "mustSupply" from <component> |
|
|
|
|
SCA Composite Visibility |
This seems to be a clarification by the spec |
|
|
|
|
Composite Completeness |
Tuscany needs to add more validations to ensure the completeness of the composite for implementaiton.composite |
|
|
|
|
Compatability of component type side files |
Each implementation type has to decide how to support the componentType file |
|
|
|
|
Allow multiple definitions.xml files |
Tuscany should allow META-INF/definitions.xml from SCA contributions. These definitions become visible to the SCA domain |
|
|
|
|
Incorrect description of <Operation/> child elements inAssembly |
I see this conflicts with http://www.osoa.org/jira/browse/POLICY-58 |
|
|
|
|
Long-Running Request-Response Operations |
Tuscany needs to support the proposal |
|
|
|
|
Do we need appendix A (pseudo-schema)? |
No action is required |
|
|
|
|
Corrections to the contributions schema |
See ASSEMLY-28 |
|
|
|
|
"Section on ""Wire"" in Appendix is Incorrect" |
Tuscany already has the correct model, No action is required |
|
|
|
|
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 |
|
|
|
|
Add a Section documenting naming conventions to the start ofthe SCA Assembly Specification |
No action is required |
|
|
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 |
|---|---|---|---|---|---|
|
Spurious cast() method definition in ComponentContext interface |
|
|
|
|
|
Constructor name information may not be available |
Adjust the @Property/@Reference processor on CDI |
|
|
|
|
Java CAA spec does not contain the interface.java schema |
|
|
|
|
|
Incorrect definition of the SCA JEE JSP Tag library |
|
|
|
|
|
Inconsistent use of a and an when referring to annotations |
|
|
|
|
|
Normative references to SCA Spec docs point to v1.00 docs |
|
|
|
|
|
Missing word "type" for "return type" in CAA spec - sec 3.1 |
|
|
|
|
|
Incorrect description of @Scope annotation default |
Make sure the scope is default to "COMPOSITE" if there is an @Conversational |
|
|
|
|
Incorrect reference to "original request" |
|
|
|
|
|
Should not say callback ID is passed in reference parameters |
|
|
|
|
|
Incorrect code in section 6.7.2 example |
|
|
|
|
|
SCA Spring C & I specification does not state the purpose of sca:composite element |
Remove the sca:composite |
|
|
|
|
Describe the concurrency model for each scope |
|
|
|
|
|
SCA Spring Client and Implementation Specification uses an unacceptable namespace |
Update the namespace based on the OASIS spec |
|
|
|
|
When more than one interface with the same unqualified name used in the @Service annotation |
|
|
|
|
|
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 |
|
|
|
|
Version requirements for SDO, JAXB and JAX-WS |
|
|
|
|
|
@Callback annotation does not feature in section on Interfaces |
|
|
|
|
|
Missing description of what the @EagerInit annotation does |
|
|
|
|
|
@Reference annotation can also be used on a constructor parameter. |
|
|
|
|
|
Incorrect examples of methods annotated @Init and @Destroy |
|
|
|
|
|
Inconsistent method description for @Init and @Destroy annotations |
Tuscany already validates the pattern |
|
|
|
|
Incorrect generated service name |
|
|
|
|
|
Clarify Request Scope lifetime |
Remove the Request scope |
|
|
|
|
annotations on parameters |
@Reference, @Property can only be used for constructor parameters. Tuscany |
|
|
|
|
EJB remove method on EJBHome |
|
|
|
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 |
|---|---|---|---|---|---|
|
intents names defined by SCA should be defined using camel case |
|
|
|
|
|
How are mayProvide intents on bindings satisfied |
|
|
|
|
|
Clarify scope of ordered intent |
Add "ordered" intent support |
|
|
|
|
Limit policySet attachment to bindings |
|
|
|
|
|
Remove <operation/> elements from the specification |
|
|
|
|
|
Intents which conflict with binding configuration |
|
|
|
|
|
Clarify the handling of Intents |
|
|
|
|
|
Wire validation rules have changed |
|
|
|
|
|
How do we tell what a policySet @provides? |
|
|
|
|
|
Policy algorithm gets required intents from what interfaces definitions/declarations? |
|
|
|
|
|
How to configure policySets |
|
|
|
|
|
Need a clear way to distinguish Implementation Intents from Interaction Intents |
|
|
|
|
|
Infoset for policySet/@appliesTo |
|
|
|
|
|
Fix SCA Policy schema complex types for Qualifier and PolicySet |
|
|
|
|
|
Need Support for Mutually exclusive intents |
|
|
|
|
|
Improve description of the overides available to the two different hierarchies in SCA |
|
|
|
|
|
The URL for the location of the ws-policy.xsd is incorrect. |
|
|
|
|
|
Need more precision on when policies in a policySet are in effect |
|
|
|
|
|
Security implementation policy should be validate-able by schema |
|
|
|
|
|
More direct, structural qualifier definition |
|
|
|
|
|
Profile intent extension - provides other intents |
|
|
|
|
|
Should qualifiable intents have a default qualifier |
|
|
|
|
|
Need Transaction Policy Spec |
|
|
|
|
|
External mechanism for attaching intents or policySets |
|
|
|
|
|
Include definition on 'conversational' intent as mentioned in SCA Assembly |
|
|
|
|
|
Implicit addition of intents based on a service or reference's @requires list |
|
|
|
http://www.osoa.org/jira/browse/BINDINGS
|
OASIS JIRA |
Description |
Tuscany TODO |
Tuscany JIRA |
Conformance |
|---|---|---|---|---|---|
|
Clarify use of URI vs. uri |
|
|
|
|
|
Does WSDL binding take precedend over policy intents |
|
|
|
|
|
Allow topics anywhere that queues can be used |
|
|
|
|
|
Clarify default function selection and data binding behavior |
|
|
|
|
|
Correlation property names are odd, and the space of options is not extensible. |
|
|
|
|
|
JMS binding pseudo-schemas inconsistent with assembly |
|
|
|
|
|
JMS binding URI should follow JMS IRI scheme submitted to IETF |
|
|
|
|
|
Web Service binding should allow #wsdl.binding with reference targets |
|
|
|
|
|
Clarify the rules on which queues are used for responses and callbacks |
|
|
|
|
|
Rules for Binding compatibility |
|
|
|
|
|
binding.ws reference to assembly spec for interface mapping is incorrect |
|
|
|
|
|
Namespace/location for WS-Addressing is incorrect in WebService binding spec/XSD |
|
|
|
|
|
What namespace(s) do we use for each binding? |
|
|
|
|
|
Are JMS message selectors supported? |
|
|
|
|
|
Rules for WSDL generation create invalid WSDL by using "/" where it is not allowed. |
|
|
|
|
|
Use of wsdli:wsdlLocation does not match WSDL 2.0 specification |
|
|
|
|
|
No bindingType for binding.ws |
|
|
|
|
|
JMS bindingType and conversation intent |
|
|
|
|
|
JMS bindingType and atLeastOne intent overlaps with setting JMSDeliveryMode |
|
|
|
|
|
portType referred to inconsistently throughout specification |
|
|
|
|
|
JMSDeliveryMode, JMSTimeToLive and JMSPriority defined as types different from what the JMS specification uses. |
|
|
|
http://www.osoa.org/jira/browse/BPEL
|
OASIS JIRA |
Description |
Tuscany TODO |
Tuscany JIRA |
Conformance |
|---|---|---|---|---|---|
|
SCA-BPEL spec can not require bpel:mustUnderstand to be true |
|
|
|
|
|
SCA-BPEL XML Schema |
|
|
|
|
|
Allow Component Type side file to override defaults for service/reference |
|
|
|
|
|
Allow sca-aware processes to specify everything that can be specified in a CT side file |
|
|
|
|
|
ComponentType should not contain implementation.bpel |
|
|
|
|
|
test issue please ignore |
|
|
|
|
|
SCA-BPEL XML Namespaces |
|
|
|
|
|
Correlation disagreement between SCA and BPEL |
|
|
|
|
|
Does the spec allow a componentType side file |
|
|
|
|
|
support for BPEL4WS 1.1 |
|
|
|