DUE TO SPAM, SIGN-UP IS DISABLED. Goto Selfserve wiki signup and request an account.
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 |
|---|---|---|---|---|
|
for implentations.*'s fix attributes that should show qnames as values |
|
|
|
|
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 |
|
|
|
usage of not promoted references |
Make sure the reference resolution follows what's described by the assembly spec |
|
|
|
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 |
|
|
|
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 |
|
|
|
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 |
|
|
|
|
Confusing words in Section 5.3 relating to ConversationalIntent |
|
|
|
|
"SCA schema fixes requested for sca-core.xsd (based on OSOA site versions that may be copied to OASIS site)" |
|
|
|
|
Description elements in SCDL |
Support documentation element in the model and processors |
|
|
|
No schema or extension model definitions for contributions |
|
|
|
|
component type allows to specify wire targets on references |
Push teh getTargets() method from Reference to ComponentReference |
|
|
|
Assembly Specification should not state what marks a Javainterface as Local |
|
|
|
|
Implementation.composite pseudo-schema incorrect |
|
|
|
|
Conflicting Specification of Values for Many-Valued StringProperties |
Adjust the property value processing to conform to the new syntax |
|
|
|
WSDL extension should not be required for conversations |
Make sure conversational intent is supported at interface and service |
|
|
|
XSD definitions of Component Service and Component Referencehave unintended features |
|
|
|
|
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 |
|
|
|
Need for a Callback annotation for WSDL interface files |
Tuscany needs to handle sca:callback extensibility elements in WSDL |
|
|
|
Component URI is not well described |
Tuscany needs to support the structural URI based on this proposal |
|
|
|
SCDL artifact resolution underspecified |
Adjust the artifact resolution based on the proposal in this JIRA |
|
|
|
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 |
|
|
|
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 |
|
|
|
Add a Section documenting naming conventions to the start ofthe SCA Assembly Specification |
No action is required |
|
|
|
Corrections to the contributions schema |
See ASSEMLY-28 |
|
|
|
Duplicated atributes in sca-binding-sca.xsd and sca-implementation-composite.xsd |
No action is required |
|
|
|
"Section on ""Wire"" in Appendix is Incorrect" |
Tuscany already has the correct model, No action is required |
|
|
|
Do we need appendix A (pseudo-schema)? |
No action is required |
|
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 |
Action |
|---|---|---|
Spurious cast() method definition in ComponentContext interface |
|
|
Constructor name information may not be available |
|
|
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 |
|
|
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 |
|
|
Describe the concurrency model for each scope |
|
|
SCA Spring Client and Implementation Specification uses an unacceptable namespace |
|
|
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 |
|
|
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 |
|
|
Incorrect generated service name |
|
|
Clarify Request Scope lifetime |
|
|
annotations on parameters |
|
|
EJB remove method on EJBHome |
|
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 |
Action |
|---|---|---|
intents names defined by SCA should be defined using camel case |
|
|
How are mayProvide intents on bindings satisfied |
|
|
Clarify scope of ordered intent |
|
|
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 |
|
Bindings
http://www.osoa.org/jira/browse/BINDINGS
OASIS JIRA |
Description |
Action |
|---|---|---|
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. |
|
BPEL
http://www.osoa.org/jira/browse/BPEL
OASIS JIRA |
Description |
Action |
|---|---|---|
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 |
|