W3C home > Mailing lists > Public > www-ws-arch@w3.org > September 2002

RE: service references (was: Re: WSA diffs from REST)

From: Anne Thomas Manes <anne@manes.net>
Date: Mon, 23 Sep 2002 19:58:04 -0400
To: "Paul Prescod" <paul@prescod.net>
Cc: "Sanjiva Weerawarana" <sanjiva@watson.ibm.com>, "Mark Baker" <distobj@acm.org>, <www-ws-arch@w3.org>, "Jan Alexandr" <alex@systinet.com>, "Radovan Janecek" <janecek@systinet.com>, "Jacek Kopecky" <jacek@systinet.com>

Hmmm ...

Good idea. There's no reason (that I can think of at the moment) why WASP
server couldn't generate a URI rather than an instance ID for the service
instance. The WASP runtime can just as easily map the URI as it does the
instance ID. I'll pass the idea by the chief architect.

It's that old CORBA/app server architecture mindset that permeates our
thinking: We have a single access point to a service, and our runtime does
the appropriate magic to map the request to an appropriate service instance.

See below for more detail on the WSDL...

> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Paul Prescod
> Sent: Monday, September 23, 2002 6:45 PM
> To: Anne Thomas Manes
> Cc: Sanjiva Weerawarana; Mark Baker; www-ws-arch@w3.org
> Subject: Re: service references (was: Re: WSA diffs from REST)
> Anne Thomas Manes wrote:
> > Systinet WASP has supported service references for more than a year. It
> > references a Web service by its WSDL port. To pass a service by
> reference,
> > you return the URI of the WSDL port, and you return an instance
> ID of the
> > service instance in a SOAP header. You can reconnect to the
> same instance by
> > dynamically connecting to the service (using a dynamic proxy or
> a DDI) and
> > specifying the instance ID in the SOAP header. The WSDL file
> for the service
> > indicates what types and headers are used in the service.
> I am curious why I must pass a URI and an instanceID to connect to a
> service instance rather than naming each service instance by a single
> resolvable URI as is done elsewhere on the Web?
> Also, I'd like to hear more about the WSDL. Obviously it is trivial to
> make a WSDL where a complexType "PO" is repeated or made optional
> through a parent's content model:
> <element name="purchase_orders">
>    <complexType>
>       <element name="po" minoccurs="0" maxoccurs="20">
>          <sequence>...</sequence>
>       </element>
>    </complexType>
> </element>
> Can I similarly refer to *references* to purchase order *services* (or
> port types)?

Do you mean, does the WSDL indicate that the remote reference is a purchase
order service rather than a insurance claims service? No. When passing back
a remote reference, the return message contains an element of type=anyURI.
Your application needs to dig into the WSDL to figure out what type of
service it is. Thanks. That's another nice suggestion.

>  >...
> > It would be nice to define a standard SOAP extension to
> accomplish services
> > by reference, but I don't view it as a top priority. We had a discussion
> > about service references on Apache axis-dev a while back, but
> it didn't go
> > anywhere.
> I objserve that an awareness of this issue is not widespread in the Web
> Services industry. Individual web service deployers invent one-off
> solutions (UDDIs, XPaths, handles) and because they do not yet care
> about interoperability BETWEEN web services, they see no problem with
> using home-grown solutions.

I wouldn't go so far as to say that we don't CARE. It's more a matter of
expediency. It takes a long time to establish consensus and create
standards. If the established specs don't define requested functionality
(stateful sessions, remote references, security, transactions, etc.) then
you have to create a one-off solution. Systinet's approach has always been
to create SOAP extensions that can be consumed by other SOAP
implementations, although in some cases you may need to work at a low-level
API to achieve interoperability. Systinet has also been quite open about its
extensions (everything is well documented and freely available).

Received on Monday, 23 September 2002 19:57:38 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:40:59 UTC