[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]