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? > > > > > > > >
