- From: <ryman@ca.ibm.com>
- Date: Tue, 2 Apr 2002 15:33:44 -0500
- To: Roberto Chinnici <roberto.chinnici@sun.com>
- Cc: www-ws-desc@w3.org
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 Tuesday, 2 April 2002 15:35:07 UTC