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 <[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: <[email protected]>
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]
