[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsdm] WS-RF Resources vs. WSDM Resources
Thanks for the extensive reply, Fred. And, yes, Happy Thanksgiving to all.
Considering the comments I got, I have undertaken (for the 50th time) a revision of the mind-map. But I think the value of the exercise is diminishing and section should be deleted.
I’ll be posting a new version of the MOWS 1.1 spec on Monday.
Office of the CTO
preliminaries. Happy Thanksgiving to everyone (mostly US folks who care,
but Happy Thursday to others not partaking :-).
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.)
I don't think you're the
only contributor to the discussion, and I certainly appreciate your attention
to detail. I'm all for clarity; it's just that defining every word
to have some non-traditional meaning when the common understanding will suffice
& is accurate moves things the wrong way, IMHO.
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.)
I think many:many is the
correct interpretation. Certainly not one:one, if endpoint really means
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.
Yes, but so what. A
resource representing a student record is unlikely to be very useful from a
travel booking endpoint. The purpose of
the WSDM Resource is to be something managed, thus 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.)
nope, I made it up.
But I understand exactly what it means :-), it makes perfect sense in
English, and I
don't think it violates any rules of time, space, or standards as I understand
Office of the CTO
(I tried to stay out of
this as long as possible. Oh well...)
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.
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”.
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
Fred Carter / AmberPoint, Inc.