[
https://issues.apache.org/jira/browse/TUSCANY-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12587629#action_12587629
]
Mike Edwards commented on TUSCANY-2109:
---------------------------------------
Folks,
It is right to be concerned over the interface matching, but let's not lose
sight of the context here.
In general, there are two scenarios to consider:
a) the reference is to a service which is defined within the SCA domain and SCA
means are used to wire it
b) the reference is to a service which is outside the SCA domain and wiring is
through configuration of a specific binding and target endpoint
In case a) it is possible that a Java interface as used by the client in its
reference is exactly the same (file) as is being used by the provider in the
service interface. If this is so, then in general, even if WSDL is generated,
the reference and the target service are going to match, assuming that the same
rules are followed at both ends for generating WSDL. (They should be following
JAX-WS according to the specs).
In case b), the normal situation would be for the client to be constructed
using a Java interface derived from the target WSDL using the WSDL2JAVA
tooling. While the reference targets the original service from which the WSDL
came, there should be no problem, even if the reference itself is typed in
terms of the Java interface.
Things get interesting if the target service gets changed - and if the WSDL
describing the interface changes. Now, to first order, you might say that if
the WSDL is different, how do you know that the new service is compatible with
the old one? Even if the operation names match and the input and output
messages have the same structure, if the namespaces differ, there is no
guarantee that the two services are actually compatible.
This is an area where ESB style mediations come into play. Let's assume that
the target service does use a different namespace, but that the operations and
messages otherwise map. There is still a mediation necessary, since the
transmitted messages will use the "wrong" namespace - the mediation simply has
to remap the namespace when sending and receiving messages. More complex
mediations are possible, where perhaps the operation names and message names
don't match, although the structure and semantics do match.
The question for us folks in SCA-land is whether we want to model mediations of
this type as explicit components, with services and references that match the
reference and endpoint that they are trying to mediate, or whether we want to
extend our bindings definition to allow configuration of mediations "within the
bindings". The explicit component always works - and it can in principle
perform much more complex meditations too (eg wholesale message
trasnformation). The question is more whether it could be simpler, for simple
mediations, to manage the mediations "within the bindings".
Yours, Mike.
> Conflicts between component reference interface and promoted composite
> reference interface are not detected
> ------------------------------------------------------------------------------------------------------------
>
> Key: TUSCANY-2109
> URL: https://issues.apache.org/jira/browse/TUSCANY-2109
> Project: Tuscany
> Issue Type: Bug
> Components: Java SCA Core Runtime
> Affects Versions: Java-SCA-1.1
> Environment: All
> Reporter: Simon Nash
> Assignee: Simon Laws
> Fix For: Java-SCA-Next
>
> Attachments: jira2109.patch, jira2109.zip
>
>
> See TUSCANY-2033 for the background to this problem.
> When a component reference defined with <interface.java> (either explicitly
> or implicitly by introspection) is promoted to a composite reference defined
> with <interface.wsdl>, and there is a namespace conflict between the
> component reference's <interface.java> and the composite reference's
> <interface.wsdl>. this conflict should be diagnosed as an error because it
> violates the spec rule that an interface specified on a composite reference
> must be a compatible superset of the interface of the promoted component
> reference. In this case, the composite interface is incompatible with the
> component reference because it has a different namespace.
> There is code in CompositeWireBuilderImpl.connectCompositeReferences() to
> handle connections between composite references and promoted compoennt
> references. The only interface processing performed in this method is to copy
> the component reference's interface contract to the composite reference's
> interface contract if the composite reference does not have an interface
> contract. Code should be added here to check for conflicts between the
> composite reference's interface and the component reference's interface if
> both interfaces are specified.
> Similar code should be added to
> CompositeWireBuilderImpl.connectCompositeServices() to check that the
> composite service interface is a compatible subset of the component service
> interface as required by the spec.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
