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

["Sedukhin, Igor S" <Igor.Sedukhin@ca.com>]

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.php.

MUWS Concepts.png

MUWS Logical Model.png