Re: Should a Service Implement a Single PortType?

Arthur,

Thanks for the clarification.

In principle, I like the idea of a client being able to choose between
several equivalent endpoints, but in practice this may be a lot harder
than it seems.

First of all, it's hard to say what it means for two endpoints to be
the same when binding considerations can greatly affect the client
view of a service. Of course, this won't happen as long as the choice
is between a SOAP/HTTP binding and an HTTP GET binding,
but as bindings become more sophisticated the differences between
them will grow considerably.

Consider for instance a one-way operation with a binding that
guarantees delivery and the same operation with a fire-and-forget
binding. Although a client can in principle select either endpoint,
the client application logic will often be completely different in
order to compensate for the difference in semantics between
the two (bound) operations. Moreover, some of the differences
cannot be accounted for just by looking at the bindings, because
they really depend on the semantics of the operations themselves.

Things get even more complicated in the case where a client will start
working against one endpoint and, upon encountering an error (e.g. a
dropped network connection), decides to switch over to another
endpoint. In that case, it's even harder to make assumptions on
the state of the service based on binding information alone.

So, it seems to me that, for the feature you describe to be genuinely
useful, we need to go beyond the static view of web services that WSDL
currently offers and start looking at considerations about service semantics
and client-server interaction patterns in potentially extended conversations.

All this to say that I prefer option (3), i.e. keep the basic concepts (such
as <service/>) as simple as possible ("a service is a grouping of endpoints",
without any implications on the relationships between them) and introduce
other concepts as needed.

Roberto

--
Roberto Chinnici
Java and XML Software
Sun Microsystems, Inc.


ryman@ca.ibm.com wrote:

> Roberto,
>
> I agree with Sanjiva that there are use-cases where multiple interfaces are
> required and that this should be a requirement. Here multiple interfaces
> means possibly completely unrelated interfaces and is not the notion of one
> interface extending several other interfaces. i.e. service1 contains
> endpoint1 and endpoint2, and endpoint1 implements interface1, and endpoint2
> implements interface2.
>
> The proposal below was that all endpoints of a service should implement the
> same interface, have equivalent behavior, and only differ in the transport
> or location used. The client would pick the endpoint that suited its needs.
> This makes the way the service is accessed orthogonal to the interface
> implemented by the service. With this definition, a service has a
> well-defined behavior that can be accessed in one or more ways.
>
> I see the following alternatives:
>
> 1. Leave the definition of <service> the way it is and place no restriction
> on what interfaces the endpoints implement.
>
> 2. Adopt the above restriction and semantics of <service> and introduce a
> new grouping concept (to be defined) to handle the requirement for
> supporting multiple interfaces.
>
> 3. Introduce some other concept to represent a set of endpoints that
> implement the same interface.
>
> Arthur Ryman
>
> phone: 905-413-3077, TL 969-3077
> assistant: 905-413-2323, TL 969-2323
> fax: 905-413-4920, TL 969-4920
> intranet: http://w3.torolab.ibm.com/~ryman/
>
>
>                     Roberto Chinnici
>                     <roberto.chinnic       To:     Sanjiva Weerawarana <sanjiva@watson.ibm.com>
>                     i@sun.com>             cc:     www-ws-desc@w3.org
>                     Sent by:               Subject:     Re: Should a Service Implement a Single PortType?
>                     www-ws-desc-requ
>                     est@w3.org
>
>
>                     04/02/2002 12:23
>                     PM
>                     Please respond
>                     to Roberto
>                     Chinnici
>
>
>
> I concur with Sanjiva that a web service may well consist of
> multiple endpoints supporting different interfaces. I also would
> very much like to see the concept of service become first class
> through the introduction of <serviceType/> definitions.
>
> About Jacek's proposal of reusing the <definitions/> element for the
> purpose of grouping endpoints: the <wsdl:definitions/> element is
> analogous to <xsd:schema/> and establishes the target namespace
> for all the definitions it contains (including those in extensions).
> It seems to me that if we reused it for the purpose of creating
> a service type, we'd lose the namespace declaration aspect
> and we'd end up needing another container element anyway.
>
> I'd also be interested in understanding Arthur's proposal better.
>
> By inspecting a WSDL document, a client can already find out
> that several of the endpoints exposed by a service are of the
> same type (port type, that is). Is the purpose of allowing only
> ports with the same port type in a service to make this
> determination even easier?
>
> From a client point of view, there is still no indication that, say,
> PortA and PortB, both implementing interface I, are equivalent.
> It may well be that the behaviors of the two endpoints differ
> wildly, and yet a client has no indication of that. Was then
> the proposal intended to rectify that, i.e. by saying that all ports
> in a service must not only be of the same type but also behave
> the same way, under some suitable definition of "same"?
>
> Roberto
>
> --
> Roberto Chinnici
> Java and XML Software
> Sun Microsystems, Inc.
>
> Sanjiva Weerawarana wrote:
>
> > I disagree that a service should be restricted to a single
> > portType. There are lots of services which are naturally
> > best represented by multiple interfaces (portTypes)- having
> > a description language that cannot describe those naturally
> > is broken IMO. If we restrict to multiple portTypes, why
> > not go all the way down to one operation? After all, we can
> > do everything with just that too .. ;-).
> >
> > Jacek, you make a point below about an abstract analog of
> > a service that I personally like:
> >
> > >  If, on the other hand, we really want to group multiple
> > > interfaces into one, the logical "one" should be called something
> > > like serviceGroup or something.
> >
> > I use the term "serviceType" for this- basically a name for
> > the set of portTypes that comprise a service's function. Then,
> > one or more services can support that service type.
> >
> > Sanjiva.
> >
> > ----- Original Message -----
> > From: "Jacek Kopecky" <jacek@systinet.com>
> > To: "Arthur Ryman" <ryman@ca.ibm.com>
> > Cc: <www-ws-desc@w3.org>
> > Sent: Friday, March 29, 2002 6:50 PM
> > Subject: Re: Should a Service Implement a Single PortType?
> >
> > > Hi,
> > >  I second this request because now the WSDL service is really
> > > somewhat too general.
> > >  If a service's ports were to implement the same portType, that
> > > would truly mean different accesspoints to the same service.
> > >  If, on the other hand, we really want to group multiple
> > > interfaces into one, the logical "one" should be called something
> > > like serviceGroup or something.
> > >  I can see the meaning and usefullness of the relationship
> > > between different accesspoints to the same portType, but the
> > > relationship between two portTypes in a service is everything but
> > > clear.
> > >  I think the WSDL <definitons> (if named) can successfully imply
> > > the general relationship between the different services defined
> > > therein, so we don't need the general service construct.
> > >  Best regards,
> > >
> > >                    Jacek Kopecky
> > >
> > >                    Senior Architect, Systinet (formerly Idoox)
> > >                    http://www.systinet.com/
> > >
> > >
> > >
> > > On Thu, 28 Mar 2002, Arthur Ryman wrote:
> > >
> > >  > In WSDL 1.1 a service is a set of ports. Each port could in
> principle
> > be
> > >  > bound to a different portType. I think this is too general. It would
> be
> > >  > simpler if every port in a service was bound to a single portType.
> > >  >
> > >  > In practice this was not possible because the binding rules for HTTP
> > GET
> > >  > and POST required slightly different portTypes than SOAP. However,
> if
> > >  > this problem is fixed, then should we require all ports to uses the
> > same
> > >  > portType within a service?
> > >  >
> > >  > This is really not much of a restriction, since you can easily
> define
> > >  > multiple services and can reuse common types and messages via an
> > import.
> > >  >
> > >  > Having a service implement a single portType would give it more
> > >  > cohesion.
> > >  >
> > >  > -- Arthur Ryman
> > >  >

Received on Wednesday, 3 April 2002 13:33:59 UTC