[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
For the fax number problem, CIM would say that you have 3 logical resources
(printer, scanner and fax), 1 physical chassis (that may be broken down
further into connectors/ports, etc.) and "who cares" how many providers to
manage them (since that is behind the object broker).
Andrea
> -----Original Message-----
> From: John DeCarlo [mailto:jdecarlo@mitre.org]
> Sent: Monday, June 14, 2004 6:58 AM
> To: Andrea Westerinen
> Cc: 'Sedukhin, Igor S'; 'Vambenepe, William N';
> wsdm@lists.oasis-open.org
> Subject: Re: [wsdm] Groups - Concept Models 9 June 2004.ppt uploaded
>
>
> And, as we have discussed in the past when bringing up taxonomies of
> manageable resources, how many manageable resources do you have, and
> also how many "physical" resources do you have, when:
>
> o) You need to change a Network Interface Card (NIC) to autodetect
> speed. There is a computer with three NICs in it. And the only
> manageability interface is for the computer, but it allows
> managing the
> NICs, disk drives, and monitor(s) that are part of the computer. Or
> maybe there are separate manageability interfaces for each of
> the NICs,
> each of the disk drives, and each of the monitor(s).
>
> o) You need to change a built in fax number on a fax machine, using a
> standard fax manageability interface. You need to monitor how many
> bytes have been processed by a printer, using a standard printer
> manageability interface. A subset of the many devices managed are
> multifunction printer/scanner/fax. Would this be two or
> three (if the
> scanner is made manageable) manageable resources and one
> physical resource?
>
>
>
> Andrea Westerinen wrote:
>
> > 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_workgr
> > oup.ph
> > p.
> >
> >
> >
> >
> > 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_workgr
> > oup.php.
> >
> >
>
> --
>
> John DeCarlo, The MITRE Corporation, My Views Are My Own
> email: jdecarlo@mitre.org
> voice: 703-883-7116
> fax: 703-883-3383
> DISA cube: 703-882-0593
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]