On Thu, Apr 10, 2008 at 10:14 PM, Simon Laws <[EMAIL PROTECTED]> wrote:
> Hi Mike > > Some comments in line > > Simon > > > > > > > > > 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 > > > > > This JIRA covers a very specific scenario which adds another twist where > there is a different between the interface definition of a composite level > reference that promotes a component level reference. > > > > > > > > > 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). > > > > > It is certainly possible. Maybe even likely. But not guaranteed. > > > > > > > > > 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 proposed change is intended to at least raise a warning that there > is something amiss. > > > > > > > > > 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". > > > > > Interesting thought. I would say that the first baby step is to detect > when there is an issue (which we don't do at the moment). I seems that you > are suggesting that a future stage could be the configuration of the runtime > to add a namespace transformation if it can be detected if all else is > equal. Is that correct? > > > > > > > > > > > > > > > So to continue in the vein of detecting the underlying issue of TUSCANY-2109. Assuming that we think that's a good idea we need to be able to compare the namespaces in which interfaces are defined. We can't do this generally at the moment. There is no Interface.getNamespace() method. How about we add Interface.getNamespace() WSDLInterface.getNamespace() - returns the namespace from the WSDL definition JavaInterface.getNamespace - calculates the likely namespace from the java interface package name, i.e. get the package name, reverse the order of the dot separated words and add http:// in front of it. Simon
