Â¥Ö÷

Web Resources and WS-Resources £¨Í¬Ê±¹Ø×¢SWºÍGridµÄÅóÓÑÖµµÃÒ»¶Á£© Web Resources and WS-Resources Posted Mar 2, 2005, 8:36 AM ET by Danny Ayers Although I¡¯m reasonably familiar with many aspects of Web services, I know little or nothing about some of the specifications that are now being used in grid computing (e.g. in the Globus Toolkit). I¡¯ve also spent quite a lot of time around the W3C¡¯s Resource Description Framework, so I thought I knew all there was to know about resources and their description. But it¡¯s hard to tell from first impressions whether the Web Service Resource Framework is something completely orthogonal to RDF concepts, a duplication of the same ideas with different expression in XML or somewhere in between. Articles have appeared in the past pointing to the crossover between RDF and Web Services, for example Uche Ogbuji¡¯s Supercharging WSDL with RDF, and there¡¯s a lot of work ongoing in the field of Semantic Web Services notably around OWL-S. I believe there¡¯s even some of the same people in Working Groups for both WS-*& SWS angles. When I cast my naive eyes over something like this ¡°Grid Computing & the Linda Programming Model¡± (PDF) it seems like it would make more sense to swap out the discrete, narrowly connected Linda and use the widely distributed Semantic Web as a tuplestore instead (virtually everything over HTTP, with RDF providing the base data model, RDFS and OWL providing richer semantics with inference, and the SPARQL query language looking after pattern matching). But to build a system that operated that way you¡¯d need communications between the HTTP/RDF parts and the SOA/Grid parts. Each of those parts is liberally covered in specifications, but do the same standards intersect (above and beyond XML)? So my basic question is how compatible are Web Services from the WSRF/Grid point of view with the Web from the Semantic Web point of view? I honestly don¡¯t know, and having to start somewhere I¡¯ll have a go at zooming out a little, and try and compare and constrast their different viewpoints of resources (something that seems quite fundamental), and a place where any points of intersection should be visible. Ok, so one conceptual view of resources may be found in RDF, a view which is generally consistent with Roy T. Fielding¡¯s Representation State Transfer (REST) view of the Web. A key part of the intersection between RDF and REST has been cemented in RFC 3986 Uniform Resource Identifier (URI): Generic Syntax. That provides rather a circular definition, a URI is something that identifies a resource, a resource is something identified by a URI. Whatever, a clear distinction is made between identifiers and representations, and perhaps more importantly the identification of resources is kept orthogonal from any resolution mechanism (such as HTTP). Now another kind of resource is that of OASIS¡¯s WSRF, specifically the WS-Resource (PDF) specification which defines a resource as follows: A resource is a logical entity that has the following characteristics: It MUST be identifiable; a resource has at least one resource identifier It MUST have a set of zero or more properties, which are expressible in XML infoset. It MAY have lifecycle. How does that compare with the resources of RFC 3986? Being identifiable is in that kind of resource¡¯s definition. The second point is a little weak for definition purposes - zero or more is quite a loose demand, and just about anything can be expressed in the XML infoset. So that point can be considered consistent, or at least there¡¯s not clear contradiction. The last point is trickier. Conceptually at least a URI-style resource is for ever, and a URI associated with that resource is eternally bound. Representations of resources certainly MAY have lifecycles, but from here it¡¯s hard to say whether that could be considered the same thing. It¡¯s also hard to tell whether if we assert that URI-style resources don¡¯t have lifecycles, they might still be acceptable by this definition given that it¡¯s only a MAY (is the definition talking about the whole class of resources or merely instances?). The WS-Resource spec also includes a definition of a resource identifier: A resource identifier embodies sufficient information required to distinguish one resource from all other resources within its scope of identification. That¡¯s pretty well satisfied by URIs in RFC 3986. The definition that follows in the WS-Resource spec is that of WS-Resources themselves, which are Web services through which a resource can be access. As a nitpick, the naming seems a little contrary, Resource-WS seems nearer. The definition of a WS-Resource then brings in the requirement that messages to a WS-Resource must contain a resource identifier. Nitpicking again, this would seem more fitting for the definition of a WS-Resource Message rather than the WS-Resource itself, although given as the ¡°WS-Resource Access Pattern¡± it does move it closer to where it¡¯s needed. Next there is a requirement that the set of properties of the resource MUST be expressed using an XML Infoset described by XML schema, and that the WS-Resource MUST support accessing resource properties through message exchanges defined by the WS-Resource Properties specification (WS-RP, PDF). I suppose is where the specification really starts appearing part of the SOAPy WS-fold. Abstracted from transport mechanisms and syntax, the RDF Property enables the construction of (binary) relations and as such is one of the fundamental constructs of the model. (It might be worth noting in passing that these properties are identified using URIs and as such are resources in their own right). Similar facilities to WS-RP can also be provided using WebDAV extensions to HTTP, where properties are pieces of data that describe the state of a resource. The core WebDAV spec (RFC 2518) does allow for properties to be expressed in XML. It¡¯s hard to tell without further digging whether this part of WS-Resource is diverging from the RESTful/HTTP direction, or whether WS-RP and WebDAV are merely slightly different abstractions/implementations of the same facility, which may be to some extent interchangeable. There¡¯s a slightly confusing and/or worrying crossover in terminology between the next part of the WS-Resource spec and some of the headaches the W3C¡¯s Technical Architecture Group have had when trying to pin down URIs (and URI accessories). The spec defines a WS-Resource reference as a representation through which a single WS-Resource can be accessed. A reference encapsulates a resource identifier and may contain other information necessary to access the WS-Resource. Perhaps unintentionally this could probably be mapped onto the base#fragment structure of some URIs, where: The fragment identifier component of a URI allows indirect identification of a secondary resource by reference to a primary resource and additional identifying information. But the idea that the syntax of a URI could be interpreted as a representation itself is getting into brain-melt territory, please consider that a digression¡­ The WS-Resource spec next brings in a useful-sounding construct, the WS-Resource Access Pattern Embodiment. With the Access Pattern defined previously as how the message finds its target resource, the embodiment is a concrete realization of such a pattern, and a WS-Resource MUST support at least one embodiment. The key word itself seems like it¡¯s come from a long session rifling through a thesaurus, ¡°embodiment¡± is used to refer to something a bit like ¡°implementation¡± and a bit like ¡°instance¡±. The intention does make sense though - it¡¯s kind-of demanding that the WS-Resource has to be usable. The WS-Resource spec goes on to describe a WS-Addressing Embodiment, a WSDL 1.1 Service Element Embodiment, WSDL 1.1 Binding Element Embodiment and WS-Message Delivery Embodiment. Each of these are covered down to the XML elements that would appear. All of these embodiments make fairly extensive use of URIs. Now I can still only really talk from the point of view of first impressions, but it seems to me that the WS-Resource approach seems generally more concrete than the resource abstraction of RDF. I think it likely that WS-Resource constructs could be modelled in RDF. However, the emphasis of WS-Resource is very much on the protocol, so this isn¡¯t really comparing like with like. It does seem that WS-Resource follows the tunnelled-message approach found throughout the WS-* raft, rather than the more transparent, FIPA-ACL-like messaging of HTTP methods. But despite there being some misaligned of terminology, I get the impression that WS-Resource isn¡¯t some much reinvention of (URI-style) resources and their description, rather a communication language built from the same starting points. Which looks good from the point of view of compatibility. One of the justifications for the Grid¡¯s SOA using WSRF on top of just SOAP/WSDL (and one or two other WS-bits) is to provide statefulness. I¡¯m still a little confused on that point. I can see how state can be managed using WS-Resources, but what I having discovered is why the assumption is made that because SOAP++ messaging is usually done statelessly, it has to be that way. State can (and often is) maintained at both client and server sides of communications. If state that is global across client and server is needed then that can be maintained using one of the many reliable messaging protocols possible on top of HTTP. So although I¡¯m reasonably comfortable that there¡¯s potential compatibility between the WSRF approach and RESTful techniques, I am still rather puzzled why the former was considered necessary for grid¡¯s stateful SOA. The answer to that almost certainly doesn¡¯t matter.    Êղؠ  ·ÖÏí   ¶¥(0)

----------------------------------------------

-----------------------------------------------

µÚÊ®¶þÕµÚÒ»½Ú¡¶ÓÃROR´´½¨ÃæÏò×ÊÔ´µÄ·þÎñ¡·
µÚÊ®¶þÕµڶþ½Ú¡¶ÓÃRestlet´´½¨ÃæÏò×ÊÔ´µÄ·þÎñ¡·
µÚÈýÕ¡¶RESTʽ·þÎñÓÐʲô²»Í¬¡·
InfoQ SOAÊ×ϯ±à¼­ºú¼üÆÀ¡¶RESTful Web ServicesÖÐÎÄ°æ¡·
[InfoQÎÄÕÂ]½â´ðÓйØRESTµÄÊ®µãÒÉ»ó