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

I've seen two schools of thought around this subject.

One that believes it should be a URI regardless, and would often interpret
URI to mean an accessible URI (a URL, in fact). In this case, when I create
the purchase order I would use the URI http://myserver.com?poNum=1234. The
obvious risk here is that tomorrow I will be using the service at
http://yourserver.com to access the purchase order, and the client
application will attempt to use the URI to access the service by talking to
the wrong server.

The other shcool of thought believes that the instance ID should be based on
the type that is most applicable. It could be an eleven digit type, or an
alphanumeric, or it could be a URI. There are identifiers out there that are
based served by URI. But if you subscribe to this school of thought you
understand that the URI is not necessarily an accessible resource, but
merely an encoding scheme for an identifier. For example, urn:po:1234 could
be a valid URI scheme for a purchase order number. You could use it equally
as well with the service at http://myserver.com or http://yourserver.com.

By saying that the instance ID should be an identifier of some type, and any
simple type is allowed, we allow it to also be a URI, without accidentally
going down the road of accessible URLs.

arkin


True ... but an instance ID is just a label for an instance. There's no
reason why the instance ID can't conform to the format of a URI.

> -----Original Message-----
> From: Assaf Arkin [mailto:arkin@intalio.com]
> Sent: Monday, September 23, 2002 8:29 PM
> To: Paul Prescod; Anne Thomas Manes
> Cc: Sanjiva Weerawarana; Mark Baker; www-ws-arch@w3.org
> Subject: RE: service references (was: Re: WSA diffs from REST)
>
>
> You will find that this approach is quite common. For example, when you're
> updating a record in the database you open a connection to the database
> (service) and identify the record in the SQL statement. You can write the
> application to deal with records in any database if you keep a distinction
> between the record identifier and server identifier. You can also use
> identifiers that have business meaning, e.g. a purchase order number,
> employee number, etc.
>
> Yes, this doesn't look consistent with other aspects of the Web
> or the REST
> approach, that prefer that each entity have a unique address. But it does
> allow you to perform various operations on objects regardless of which
> service you are using. It could be http://myserver.com today,
> http://yourserver.com tomorrow, but you will always operate on the same
> purchase order.
>
> arkin
>
>
> 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)?
>
>  >...
> > 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.
>
>   Paul Prescod
>

Received on Monday, 23 September 2002 20:56:23 UTC