RE: Reference requirements

I am very concerned that we seem to be looking for a solution to a problem
that is fundamentally an architecture problem and not a description problem.
I think this problem needs to be discussed in the architecture WG.  I seem
to remember that similar discussion cropped in XMLP WG also and we soon
realized that there are many issues such as lifecycle and representation
issues that need to be addressed first.  

I would fully support if someone forwards a proposal on representing remote
references and instance IDs, if the proposal also addresses the lifecycle
issues and provides a model for representation, but not in the DESCRIPTION
activity.

I am cross-posting this to the architecture WG also to get some feedback
from that community also.

Thanks, 

 
_______________________________________________
Waqar Sadiq
 
EDS EIT EASI - Enterprise Consultant
MS: H3-4C-22
5400 Legacy Drive
Plano, Texas 75024
 
phone: +01-972-797-8408 (8-837)
e-mail: waqar.sadiq@eds.com
fax: +01-972-605-4071
_______________________________________________
 
 

-----Original Message-----
From: Jacek Kopecky [mailto:jacek@systinet.com] 
Sent: Wednesday, February 20, 2002 5:57 AM
To: Paul Prescod
Cc: www-ws-desc@w3.org
Subject: Re: Reference requirements

 Paul,
 we will be very glad if we can standardize our way of supporting 
remote references, and we'll welcome support from other W3C 
members if we try to submit a Remote references and Instance IDs 
spec as a W3C note.

 However, we will be equally glad if a different standard is
created and adopted and we can support that instead.

 In any case, the problem of remote references is two-fold:
 1) accessing different instances of a single service,
 2) referencing services and their instances.

 We can take your approach of extending the URI of the service 
with the instance ID, and it would solve both problems easily, 
but I feel nervous about this method because nowhere does it say 
that every URI scheme used for accessing Web Services will allow 
such extensions (thinking of email here).

 We can alternatively take the SOAP approach - create an 
extension that will carry that additional information inside a 
header. That's what we've taken. This solves the first problem 
and it somehow resembles the notion of "sessions".
 The second problem we solve by passing a structure which 
references a WSDL service (by its qname) and specifies the value 
of the instanceID for the service, for example:
    <reference>
      <wsdlUri>http://example.org/service.wsdl</wsdlUri>
      <wsdlService 
           xmlns:ns="urn:foo">ns:ServiceName</wsdlService>
      <instanceID>uuid:...</instanceID>
    </reference>
 In fact, the instanceID element in this structure can (and 
probably should) be viewed as an extension of this structure 
which without it serves quite sufficiently to reference whole 
services. This implies there can be other parameters in such a 
structure (if we don't move them to the WSDL description itself) 
and I think this is the proper way.

 Oh, then there are HTTP cookies, too, but that way lay madness. 
8-)

                   Jacek Kopecky

                   Senior Architect, Systinet (formerly Idoox)
                   http://www.systinet.com/



On Tue, 19 Feb 2002, Paul Prescod wrote:

 > Anne Thomas Manes wrote:
 > > 
 > > Systinet WASP supports remote references using a header element to
reference
 > > the instance id.
 > > 
 > > Anne Thomas Manes
 > > CTO, Systinet
 > 
 > That's great. Can we standardize it?
 > 
 > Even better...why not combine the endpoint URI and the instance ID
 > somewhat like this:
 > 
 > http://www.manes.net/service?instance=instanceID
 > 
 > I have other ideas beyond that but I'll let that one sink in. If you do
 > that then voila you've made it easy for every instance to be an endpoint
 > and all you need is a WSDL for it. Which puts the ball back in WSDL's
 > court. You need a way to say that the return value of a method will be a
 > URI like that and declare the WSDL that goes with that
 > instance-endpoint.
 > 
 >  Paul Prescod
 >

Received on Thursday, 21 February 2002 09:46:14 UTC