Re: i026: Supporting Multiple Ports in EPRs: Initial proposal

Steve:

Option 1 assumes that the reference properties for each port access are 
the same.  This is reasonable assumption
in many or most cases, but is it always true?

Option 2 pays a big penalty if the ref properties are the same for each 
endpoint.   Perhaps, if we go this direction,
we could have a "common" set of ref proerties at the hightest level of 
nesting of this syntax.  The ones in the per
endpoint level would be concatenated to those at the highest level.

Tom Rutt

Vinoski, Stephen wrote:

>Issue i026 [1] is about supporting multiple ports in EPRs. This message
>contains two possible approaches to solving this issue. Because there
>are two approaches here, the language and solution specification are not
>as tight as they'd be expected to be for a formal issue resolution proposal.
>I'd like to get more WG input on the two approaches described here before
>working on a more complete and tighter proposal.
>
>In practice, some services have multiple ports. For example, a service
>might make itself available over multiple different protocols because
>it must maintain legacy protocol access while also supporting access
>over newer protocols.
>
>WSDL 1.1 [2] defines a service as an entity that "groups a set of related
>ports together." It goes on to say:
>
>"If a service has several ports that share a port type, but employ
>different bindings or addresses, the ports are alternatives. Each port
>provides semantically equivalent behavior (within the transport and
>message format limitations imposed by each binding). This allows a
>consumer of a WSDL document to choose particular port(s) to
>communicate with based on some criteria (protocol, distance, etc.)."
>
>WSDL 2.0 [3] tightens up the WSDL 1.1 language to a degree by defining
>a service component as "a set of endpoints at which a particular deployed
>implementation of the service is provided." With respect to these
>endpoints, it further states that "the endpoints thus are in effect
>alternate places at which the service is provided." Note that the
>definition of "endpoint" in this context in WSDL 2.0 is pretty
>clearly synonymous with the use of "port" in the same context in
>WSDL 1.1.
>
>WSDL thus clearly allows services to have multiple ports, but the current
>WS-Addressing EPR definition [4] allows only a single port per service.
>The current definition of the WS-Addressing EPR makes it clear that the
>EPR is intended to complement, not replace, the WSDL 1.1 <wsdl:service>
>element. However, the final paragraph of section 2 of [4] discusses the
>expected evolution of EPRs as follows:
>
>"We expect solutions built on WSDL/1.1 to continue to utilize a
>service element. Moving forward we anticipate that endpoint references
>and WSDL will evolve coherently. The endpoint references may link
>to service elements in WSDL/1.1, and support additional scenarios
>in which the WSDL information is not known by a party processing
>a message. These scenarios may include dynamic messaging or
>limited capability message processors."
>
>In addition to the "additional scenarios" described in the quoted text
>above, other scenarios exist in which a true service reference, not
>just an EPR, is required. One such scenario is when a service must be
>made known to another party in such a way that information about all
>of its ports is made available, not only one such port as an EPR
>allows. For example, when registering a callback reference with
>another party, it's often preferable to let that party know all the
>ports over which the service to be called back is available, so that
>that party can choose the port it prefers to use to call back to the
>service. In general, making the entire service definition known,
>rather than just one of its ports, allows the receiving party to
>choose which port to use.
>
>One suggested workaround for the problems described in the preceding
>paragraph is to add an optional URI for a service's WSDL definition
>to the EPR. Changing the EPR in that fashion does have certain benefits,
>especially for dynamic applications that do not have static knowledge
>of the referenced service. However, it doesn't solve all such cases.
>There are scenarios in which there is an unacceptable negative
>performance impact of remote access to a WSDL definition in order for
>a party processing a message to learn about a service's definition in
>order to contact it.
>
>Another suggested workaround for a multi-port reference is to send
>multiple EPRs, one for each port. There are at least two problems with
>this approach. The first is that it pushes the problem up a level to a
>point where different applications will handle the case differently,
>thus hindering or even preventing interoperability. Another problem is
>one of being able to properly correlate multiple EPRs as all referring
>to the same service, or preventing a sender from sending multiple
>unrelated EPRs where multiple EPRs to the same service are expected.
>
>Including port information by value in the EPR or service reference is
>an obvious way, already proven in other distributed systems, to solve
>issue i026. Either of the following two ways of addressing this issue
>are preferable to the workarounds described above:
>
>1. Augment the existing EPR with an optional element that contains
>by value information about alternative service ports and addresses.
>
>2. Create a new reference container type that can hold one or more EPRs.
>
>The first approach would add the following abstract property to section
>2.1 of WS-Addressing:
>
>[alternative-ports]: wsa:ports (0..1)
>   This is an optional list of alternative ports at which the service
>   identified by the [service-port] property is also available.
>
>For this new property, wsa:ports would be defined as something like
>the following:
>
><xs:complexType name="ports">
>  <xs:sequence>
>    <xs:element name="port" maxOccurs="unbounded">
>      <xs:complexType>
>        <xs:sequence>
>          <xs:any minOccurs="0" maxOccurs="unbounded"/>
>        </xs:sequence>
>      </xs:complexType>
>    </xs:element>
>  </xs:sequence>
>  <xs:attribute name="name" type="xs:NCName" use="required"/>
></xs:complexType>
>
>This approach essentially includes WSDL port definitions by value as
>an optional element of the EPR.
>
>A port's address would be specified as one of the xs:any elements
>within the port element.
>
>If this optional element is included in the EPR, the EPR is also expected
>to include a [service-port] property. For this case, the current [address]
>property and [service-port] property would refer to the "default" endpoint
>at which the service could be reached, and the addresses and ports
>specified in the [alternative-ports] property would be considered as
>alternative endpoints for the service.
>
>One problem with this approach is that it effectively turns an EPR into
>a service reference, making the name "endpoint reference" a misnomer.
>Approach 2 described above addresses this problem by introducing a
>separate service reference type that can hold one or more EPRs. Such a
>reference would look something like this:
>
><wsa:ServiceReference>
>  <wsa:EPR>wsa:EndpointReference</wsa:EPR> +
>  <wsa:ServiceName PortName="xs:NCName"?>xs:QName</wsa:ServiceName>
></wsa:ServiceReference>
>
>The service reference type holds one or more EPRs. It also contains a
>service name element that is common across all the EPRs, overriding any
>service names specified by any of the individual EPRs.
>
>The merit of the first approach is that it adds straightforward optional
>information to the existing EPR. The drawback is, as noted above, that it
>turns the EPR into a service reference, which is really something other
>than an EPR as currently defined.
>
>The merit of the second approach is that it adds a new entity and leaves
>the existing EPR intact, and is thus less invasive with respect to the
>current WS-Addressing spec. The drawback is also that it adds a new
>entity, thus complicating the spec.
>
>I'd like to get further WG input on these two approaches before continuing
>work on issue i026.
>
>--steve
>
>[1] http://www.w3.org/2002/ws/addr/wd-issues/#i026
>[2] http://www.w3.org/TR/wsdl#_services
>[3] http://www.w3.org/TR/wsdl20/#Service
>[4] http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr-core.html#_Toc77464317
>
>  
>

-- 
----------------------------------------------------
Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133

Received on Monday, 15 November 2004 19:41:33 UTC