Bryan, I must admit that don’t believe my diagram helps very much
in understanding the relationship between MOWS and MUWS. While this
little exercise has been helpful to me, I have no qualms about whacking the
section.
Actually, except for Figure 1, “WS-Resource”
doesn’t appear in the text of MOWS. I might have misunderstood the
goal of the editing exercise. I think “resource” is used
fairly consistently as a generic resource with appropriate adjectives like “manageable”
in the MOWS text. Things like “WSDM resource” and “WS-RF
Resource” don’t appear, but I’ll check that. If we eliminate
references to WSDM- and WS-RF and WS- resources—all the more reason to
whack 2.4.
I would tend to agree that these diagrams
only make it more difficult to understand the simple idea of exposing manageability
via XML and Web services by complicating it with the semantics of UML.
I’ll wait to hear from others and
for a discussion in a conf call of these issues before I make the final
decision to delete the section.
Whatever I do, I will remove the right
side of my diagram with respect to “Manageabiity interfaces”—yes,
the notion is now eliminated.
Kirk Wilson
Architect, Development
Office of the CTO
802 765-4337
-----Original Message-----
From: Murray, Bryan P.
[mailto:]
Sent: Monday, November 21, 2005
1:25 PM
To: Wilson, Kirk D;
Subject: RE: [wsdm] WS-RF
Resources vs. WSDM Resources
MOWS provides a
management model for a Web service that is specifically tailored for access
from MUWS.
Section 2.4 does not help
me understand that is what MOWS is trying to accomplish. I recommend we remove
section 2.4 from MOWS. For that matter, I suggest we remove section 2.3 from
MUWS.
Kirk - I think your new
diagram is somewhat better than the existing one (its missing some of
the blatant lies in the original), however it does not help with the
confusion issue.
I thought we were going
to modify the text so we did not reference either WSRF-resource (or
WS-Resource) or WSDM-resource in both MUWS and MOWS. These terms don't help us
understand that we are exposing manageability of resources using an XML
representation of the resource accessed through a Web service.
Manageability
capabilities are no longer associated with an interface. Any property,
operation, and notification can be associated with zero or more manageability
capabilities independent of which interface it is in.
Bryan
From: Wilson, Kirk D
[mailto:]
Sent: Sunday, November 20, 2005
4:42 AM
To:
Subject: [wsdm] WS-RF Resources
vs. WSDM Resources
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:>
