RE: [wsdm] Groups - Concept Models 9 June 2004.ppt uploaded

["Andrea Westerinen" <andreaw@cisco.com>]

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.