Re: WS-Addr issues

+1

-Anish
--

Vinoski, Stephen wrote:

> 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
>         <mailto: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
>             <mailto: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

Received on Friday, 5 November 2004 01:06:37 UTC