RE: WS-A Issue 27 - Reference to WSDL definition in an EPR

I don't know if this was cleared up in tghe unsuing discussion on Monday (I've been deep in other meetings), but what we would like is an optional wsdl11:Definition and, for 2.0, an optional wsdl20:Description to be a part of the EPR specification.  This is needed for the use case I outlined in the issue definition.
 
--Rebecca

-----Original Message-----
From: David Orchard [mailto:dorchard@bea.com]
Sent: Thursday, November 04, 2004 12:02 PM
To: Bergersen, Rebecca; public-ws-addressing@w3.org
Cc: Newcomer, Eric; Vinoski, Stephen
Subject: RE: WS-A Issue 27 - Reference to WSDL definition in an EPR



Rebecca, I don't see what you are proposing.   You say a reference to the WSDL definition of a service is sometimes required and must be included.

 

Is it that EPR adds an optional wsdl20:Location?  Is it that EPR adds an optional wsdl11:Definition and wsdl20:Description as optional elements?  

 

I don't think you are proposing that a wsdl definition is required for all cases, hence it's optional.  

 

Can you provide a more detailed proposal?

 

Thanks,

dave

 


  _____  


From: public-ws-addressing-request@w3.org [mailto:public-ws-addressing-request@w3.org] On Behalf Of Bergersen, Rebecca
Sent: Thursday, November 04, 2004 8:51 AM
To: public-ws-addressing@w3.org
Cc: Newcomer, Eric; Vinoski, Stephen; Bergersen, Rebecca
Subject: WS-A Issue 27 - Reference to WSDL definition in an EPR

 

ISSUE 27 - Reference to WSDL definition in an EPR

  According to the ws-addressing submission, "Endpoint references convey the information needed to identify/reference a Web service endpoint, and may be used in several different ways: endpoint references are suitable for conveying the information needed to access a Web service endpoint...."  However, in order to assure that the information needed to access a Web service endpoint, a reference to the WSDL definition of a service is sometimes required and in those cases must be included as part of the EPR construct.

 

This requirement derives from several common use cases. For example, in a communication chain there may be intermediaries that can accept incoming messages and, in a fully dynamic manner, further dispatch or route those onward. This is what we do with our products.  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 it is necessary to 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. The whole definition is required so there is access to all the possible bindings for the service. The WSDL definition is also used 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.