Why do we need to be so strict in comparing interfaces? Can't we argue essentially the same point in the case with we have a Java client w/ reference w/ Java intf with a <binding.ws>?
So, following this logic, it's suggested that the NS calculated per-JAXWS for the Java intf must match the portType on the WS binding. So, in the case (2) that Mike presented, say the Java is gen'd from the WSDL of an existing WS w/ wsimport, embedding a @WebService(name = "...", targetNamespace = "...") in the Java. Now the WS evolves and we take the new WSDL w/ portType in a new NS. Maybe a new operation is added but we don't care about it from our existing client. Why should we have to re-gen the Java to reflect the new TNS? Also, someone using an older W2J tool may have an option to select a non-standard pkg when generating Java from WSDL, but the tool doesn't reflect this in the @WebService(... targetNamespace...). Do we really need to break them? Would people agree this is essentially the same case as the overridden, promoted intf, or is the argument that this specific case is a bit different ? I mean, I can certainly see how it simplifies the runtime authors' lives to be strict about NS's when doing intf mapping... but do we really have a good reason to? What use case can we just not handle that would make us need this restriction? Scott On Thu, Apr 17, 2008 at 12:09 PM, Raymond Feng <[EMAIL PROTECTED]> wrote: > +1 on Simon's proposal to add the getNamespace() on Interface from another > perspective: converting/mapping between IDLs. > > Thanks, > Raymond > -------------------------------------------------- > From: "Simon Laws" <[EMAIL PROTECTED]> > Sent: Thursday, April 17, 2008 6:32 AM > To: <tuscany-dev@ws.apache.org> > Subject: Re: [jira] Commented: (TUSCANY-2109) Conflicts between component > reference interface and promoted composite reference interface are not > detected > > > 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 >> >> > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
