i026: Supporting Multiple Ports in EPRs: Initial proposal

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

Received on Saturday, 13 November 2004 03:22:33 UTC