W3C home > Mailing lists > Public > www-ws-desc@w3.org > June 2002

RE: issue: service type

From: <ryman@ca.ibm.com>
Date: Wed, 19 Jun 2002 15:25:29 -0400
To: "Jeffrey Schlimmer" <jeffsch@windows.microsoft.com>
Cc: www-ws-desc@w3.org, www-ws-desc-request@w3.org
Message-ID: <OFCBE19F1F.5091FA9D-ON85256BDD.00675A5F@torolab.ibm.com>

The cited posting makes an excellent case for supporting inheritence of
portTypes just like Java or C# interfaces can be inherited. In the example,
the extended tuner would inherit from the basic tuner. I agree with that
completely.

You asked how the case of a TV that contained two tuners would be handled.
This is a case of composition or aggregation, not inheritence. A TV is
composed of two tuners (among other things). There should be a portType
that represents the TV as a whole and a service that has one or more ports
of that portType. That leaves the question of how to design the TV
portType.

One way is to "promote" the operations of each tuner to the interface of
the TV, but that is awkward and has the disadvantage that a client that
understood the tuner portType would not immediately understand the TV
interface. By "promote", I mean to copy the operations to the TV portType
and rename them so they indicate the tuner. For example, if the tuner
contained the operation "advanceChannel", and the TV had two tuners, then
the TV portType would have new operations, "advanceChannel1" and
"advanceChannel2" which refered to tuner 1 and 2 respectively. As
mentioned, this obscures the fact that the TV contains devices that support
a well-known tuner portType.

One solution would be to allow operations that returned ports. The
interface to the TV would then have two operations, e.g. "getTuner1" and
"getTuner2" that would each return a port that implemented the tuner
portType. The semantics should be that any port returned by an operation
should use the same transport as the operation, i.e. if the operation uses
SOAP/HTTP then the returned port uses SOAP/HTTP. That way a client would be
guaranteed that it understood the transport used by the returned port.

If you don't want to enforce the same transport rule, then the operations
should return a service and the client can pick any of its ports.

To allow operations that return ports or services, we should define
standard WSDL messages as part of the spec.

In the TV example, I would create a single WSDL document that contained:
- a service for the TV that implements the TV portType (getTuner1 and
getTuner2)
- a service for tuner 1 that implements the tuner portType (advanceChannel)
- a service for tuner 2 that implements the tuner portType (advanceChannel)

Arthur Ryman



                                                                                                                                      
                    "Jeffrey Schlimmer"                                                                                               
                    <jeffsch@windows.micr       To:     <www-ws-desc@w3.org>                                                          
                    osoft.com>                  cc:                                                                                   
                    Sent by:                    Subject:     RE: issue: service type                                                  
                    www-ws-desc-request@w                                                                                             
                    3.org                                                                                                             
                                                                                                                                      
                                                                                                                                      
                    06/18/2002 03:07 PM                                                                                               
                    Please respond to                                                                                                 
                    "Jeffrey Schlimmer"                                                                                               
                                                                                                                                      
                                                                                                                                      




ryman@ca.ibm.com [mailto:ryman@ca.ibm.com] wrote:
>I think it's ok for a WSDL document to have more than one <service>
>elements.

+1

>However, I think it is confusing to have a <service> implement
>semantically different <port>s. I think the concept of a service would
have
>greater cohesion if the multiple ports were simply different ways to
access
>the same underlying service. Each port would be an alternate way,
differing
>perhaps in just the protocol used. That way the client can select any
port
>it understands and get the same result. The current WSDL forces you to
>define different portTypes because of problems in the binding
definitions
>(e.g. one for SOAP/HTTP, one for HTTP POST). If this is fixed, then the
>rule should be that all ports in a service implement the same portType.
Or
>if the serviceType proposal is accepted, then all ports in a service
>implement the same serviceType (here I assume the portTypes in a
>serviceType really define different sets of operations, i.e. they are
not
>just to accomodate different protocols).

If we retain the WSDL 1.1 rule about multiple ports being alternates to
the same underlying state, how would we support the two tuner use case?
From [1]: "When building a UPnP TV device, a vendor may wish to include
two analog TV tuners to support a feature like picture-in-picture."
Assuming you'd model a tuner as a port, the two ports would need to be
recognized as semantically different ports.

[1] http://lists.w3.org/Archives/Public/www-ws-desc/2002Apr/0205.html
Received on Wednesday, 19 June 2002 15:25:37 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:20 GMT