Hi,
These are all good comments. I suggest that we carry on discussions on
tuscany-dev ML instead of JIRA :-).
Raymond
--------------------------------------------------
From: "Mike Edwards (JIRA)" <[email protected]>
Sent: Thursday, April 10, 2008 6:02 AM
To: <[email protected]>
Subject: [jira] Commented: (TUSCANY-2109) Conflicts between component
reference interface and promoted composite reference interface are not
detected
[
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
