First, the preliminaries. Happy Thanksgiving to everyone (mostly US
folks who care, but Happy Thursday to others not partaking :-).
Thus quoth Wilson, Kirk D (~ 11/22/2005 5:09 AM ~)...
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 endpoint :-)
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.
I don't think WSRF expected that any resource was viable via any
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.
In order...
I guess here I don't read/analyze the specs close enough, nor do I
think that's really what anyone meant. When I read "logical entity", I
always understand that to mean either something completely abstract OR
something logical that probably maps to something physical. Thus,
while WSDM/WS-RF cannot ever have the printer as a *-resource, they
have the logical entity representing the physical [entity of the]
printer and view them as the same thing, except when obviously
different (e.g. WSDM cannot change the toner cartridge, no matter how
hard it tries, nor can it unplug the printer, etc.). On the other
hand, some logical things have no physical counterpoint -- the order
management service probably has no physical counterpoint (not counting
the collected bits on a various disks), so it exists as logical only.
On the subject of a an absolute requirement or optionality of no
properties or more, I guess while I see the difference in the RFC 2119
words, I don't see
any real difference. If something MUST have zero or more things, I
think the zero case covers every entity, logical, physical, or
metaphysical in the known universe (excluding any presumably
metaphysical which have either sqrt(-1) or negative (consumes someone
elses?) properties). So, while the words are different, anything that
satisfies one satisfies the other, making it a distinction without a
difference. Thus, MUST have zero or more == MAY have 1 or more, and
the MUST case is largely moot. I think the "extension" is there so
that a get properties doc type request on a WS[RF]-Resource shouldn't
return "huh???", but should return any empty doc if there are no
resources. This is a interface requirement, not a conceptual one.
Either way, I see it as moot. But I'm probably to practical for this
business anyway :-)
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 them. ;-)
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
To: Wilson,
Kirk D
Cc: wsdm@lists.oasis-open.org
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.
/fred
// 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
<mailto:kirk.wilson@ca.com>
---------------------------------------------------------------------
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
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
--
Fred Carter / AmberPoint, Inc.
mailto:fred.carter@amberpoint.com
tel:+1.510.433.6525 fax:+1.510.663.6301
|