OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsdm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [wsdm] WS-RF Resources vs. WSDM Resources

Fred, I basically agree with what you say, but, on the other hand, I totally disagree.  (And you’re undoubtedly going to say, “Here goes Wilson overanalyzing again”.  Unfortunately, as a former academic philosopher, overanalyzing is in my blood.  Sorry, can’t help myself.  And you should know, if you want to stay out of a discussion, don’t offer up a contribution—it only generates more “contributions” J.)


Anyway, here goes!  The WS-RF Resource specification provides TWO definitions: one for “resource” and one for “WS-Resource”.  WS-Resource is indeed a concept defined by WSRF and it can be whatever WSRF defines it to be.  (That’s the part I agree with.)  In the latest version of the spec, WS-Resource is defined as a composition of a resource and a Web service endpoint through which the resource can be accessed.  (ONE way to represent that in UML is as is done in the MOWS section 2.4 mind-map; namely, as an association class between a resource and an endpoint.  However, the example in the WSRF spec makes it clear that this is a 1:1 association, whereas the current version of the mind-map represents the association as many:many.  One of those mistakes—“lies”—in the 2.4 diagram.)  WSDM should use the notion of WS-Resource exactly as it is defined in the WSRF spec—I’m quite satisfied that MOWS is compliant here with WSRF.  The only difference is, as you point out, that the Web service endpoint (the association end) in WSDM is specifically a manageability endpoint.  WS-Resources were never an issue in this discussion.  (I have heard some intimations of an argument that would urge sending the whole notion of WS-Resource to the same fate as the Resource Access Pattern (RAP), but that is not at issue here.)


However, the situation is totally different when it comes to the definition of “resource”.  “Resource” is a term in common parlance; it is also a term that has technical definitions from the IETF (RFC 2396), W3C (WS Architecture), in RDF, and in probably a number of other source.  Against this background, the definition of “resource” offered in the WS-RF spec is, IMHO, both a restriction and an extension.  It is a restriction in the sense that it restricts a “resource” to “a logical entity” (something abstract, something that is part of a service implementation)—whereas in other definitions and in common parlance, resources can be or are generally physical things—and it is an extension in the sense that resources MUST have zero or more properties—the W3C definition of “resource” merely says a resource MAY have zero or more properties—and in the sense that a resource MAY have a life cycle.  Since the definition of “WS-Resource” follows the definition of “resource” in the WS-RF spec, one must assume that the WS-Resource definition uses “resource” in this restricted/extended sense.  When I have referred to a WS-RF Resource, I have meant it as a means of referring to the precise definition of “resource” in the WS-RF spec, not the technical definition of “WS-Resource”.  Thus, a WS-Resource is a composition of a WS-RF resource and an endpoint.


On the other hand, when I hear people talk about manageable resources (or “WSDM resources”), I get the mental sense (and I guess it is only a sense) that they are using “resource” in a more generic, more traditional, sense of “any resource”; in particular a “WSDM resource” is anything that I want to manage via Web service, which means that thing can be a physical thing (as long as it is exposed as a Web service) or a logical (abstract) resource (like a Web service itself), or even a WS-RF resource (MOWS applied to MUWS, see MOWS section 2.3—or even MOWS applied to MOWS (!?) ).  In fact, doesn’t MUWS Part 1 require a generic definition of “resource” that is independent of the WSRF specification?  Part 1 is all about defining what WSDM means by a manageable resource, and I always understood that WSRF stuff isn’t brought into the picture until Part 2.  Thus, I think it is a legitimate task of the editors to make sure the use of the word “resource” conveys appropriate meaning in a particular context.


By the way, is the statement you make—or anything like it--a direct quote from the spec or the primer?  (If so, it certainly needs to be revised immediately.)


Kirk Wilson
Architect, Development

Office of the CTO

802 765-4337


-----Original Message-----
From: fred carter [mailto:fcarter@amberpoint.com]
Sent: Monday, November 21, 2005 2:48 PM
Wilson, Kirk D
Subject: Re: [wsdm] WS-RF Resources vs. WSDM Resources


(I tried to stay out of this as long as possible.  Oh well...)

I don't understand the fuss about this.  WSRF defines a WS-Resource to be whatever they define it to be.  Those needing further explication can consult the references or complain vociferiously to that august body.

WSDM defines a WSDM Resource (really a WSDM WS-Resource) to be WS-Resources needful of management, analogous to how some bank might define a resource needful of money stuff.  Doing such a thing allows us to make statements of the following form with a relatively straight face (which is scary enough).

In our example, we show how to manage a printer. The manageability endpoint for the printer have a WSDM Resource which represents the printer.  Associate with the WSDM resources is, of course, a resource properties document that has information about the resource consumption (amount of paper, level of cyan ink, etc.).

Seems like we can go ape about the word all we want, but it's all pretty obvious from context.

// now going back into resist-the-resource-discussion mode

Wilson, Kirk D wrote:

One of the things we would like to do in WSDM 1.1 is to make sure that when the text refers to a resource, it is clear whether the reference is to a WS-RF Resource or a WSDM Resource.  The fundamental difference between the two, as I believe has been discussed, is that a WS-RF Resource is a “logical entity”, well, something abstract, whereas a WSDM is anything that is of interest to manage.  As editor of the MOWS spec, I started this AI to make sure the text was correct and consistent by looking at the so-called “mind-map” in section 2.4 of the MOWS spec.  The most significant thing that the diagram does over the corresponding (but slightly different diagram in section 2.3 of MUWS Part 1) is to make a Web service endpoint a “resource”.  Is that really what we want it to say—isn’t the “resource” under MOWS the Web service that is being managed, not its endpoint.  At any rate, the use of the “resource” still left open the whole question of what is the relationship between a WS-RF Resource or a WSDM Resource—which is it?


Also, I believe we have eliminated the notion of the “manageability capability interface” as a specifically specified “thing” that represents 1 manageability capability in recent decisions about what a Manageability Capability is. Is that correct, Bryan?  At least, it seems to be a subtlety that could be eliminated.


So, I have attached another mind-map, which, IMHO, better expresses the relationship of Resource, WSDM Resource and WS-RF Resource.  By just “Resource”, I refer to one of the general definitions of “resource”, e.g.,  IETF, W3C, or an RDF-definition. Comments would be appreciated—if only to make sure I’m on the right track.


This is also a “straw” poll for what to do about section 2.4 of MOWS?


1.      Keep the section and diagram as it current is?

2.      Replace with it with the attached (perhaps with minor tweaks)

3.      Whack the section and forget about having a “mind-map”.


Kirk Wilson
Computer Associates

Architect, Development
Office of the CTO
Tele: + 1 802 765-4337
Fax:   + 1 802 765-4339



To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in OASIS

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]