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

Being an "old CORBA guy," I can assure you that someone of the "old CORBA mindset" would never pass or use an ID in the manner you've described. CORBA effectively has a uniform segmented (or hierarchical) identification scheme -- for something like IIOP, for example, an object reference uses a host-port-OA-object identification scheme, and when sending a message it conceptually first gets to the host, then to the port, then to the object adapter, and finally to the object. This approach is critical to CORBA's vast scalability (when implemented properly) because it allows the infrastructure to not have to track individual objects -- instead, it needs to track only object adapters, each of which can contain millions, billions, or practically an infinite number of objects.

CORBA in fact supports an equivalent URI scheme named corbaloc that is just an alternate representation of object references. The scheme is also uniform, and it doesn't require embedding additional identification information elsewhere in messages. (Note also that CORBA object references can carry transport/protocol information for many different schemes simultaneously, both through the use of multiple profiles and through the use of multi-component profiles, which means that even if a service can be reached over a single transport/protocol or 10 different ones, only a single object reference is needed in both cases.)

The "single URI with embedded identifier" approach that so many SOAP toolkits take appears to be due to embedding the receiver under a single servlet that uses SOAP header info to further dispatch incoming messages. You might cry foul and say that this is no different than what I described above, but it really is different because in CORBA, the location/identification system is uniform -- it's all handled by the object reference -- whereas with what you described, and what many SOAP toolkits do, is non-uniform in the sense that the URI gets you to the servlet, and then a second disjointed location/identification mechanism tunneled in the message gets you from there to the service itself. The difference in these two approaches is quite large. Uniformity matters.

--steve

> -----Original Message-----
> From: Anne Thomas Manes [mailto:anne@manes.net]
> Sent: Monday, September 23, 2002 7:58 PM
> To: Paul Prescod
> Cc: Sanjiva Weerawarana; Mark Baker; www-ws-arch@w3.org; Jan Alexandr;
> Radovan Janecek; Jacek Kopecky
> Subject: RE: service references (was: Re: WSA diffs from REST)
> 
> 
> 
> 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).
> 
> Anne
> 
> 
>

Received on Tuesday, 24 September 2002 01:02:13 UTC