[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
Be careful when assuming that 1 manageable resource = 1 physical resource. What happens when you are managing different things (a printer and a router, for example) hosted in 1 physical chassis. I might want to view these as different manageable resources since they have no overlap other than running on the same platform. Another example is a system that is partitioned into many individual, totally separated systems/manageable resources. IMHO, there is a many to many correspondence between manageable resource and physical resource. Andrea > -----Original Message----- > From: Sedukhin, Igor S [mailto:Igor.Sedukhin@ca.com] > Sent: Friday, June 04, 2004 10:00 AM > To: Vambenepe, William N; wsdm@lists.oasis-open.org > Subject: RE: [wsdm] Groups - Concept Models 9 June 2004.ppt uploaded > > > William, > > My <IS/> comments below. > > > -- Igor Sedukhin .. (igor.sedukhin@ca.com) > -- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788 > > -----Original Message----- > From: Vambenepe, William N [mailto:vbp@hp.com] > Sent: Thursday, June 03, 2004 9:27 PM > To: Sedukhin, Igor S; wsdm@lists.oasis-open.org > 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. > > <IS>yes</IS> > > 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. > > <IS>The manageability provider exposes > endpoint+WS-Resource(s). That is the mechanism of enabling a > resource to be a manageable resource. If manageability > provider fails, then a resource is just that a resource. It > becomes manageable resource when there is a manageability > provider. So, we can add "exposes" to WS-Resource, but I > think "enables" is correct now.</IS> > > -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. > > <IS>There is a composition of manageability capabilities at > the manageable resource. If a resource is manageable it is > composed of one or more manageability capabilities. For > example, any manageable resource is capable of identifying > itself. That is what that arrow means. Now, who actually > supports and makes those capabilities work is a different > issue. For example, your manageable printer is capable of > counting pages, and so it composes an ability to print and an > ability to count pages. Actual support of printing and > counting is implemented by different providers. > "Implements" should be to something like a "code" of the > provider, but we don't have that, and so the diagram has > "supports" from the manageability provider to the capability. > The WS-Resource is a logical construct. It can't really > implement anything. The code of the provider can expose > WS-Resources via endpoints.</IS> > > -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. > > <IS>This has nothing to to with "values". An instance of a > capability is a set of properties, operations and events > regardles of their "values". All WS-Resources share the same > WSDL, so they will need to support all the capabilities > offered at that endpoint. Otherwise we end up in a funny > situation that the consumer must always discover supported > capabilities at runtime bypassing WSDL altogether.</IS> > > -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. > > <IS>Again, the WS-Resource is a logical construct, just like > a service is a logical construct. One needs a code (and > "agent", if you will) to "implement" those logical > constructs. In WSDM case we have abstracted from "implements" > by saying that a provider "supports", "maintains", etc. This > helped us avoid "what is a Web service" and hopefully will > help us avoid "what is a WS-Resource" discussion in this TC.</IS> > > 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". > > <IS>Why is WSDL 2.0 endpoint is not an endpoint? I think it > is :). Current conceptual diagram reflects WSDL 2.0 as well. > EPR does reference an endpoint. EPR has address, has > service/port name. It of course may have reference > properties, which qualifies the endpoint to be WS-Resource. > Nevertheless I can take an EPR and say which WSDL endpoint > that is (except if EPR is underspecified). If an EPR does not > resolve to an endpoint, then reference to what is it? What is > an EPR then? I don't think you can refer to a WS-Resource > without refering to an endpoint.</IS> > > -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. > > <IS>First of all conceptual diagram shows that all manageable > resources correspond to WS-Resources, but not necessarily > that all WS-Resources correspond to manageable resources. > There could be other associations of WS-Resource that we > didn't care about yet. > > Now, the "manageability representaion" is something that does > resonate my initial thoughts (diagrams attached). The thing > is, it does not really mirror the situation in the Web > services world. In the MOWS case, if I wanted to implement an > in-band manageability, I would have no idea where to stick > that manageability representation, since it may be glued > together with my service implementation which does not have a > similar "representation" in the model. > > So, I refrained from this by saying that either endpoint and > WS-Resource are both merely the plumbing that exists between > the consumer and the manageable resource via the provider. I > believe that WS-Resource is merely a technical detail just > like an endpoint, service, SOAP message, etc. In that, I > think it does not need to have any semantic value (e.g. > "manageability representation") in the conceptual model. This > is exactly why we didn't have "manageability representation" before. > > The bottom line, I believe that there are only 3 conceptual > elements with sematic value for WSDM: manageability consumer, > manageability provider and manageable resource. > > It is interesting to evaluate, though, so I'm attaching two > diagrams that I had initially.</IS> > > 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? > > <IS>I will upload the Visio file.</IS> > > 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. 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/leave_workgroup.ph p.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]