- From: Thompson, Bryan B. <BRYAN.B.THOMPSON@saic.com>
- Date: Mon, 7 Jul 2003 14:27:20 -0400
- To: Francis McCabe <fgm@fla.fujitsu.com>, "Thompson, Bryan B." <BRYAN.B.THOMPSON@saic.com>
- Cc: Anne Thomas Manes <anne@manes.net>, "Www-Ws-Arch@W3. Org" <www-ws-arch@w3.org>, "Bebee, Bradley R." <bebeeb@US-McLean.mail.saic.com>
Frank, FYI, I like the organizational frame that you are proposing in terms of message oriented model, service oriented model and resource oriented model. I think that one of the strengths of HTTP is that it does adddress concerns from each of these levels, but that also is a source of its complexity. One of the use cases that we have is XML document, using a variety of different XML vocabularies, that use Xlinks to express linking relationships among those documents and to non-XML documents. In an HTTP world we can assume that the URI for the service interface for the document is the same as the URI for the document itself. A web browser uses this assumption when it applies the GET method to recover a representation of the XML document, which might then be styled for display to a user. As we move to enable dynamic service interface description discovery with WSDL, and beyond that to support the dynamic discovery of the semantics for an interface, its "contract", I think that it is important that we retain the ability to deploy documents that embed hyperlinks. If I read your suggestion correctly, you are saying that we should rely on a layer above WSDL in order to make the assertion that the service interface instance and the resource have the same URI. I would be concerned that a generation of services would be unable to use hyperlinking while we standardize the means for making that assertion! Perhaps this goes back to your comment that HTTP is a weird animal that crosses several model levels. It sounds like you are suggesting that we need SOAP + WSDL + (DAML-S/OWL/SWIF) before we can describe services that have the property that the resource and the service interface share the same URI. If this is your suggest, then how do we deal pragmatically with this issue until we have the next layer in place? -bryan -----Original Message----- From: Francis McCabe [mailto:fgm@fla.fujitsu.com] Sent: Monday, July 07, 2003 2:06 PM To: Thompson, Bryan B. Cc: Anne Thomas Manes; Www-Ws-Arch@W3. Org; Bebee, Bradley R. Subject: Re: Fw: Naming a Web service resource Bryan: Stipulated, that you may want to be able to identify a resource with a service description. It is just that targetresource is not the way to do it (again, in my opinion). I do not see the need to have a WSDL-level element that identifies *the* resource. A better solution is to permit a proper integration with an OWL-level description with a WSDL document. That way, if you want to do things like targetResource, you do it in OWL/RDF whatever, in a somewhat application-specific manner. Using OWL/DAML etc. gives you a whole class of power that you cannot embed directly into a WSDL document (nor should you). As for bridging the Web and Web services, I think that the appropriate model looks like this: The resource oriented model `sits on' (I have a much better term, but its technical: supervenes) the service oriented model. The service oriented model `sits on' the message oriented model SOAP is a technology at the MOM level, WSDL is a technology at the SOM. HTTP is a weird animal that crosses all the levels, but is fundamentally a ROM-level technology. This level crossing is a source of confusion for many. One of the reasons that everyone wants to use HTTP as a message transport is because of tunneling. But in a few years, I hope that that reason will have gone away, in favor of a more consistent and sustainable story. Certainly, every month, using HTTP gets more problematic as corporations strengthen their firewalls. Frank On Monday, July 7, 2003, at 10:22 AM, Thompson, Bryan B. wrote: > > Frank, > > I am not sure if I am reading your first point correctly. I see that > it is > critically important that it is _possible_ to have the same URI serve > to > identify > both the service interface instance and the resource on which that > service > is > operating. This is the case today with HTTP. We have a problem with > WSDL > 1.1 > precisely because it does not make it possible to do the same thing > with > SOAP. > Ideally, we want to be able to have both a SOAP and an HTTP interface > defined > at the same URI as the resource. This has the further implication > that the > method name must not be part of the URI for the service interface. > > For example, given: > > http://www.myorg.org/foo112 > > You should be able to write WSDL that indicates that this URI > identifies: > > 1. a resource, with an HTTP interface (POST, PUT, GET, DELETE, HEAD). > and 2. a SOAP service, with some arbitrary set of method signatures. > > I do understand that people may not always want to bind the service > interface and the resource on which the service is operating to the > same URI. > However > I > view the ability to do this as vital. If you can not express this > notion > then > it is not possible to bridge the architecture of the web and the > architecture > of web services. > > -bryan > > > -----Original Message----- > From: Francis McCabe [mailto:fgm@fla.fujitsu.com] > Sent: Monday, July 07, 2003 12:55 PM > To: Anne Thomas Manes > Cc: Www-Ws-Arch@W3. Org > Subject: Re: Fw: Naming a Web service resource > > > > Anne: > This topic has been discussed a little in WSA. I can give you my > personal view on this; it is not one that is necessarily shared ;-) > > 1. The targetResource concept is, IMO, a brain-dead idea. The > principal reasons being: > > a. The resource that a service manipulates may not be identifiable in > any obvious way b. A service may be inherently `about' a dynamic set > of resources, and therefore it becomes onerous to identify them in the > service description c. > The action-oriented level of description implicit in a service > description is not the appropriate level to discuss resources. > > However, who am I to say what WSD gets up to? > > 2. Web services *do* have identity; and hence can be expected to have > a URI. However, that does not imply that a Web service has a > meaningful > representation: > a. For a simple, atomic, service, one might assert that the binding > address of a service is a good candidate for the service identity. > However, that seems too low-level and too transport specific. b. The > service > description of a service is a potential candidate for > the service representation, but different descriptions of the same > service are likely. > c. A composite service, in the sense of a transparently composed > service, is different to its component services and yet essentially > unknown to the component parts. A simple example: a service composing a > weather service with a language translation service to give weather > reports in foreign languages. Ideally, one should be able to build such > a service with no programming: simply by hooking together the weather > service and the translation service. The service description amounts to > a particular choreography over existing services. The foreign language > weather service is still a service, and still had an identity (it may > be composed further, by linking with an import-export service to > predictively order umbrellas say). > > So, the upshot seems to be that a Web service has an identity, but > that that identity is closer in spirit to the namespace uri than a web > page uri. > > Frank > > On Friday, July 4, 2003, at 07:10 AM, Anne Thomas Manes wrote: > >> >> I'm not getting much response from the ws-desc team on this issue, >> and it occurs to me that it might be of more interest at the arch >> level. >> >> Some background: The WS-Desc team has proposed the introduction of an >> optional attribute called targetResource to provide some additional >> discovery metadata to reference the "thing" behind a Web service >> interface -- for example, it can help you discover that different >> service interfaces provide access to the same thing. To some degree, >> this attribute is tied to the groups decision to limit a service to a >> single interface, >> because now you need a mechanism to express that fact that multple >> services >> are related in some way. >> >> Thinking through this scenario, I've realized that one of the must >> unwebby features of the Web services framework is that a Web service >> doesn't have a >> URI. It has a description (WSDL). It has one or more endpoints. But >> there is >> no one URI that represents the resource that *is* the Web service. >> >> Reading through the various documents that describe URIs and the Web >> architecture, it seems obvious to me that a Web service is an >> "important" Web resource, therefore it should have a URI. >> >> I'd appreciate it if the WS-Arch group would discuss this issue. >> >> Anne >> >> ----- Original Message ----- >> From: "Anne Thomas Manes" <anne@manes.net> >> To: <cordau@acm.org>; <www-ws-desc@w3.org> >> Sent: Wednesday, July 02, 2003 11:43 AM >> Subject: Naming the service resource >> >> >>> >>> See inline... >>> ----- Original Message ----- >>> From: "Ugo Corda" <cordau@acm.org> >>> To: <www-ws-desc@w3.org> >>> Sent: Saturday, June 28, 2003 3:48 PM >>> Subject: Re: Minutes of W3C WSDWG Conference Call, June 26th, 2003 >>> >>> >>>> Anne, >>>> >>>> Let me see if I understand you correctly. I think you are saying >>>> two >>> things. >>>> >>>> a) A serviceURI is a way of associating a URI with a particular >>> wsdl:service >>>> (single interface), so that this URI abstracts away the individual >>> endpoints >>>> and associated URIs. >>>> >>>> This is fine with me. The URI of the WSDL document plus the >>>> fragment identifier mechanism gives us that type of URI right away. >>> >>> My suggestion is that we name the *service resource*, as opposed to >>> the interface to the service or the definition of the service. I >>> don't think >>> that it's appropriate to use the WSDL document plus fragment >>> identifier >> for >>> this purpose, because the fragment identifier is the URI of the >>> definition of the service, not the service itself. The serviceURI >>> would give us the >>> ability to directly associate this definition with the thing that it >>> defines. Also consider the fact that the service resource might be >>> defined >>> using some other type of description language, such as DAML-S, and it >> would >>> be very useful to have a definition-language neutral mechanism to >>> refer to this resource. (Now that I think about it, I think this >>> point is probably >>> the most important point in my argument.) >>> >>> A week ago or so I asked whether a process can be a resource, and a >>> REST-oriented person (I forget who, now--sorry) responded, "yes". >>> Way back (at least a month ago), Sanjiva made a comment in response >>> to one of the questions regarding targetResource that we have no >>> name for the thing >> behind >>> the interface, which--unless I'm missing something fundamental >>> here--is >> the >>> service resource. IMHO such a resource should have a name. It's very >>> un-Webby not to name an important resource. I'd like to think that >>> this >> idea >>> was the basic concept behind targetResource -- but then we started >>> talking about naming the thing that the service acts upon rather >>> than the service >>> itself (e.g., the printer rather than the print queuing/management >>> services). I'm totally in agreement with Mark (!) that identifying >>> the >> thing >>> that the service acts upon is too much implementation detail. >>> >>>> b) A serviceURI is a way of abstracting away a particular >>>> wsdl:service document instance, so that I could change some of the >>>> endpoint URIs >> under >>>> that wsdl:service (and generate a new WSDL document) and still >>>> refer to >>> the >>>> same serviceURI. >>> >>> The serviceURI names the service resource. It has nothing to do with >>> abstracting away a wsdl:service document instance. The wsdl:service >> document >>> instance defines some aspect of a service resource, hence it should >> specify >>> the resource that it is defining. A service resource may have >>> multiple endpoints, and these endpoints may change. But it's still >>> the same >> resource. >>> Here's a simple analogy: Ugo Corda has many endpoints -- email >>> addresses, postal addresses, phone numbers, etc. Ugo may change some >>> of these endpoints. He may get new ones, he may get rid of some. But >>> he's still Ugo >>> Corda. >>> >>>> I am not sure we need this. We could just keep the endpoints the >>>> same >>> while >>>> changing the underlying implementation and/or deployment. (To take >>>> your parallel with a Web site's home page, the Yahoo home page is >>>> always http://www,yahoo.com regardless of any change in the >>>> underlying implementation and deployment). >>> >>> That's exactly my point. http://www.yahoo.com names the Yahoo home >>> page, which is a resource. The URI isn't the definition of the >>> resource. It >> isn't >>> the endpoint of the resource (that would be >> http://www.yahoo.com/index.html >>> or something like that). It names the resource. The implementation >>> of the resource can change, and things still work. >>> >>>> Regarding the use case of a single service implementing multiple >>> interfaces, >>>> that "service" will actually be a bunch of wsdl:service's, and this >>>> particular type of relationship among them could be addressed by >>>> the >>> service >>>> group solution. >>> >>> Perhaps, but how would you indicate the type of relationship in the >> service >>> group? And how would this solution allow me to discover that a >> wsdl:service >>> definition and a DAML-S definition in fact define different aspects >>> of the same service? >>> >>>> (As you can see, I am taking a minimalist approach and trying to >>>> avoid introducing new concepts unless they appear to be absolutely >>>> necessary). >>>> >>>> Ugo >>>> >>>> ----- Original Message ----- >>>> From: "Anne Thomas Manes" <anne@manes.net> >>>> To: "Ugo Corda" <UCorda@SeeBeyond.com>, <www-ws-desc@w3.org> >>>> Date: Sat, 28 Jun 2003 07:57:02 -0400 >>>> Subject: Re: Minutes of W3C WSDWG Conference Call, June 26th, 2003 >>>> >>>> >>>> Ugo, >>>> >>>> My proposal for point 1 is simply the assignment of a name (a URI >>>> -- >> let's >>>> call it serviceURI) to a service implementation (a resource). As >>>> with >> any >>>> resource, there's no reason why you can't change the code that >> implements >>>> this resource. >>>> >>>> In many respects, it is equivalent to assigning a URI to a Web >>>> site's >> home >>>> page. There's nothing stopping you from changing the code behind >>>> the Web page (in fact it happens all the time). >>>> >>>> I proposal the serviceURI SHOULD NOT be the same as the endpoint >>>> URL of >>> the >>>> service implementation -- for exactly the reason that you may want >>>> to >>> change >>>> its implementation some time down the road. >>>> >>>> And I think I agree that the new wsdl:service definition looks >>>> pretty >>> close >>>> to being right for the definition of a service implementation -- >>>> but I suggest that the resource MUST have a serviceURI name. Given >>>> the naming >> of >>>> the service implementation, I'm not sure we then need >>>> targetResource >>>> -- >> or >>>> perhaps it could be added to the service group definition as a >>>> means to identify the relationship among the services in the group. >>>> >>>> By naming the service implementation, you also solve the use case >>>> where >> a >>>> single service might implement multiple interfaces -- you would >>>> still maintain the one service/one interface requirement, but you >>>> could define multiple service implementations that reference the >>>> same serviceURI. >>>> >>>> Anne >>>> >>> >> >
Received on Monday, 7 July 2003 14:27:42 UTC