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] Groups - Concept Models 9 June 2004.ppt uploaded



Hi Igor,

Thanks for taking a crack at this. Since it is probably the most
important one and I tend to send too many long emails already, I'll
focus for now on slide #3. A few comments:

First a clarification.

Based on slide #4, I infer that there is a 1:1 correspondence between
the manageable resource and the physical resource. So, for example if my
printer can be managed via either an on-board manageability agent or a
proxy that provides auditing there is only one manageable resource,
correct? Several WS-Resources but one manageable resource. The printer
itself is the manageable resource.

Assuming this is correct, then I think we need a few corrections:

-1- The manageability provider does not enable the managed resource. It
enables the WS-Resource. If my manageability provider fails, my printer
is still going to print. I just won't be able to manage it. Therefore
the printer is not enabled by the manageability provider, it is only the
management aspect of the printer that is. We should redirect this arrow
to the WS-Resource.

-2- Their shouldn't be an arrow from manageable resource to
manageability capability. Or if there is one then someone please name it
and describe to me what it represents. On the other hand, we need an
arrow (with the same cardinality) from WS-Resource to manageability
capability. This arrow should be labeled "implements". Even though the
manageability capabilities are (hopefully) linked to things about the
resource, they are not implemented by the resource. Two WS-Resources for
the same printer manageable resource might return a different "page
count" for example, based on when their last reset was and based on what
they see (a WS-Resource on the print server will only count pages that
go through the print server, not those sent directly to the printer via
infrared). So I suggest we move this arrow to have it originate on the
WS-Resource.

-3- Similarly, the "offers" arrow from manageability endpoint to
manageability capability is not correct and should be replaced by the
"implement" arrow from WS-Resource to manageability capability that I
describe in bullet -2-. Two WS-Resources behind the same manageability
endpoint might have different values for the same manageability
capability for the same manageable resource.

-4- The "supports" arrow between manageability provider and
manageability capability is not needed. What does it mean for the
manageability provider to "support" a manageability capability? It means
that the manageability provider "enables" a WS-Resource that
"implements" the manageability capability. These two relations
("enables" and "implements") are already covered in bullets -2- and -3-,
so we don't need to create a relation that is just a composition of two
already exposed relations.

This is it for moving arrows around. Now a few naming requests:

-5- As I described previously, the word "endpoint" is now a guaranteed
recipe for failure. Because if we pick it we either have to explain that
a WSDL 2.0 endpoint is not an endpoint or that an Endpoint Reference
does not reference an endpoint. Either way is bad. This is sad, but
WSAddressing/WSRF has muddied the waters to the point that we should
stay away from this word. I proposed to rename manageability endpoint to
"manageability listener".

-6- The thing currently called WS-Resource should be named
"manageability representation". It is a manageability representation of
a manageable resource. Sure, it happens that technically we use a
WS-Resource for this thing. But that's plumbing that doesn't need to
appear in the conceptual model. It also happens to be a Web service
(since a WS-Resource is a Web service) but we don't need to call it a
Web service. A manageability representation is a special kind of
WS-Resource, just like a WS-Resource is a special kind of Web service.
We can show this in the diagram in slide #2. But for the diagram of
slide #3 which is the MUWS conceptual model we need to show MUWS
concepts, not what they map to in implementation. Not all WS-Resources
correspond to a manageable resource (as the current diagram indicate).
But all "manageability representations" do.

It might be easier to illustrate these corrections if I could show the
resulting UML diagram. Igor, can you make the changes I propose for
consideration or email me the Visio file?

Regards,

William


> -----Original Message-----
> From: Igor.Sedukhin@ca.com [mailto:Igor.Sedukhin@ca.com] 
> Sent: Thursday, June 03, 2004 1:37 PM
> To: wsdm@lists.oasis-open.org
> Subject: [wsdm] Groups - Concept Models 9 June 2004.ppt uploaded
> 
> 
> The document Concept Models 9 June 2004.ppt has been 
> submitted by Igor Sedukhin (Igor.Sedukhin@ca.com) to the 
> OASIS Web Services Distributed Management TC document repository.
> 
> Document Description:
> New WSDM Concept models for the discussion at the WSDM F2F on 
> July 9th 2004.
> 
> Download Document:  
> http://www.oasis-open.org/apps/org/workgroup/wsdm/download.php
> /7056/Concept%20Models%209%20June%202004.ppt
> 
> View Document Details:
> http://www.oasis-open.org/apps/org/workgroup/wsdm/document.php
> ?document_id=7056
> 
> 
> PLEASE NOTE:  If the above links do not work for you, your 
> email application
> may be breaking the link into two pieces.  You may be able to 
> copy and paste
> the entire link address into the address field of your web browser.
> 
> 
> 
> To unsubscribe from this mailing list (and be removed from 
> the roster of the OASIS TC), go to 
> http://www.oasis-open.org/apps/org/workgroup/wsdm/members/leav
e_workgroup.php.



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