You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Scott Kurz <sc...@gmail.com> on 2008/05/16 17:47:02 UTC
Re: [jira] Commented: (TUSCANY-2109) Conflicts between component reference interface and promoted composite reference interface are not detected
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 <en...@gmail.com> wrote:
> +1 on Simon's proposal to add the getNamespace() on Interface from another
> perspective: converting/mapping between IDLs.
>
> Thanks,
> Raymond
> --------------------------------------------------
> From: "Simon Laws" <si...@googlemail.com>
> Sent: Thursday, April 17, 2008 6:32 AM
> To: <tu...@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 <si...@googlemail.com>
>> 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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: [jira] Commented: (TUSCANY-2109) Conflicts between component reference interface and promoted composite reference interface are not detected
Posted by Scott Kurz <sc...@gmail.com>.
Since no one objected to the understanding we reached in this thread, shall
we close out TUSCANY-2109?
I'd like to summarize by saying that we agree that when doing interface
matching, namespaces of the interfaces will not be matched.
(Not sure if there is a context I'm not considering which would make that
too broad a statement, however.)
Scott
Re: [jira] Commented: (TUSCANY-2109) Conflicts between component
reference interface and promoted composite reference interface are not detected
Posted by Simon Nash <na...@apache.org>.
Scott Kurz wrote:
> On Fri, May 16, 2008 at 1:04 PM, Simon Nash <na...@apache.org> wrote:
>
>> Scott Kurz wrote:
>>
>>> 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?
>>>
>>> Adding a new operation would be a compatible change to the interface
>> and should not result in the interface's TNS changing.
>>
>
> I'm imagining an organization rolls out a whole new deployment of some
> service, and changes the TNS
> in various WSDL/XSDs to reflect that this is version 2.0, or whatever, of
> the deployment. They wouldn't have
> to change the TNS, but they might want to, right?
>
If they do this when not necessary, they are accepting the need to
also upgrade all the clients that talk to these services.
>
>> 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?
>>>
>>> This is easy to deal with by configuring the reference binding to
>> refer to the WSDL binding that the client code is actually using
>> to make the invocation. If the reference binding.ws doesn't specify
>> any WSDL binding, the binding.ws's interface contract should be
>> generated from the reference's interface.java.
>
>
> Maybe I'm reading into the discussion too much but I was assuming that being
> proposed was doing
> a similar sort of interface compatibility testing between the Java client's
> intf.java and the binding.ws
> WSDL intf contract. In other words, I thought we were getting at the point
> that, in Tuscany across the board, IDLs would
> only be considered as matching if they matched "namespaces" (the IDL-neutral
> equiv. of TNS, Java pkg, etc.).
>
OK, I think I understand now. You are talking about compatibilty
checking between a reference's interface.java and the same
reference's explicitly specified binding.ws WSDL binding.
In this case, I think the namespace information should come from
the reference's binding.ws WSDL binding and not from the
interface.java, and should not be a problem if the interface.java
has a different namespace.
Applying the same reasoning to the promoted case, I think I
was wrong when I said earlier that it's a problem if the namespace
for the inner interface doesn't match the namespace for the outer
interface. According to the rule proposed above, interface
namespaces should always be ignored, so the interfaces would match.
The binding.ws WSDL binding namespace would be derived from the
outer interface, and any namespace information on the inner
interface would not be used.
> If this is not what others had in mind, then wrt to the interface
> compatibility testing being proposed,
> this case does differ from the promoted ref intf case and will be treated
> separately. That's one of the
> questions I was asking.....
>
>
>
>> 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
>>> ?
>>>
>>> It seems pretty similar to me.
>> 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?
>>>
>>> The use case that triggered TUSCANY-2033 and TUSCANY-2109, where an
>> incorrect namespace was sent on the wire because SCA did not detect
>> the reference/service mismatch.
>>
>> This problem is caused by a mismatch in the WSDL binding rather
>> than a mismatch in the Java interface. However, the specs say that
>> the WSDL binding (including its namespace) is generated by applying
>> the JAX-WS Java2WSDL mapping to the Java interface. If this
>> algorithm doesn't produce the same namespace that's used by the
>> service, the reference won't be able to interoperate with it.
>>
>> Simon
>>
>>
> There's another angle to view this from in which the error is not caused by
> a mismatch, per se, but rather
> by the fact that the <intf.wsdl> used to configure the promoted reference is
> not honored.
>
Yes, I agree with this now. See above.
> Why is the Java2WSDL done at all, when the user has described the interface
> with a WSDL? So why does it
> matter that the Java2WSDL we would have done doesn't match the WSDL we have
> in hand?
>
In this case, no Java2WSDL should be done, as you say.
Simon
> Scott
>
Re: [jira] Commented: (TUSCANY-2109) Conflicts between component reference interface and promoted composite reference interface are not detected
Posted by Scott Kurz <sc...@gmail.com>.
On Fri, May 16, 2008 at 1:04 PM, Simon Nash <na...@apache.org> wrote:
> Scott Kurz wrote:
>
>> 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?
>>
>> Adding a new operation would be a compatible change to the interface
> and should not result in the interface's TNS changing.
>
I'm imagining an organization rolls out a whole new deployment of some
service, and changes the TNS
in various WSDL/XSDs to reflect that this is version 2.0, or whatever, of
the deployment. They wouldn't have
to change the TNS, but they might want to, right?
>
> 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?
>>
>> This is easy to deal with by configuring the reference binding to
> refer to the WSDL binding that the client code is actually using
> to make the invocation. If the reference binding.ws doesn't specify
> any WSDL binding, the binding.ws's interface contract should be
> generated from the reference's interface.java.
Maybe I'm reading into the discussion too much but I was assuming that being
proposed was doing
a similar sort of interface compatibility testing between the Java client's
intf.java and the binding.ws
WSDL intf contract. In other words, I thought we were getting at the point
that, in Tuscany across the board, IDLs would
only be considered as matching if they matched "namespaces" (the IDL-neutral
equiv. of TNS, Java pkg, etc.).
If this is not what others had in mind, then wrt to the interface
compatibility testing being proposed,
this case does differ from the promoted ref intf case and will be treated
separately. That's one of the
questions I was asking.....
>
> 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
>> ?
>>
>> It seems pretty similar to me.
>
> 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?
>>
>> The use case that triggered TUSCANY-2033 and TUSCANY-2109, where an
> incorrect namespace was sent on the wire because SCA did not detect
> the reference/service mismatch.
>
> This problem is caused by a mismatch in the WSDL binding rather
> than a mismatch in the Java interface. However, the specs say that
> the WSDL binding (including its namespace) is generated by applying
> the JAX-WS Java2WSDL mapping to the Java interface. If this
> algorithm doesn't produce the same namespace that's used by the
> service, the reference won't be able to interoperate with it.
>
> Simon
>
>
There's another angle to view this from in which the error is not caused by
a mismatch, per se, but rather
by the fact that the <intf.wsdl> used to configure the promoted reference is
not honored.
Why is the Java2WSDL done at all, when the user has described the interface
with a WSDL? So why does it
matter that the Java2WSDL we would have done doesn't match the WSDL we have
in hand?
Scott
Re: [jira] Commented: (TUSCANY-2109) Conflicts between component
reference interface and promoted composite reference interface are not detected
Posted by Simon Nash <na...@apache.org>.
Scott Kurz wrote:
> 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?
>
Adding a new operation would be a compatible change to the interface
and should not result in the interface's TNS changing.
> 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?
>
This is easy to deal with by configuring the reference binding to
refer to the WSDL binding that the client code is actually using
to make the invocation. If the reference binding.ws doesn't specify
any WSDL binding, the binding.ws's interface contract should be
generated from the reference's interface.java.
> 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
> ?
>
It seems pretty similar to me.
> 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?
>
The use case that triggered TUSCANY-2033 and TUSCANY-2109, where an
incorrect namespace was sent on the wire because SCA did not detect
the reference/service mismatch.
This problem is caused by a mismatch in the WSDL binding rather
than a mismatch in the Java interface. However, the specs say that
the WSDL binding (including its namespace) is generated by applying
the JAX-WS Java2WSDL mapping to the Java interface. If this
algorithm doesn't produce the same namespace that's used by the
service, the reference won't be able to interoperate with it.
Simon
> Scott
>
>
>
> On Thu, Apr 17, 2008 at 12:09 PM, Raymond Feng <en...@gmail.com> wrote:
>
>> +1 on Simon's proposal to add the getNamespace() on Interface from another
>> perspective: converting/mapping between IDLs.
>>
>> Thanks,
>> Raymond
>> --------------------------------------------------
>> From: "Simon Laws" <si...@googlemail.com>
>> Sent: Thursday, April 17, 2008 6:32 AM
>> To: <tu...@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 <si...@googlemail.com>
>>> 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: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>