RE: WS-Addr issues

I don't think wsa:Action has anything to do with what I'm talking about.
 
We have a product [1] that is capable of messaging/invoking over numerous protocols, transports, and formats, all under a WSDL umbrella. We view a service essentially as a collection of one or more ports. There are cases where we have intermediaries that can accept incoming messages and, in a fully dynamic manner, further dispatch or route those onward. The trick is that the next recipient might use a completely different protocol/transport/format than what the message came in on. For this case we perform a fully dynamic dispatch by using the target's WSDL definition and to build dynamic proxies and to bind to the service over one of the protocol/transport/format combinations it supports. We need the whole definition so we have access to all the possible bindings for the service. We also use the WSDL definition in cases where consumer applications want to avoid compiling in static port type information, and instead want, for flexibility purposes, late (runtime) binding to the service.
 
In thinking more about this issue, and contrary to my response to Dave yesterday, even the WS-MetadataExchange approach Jim and Dave discussed is problematic for us. This is because we might be directly integrating existing legacy systems over their existing native protocols and formats, and it's often the case for such systems that they can't be rebuilt or touched in any way, which means they can't be changed or augmented to respond to such metadata requests. This is fairly common in the real world as customers try to renovate their existing enterprise systems and extract value from what they already have without being forced to completely redo everything. Up until now, including a URL for the complete WSDL definition in our product's proprietary service reference has allowed us to handle this common case, and so we'd like it to also be possible with the WS-Addressing standard.
 
--steve
 
[1] http://www.iona.com/products/artix/

-----Original Message-----
From: Sanjiva Weerawarana [mailto:sanjiva@watson.ibm.com]
Sent: Wednesday, November 03, 2004 2:43 PM
To: public-ws-addressing@w3.org
Subject: Re: WS-Addr issues


Hi Steve,
 
What's your view of dispatching with wsa:Action? Since those are required
to be unique that gives enough info to find the operation to dispatch
to within a service. The service itself is of course identified from
the <To> somehow.
 
Sanjiva.

----- Original Message ----- 
From: Vinoski, Stephen <mailto:Steve.Vinoski@iona.com>  
To: Doug Davis <mailto:dug@us.ibm.com>  
Cc: public-ws-addressing@w3.org 
Sent: Thursday, November 04, 2004 12:58 AM
Subject: RE: WS-Addr issues

+1 to having a pointer to the WSDL itself in the EPR. We have found in working with our customers that having access to the service definition is critical for applications that rely on pure dynamic dispatching.
 
--steve

-----Original Message-----
From: Doug Davis [mailto:dug@us.ibm.com]
Sent: Wednesday, November 03, 2004 11:02 AM
To: public-ws-addressing@w3.org
Subject: WS-Addr issues



I might have missed a formal request for "issues" from the public but since it appears there is now an issues list I thought I'd make some suggestions on possible issues for the WG's consideration: 

issue: EPRs have WSDL bits - e.g. PortType, ServiceName.  But no pointer to the actual WSDL itself - why not?  W/o the WSDL do these values mean anything?  And if we assume the consumer of the EPR has the WSDL why can't we assume they know the PortType and ServiceName?  Perhaps an example of how this would be used would clarify it for me. 

issue: If a response message is expected then a wsa:ReplyTo MUST be included.  Does the absence of a wsa:ReplyTo imply a one-way message?  The spec seems to come very close to saying that.  And does the presence of wsa:ReplyTo imply a two-way message?  My preference would be to have a clear statement so that upon inspection of the message itself a processor can know if its a one-way or two-way w/o having to go back to the wsdl. 

issue: wsa:FaultTo:  "This property may be absent if the sender cannot receive fault messages (e.g. is a one-way application message)."  But it also says that in the absence of wsa:FaultTo the wsa:ReplyTo/From may be used.  So, how does a client really say that it doesn't want ANY fault messages at all but still be allowed to specify a wsa:From? 

thanks 
-Doug