WIMS> Prototype questions

WIMS> Prototype questions

WIMS> Prototype questions

McDonald, Ira imcdonald at sharplabs.com
Wed Aug 4 11:45:49 EDT 2004


Hi Bill,

WIMS manages Services and Devices (and their contained
Jobs, Documents, Resources, etc.).  WIMS does NOT typically
manage agents (except to restart an entire host system).

A WIMS Agent is exactly analogous to an SNMP Agent or
a WSDM Agent.  It's the communications endpoint that
_forwards_ the action/operation to the desired managed
object (Printer, Job, etc.).

A SourceURI in a Report or Alert object instance only
identifies a WIMS proxy when the actual target of the 
action/operation is the proxy itself.

There is no way to tell from examining a 'pwg-wims:'
URI whether it references an end system or a proxy
- you must query the addressed WIMS Agent to find
that out with GetElements.

Since IPP Admin can at best partially manage ONLY
the IPP channel of a print service or print device,
WIMS is the only game in town for whole system
management (including Jobs, at Pete has said all
along).

My work-in-progress WIMS Objects spec will detail
the exact semantics and syntax of every single
attribute/element in any WIMS object (including
Schedule, Alert, and Report).  The main WIMS
protocol spec should not be the authoritative
source (but only reference the WIMS Objects spec).

Remember that NO schema can be added to the PWG
Semantic Model without a complete separate spec
for the semantics of the object(s) and elements
in the schema.

My early mistake was to conflate legacy/WIMS Agents
with services and devices (like Printer object) in
TargetURI and SourceURI - my modelling mistake.

A managed service is not managed (in the typical 
case) via its application protocol URI (such
as 'ipp:'), but by an independent (and not
necessarily open standard) path to/from the Agent.
But that same managed service _is_ typically
_identified_ by an application protocol URI
(in the TargetObjects structure).

Talk to you shortly.


Cheers,
- Ira


Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: imcdonald at sharplabs.com

-----Original Message-----
From: Wagner,William [mailto:WWagner at NetSilicon.com]
Sent: Wednesday, August 04, 2004 10:46 AM
To: McDonald, Ira; Harry Lewis; wims at pwg.org
Subject: RE: WIMS> Prototype questions


Ira,

I may be too confused now to clear up in the conference call. Lets try one
item at a time.

At this point, I am disregarding the spec, which we agree is wrong on some
cases and at least unclear in others. I agree that, once I understand,
separate diagrams for different operations should be created for the spec.
Somewhere along the line, we have also added the concept of managing objects
(such a jobs) within but not part of a managed entity. As far as I can see,
there is no reference to this concept in the spec.

1. Agent vs. Managed Entity in Operations: You have written:

	TargetURI or SourceURI are the address of a legacy or WIMS
management agent, NOT the actual managed entity.

 And in your response to Harry's question on SendReport:
	
	Note that the Source URI identifies EITHER a WIMS Agent (such as the
proxy running the Schedule) OR a legacy agent
	(such as the SNMP URI of a legacy printer).  That's why the source
is NOT implicit in the originator of the connection.
 
I find this confusing. Under what conditions does SourceURI reference the
proxy rather than the legacy agent? It would seem that the only case would
be when the proxy is dealing with embedded WIMS agents, but the rational for
that eludes me. The manager should not care and may not know whether it is
dealing with a proxy dealing with legacy or WIMS agents.

2. You state that the managed entity:
	.. is identified by the TargetObjects structure (which is _returned_
in the SendReport or SendAlert in the 
	PlanAction element).

That is understandable, but I think we need to find some clear way to
indicate in the spec that this structure exists in the operations and that
it includes the identification of the applicable managed entity. Right now,
it would appear to require reading through the chain of xsd files to
understand this. (Indeed, I have not been able to follow the path yet.)

Bill Wagner





-----Original Message-----
From: McDonald, Ira [mailto:imcdonald at sharplabs.com]
Sent: Tuesday, August 03, 2004 8:40 PM
To: Wagner,William; Harry Lewis; wims at pwg.org
Subject: RE: WIMS> Prototype questions


Hi Bill,

Nope - we're still not clear.

Despite the incorrect spec, a TargetURI or SourceURI should
ONLY be the address of a legacy or WIMS management agent, NOT
the actual managed entity (e.g., Printer object of a Print Service),
which is identified by the TargetObjects structure (which is 
_returned_ in the SendReport or SendAlert in the PlanAction
element).

In particular, this allows notifications to be packaged from
a managed entity that does NOT have a URI (such as a Resource
or a Document) and sent with a SourceURI that identifies the
end system management agent (NOT the intermediate WIMS agent).

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: imcdonald at sharplabs.com

-----Original Message-----
From: Wagner,William [mailto:WWagner at NetSilicon.com]
Sent: Tuesday, August 03, 2004 7:03 PM
To: McDonald, Ira; Harry Lewis; wims at pwg.org
Subject: RE: WIMS> Prototype questions


Ira,

I agree about the confusion, and some of this has been in the spec for a
long time. Hopefully we can address it in the conference call tomorrow.

If I understand you correctly:

SendReport and SendAlert operations are sent by agent, but each instance
deals with but one managed entity (e.g., a printer). The managed entity is
identified by the "SoureURI" parameter, which may or may not bear an
commonality with the agent. The spec has defined "SourceURI" as the agent so
this has been confusing. "TargetURI" in this case has been defined as
referring to the manager...but is that correct and of so, why is this
reference necessary?

It would appear that these meanings for source and target URI also apply to
RegisterForManagement and UnRegisterForManagement.

Schedules include actionTargetURI's, which also identify the managed entity
(or entities, if a given action is applicable to multiple entities)

Then what do the SourceURI and TargetURI in GetSchedule  identify?
Schedules deal with multiple managed entities. Indeed, schedules are
applicable to agents not to managed entities. So in this case, does
SourceURI refer to the agent? That may be a confusing and subtle
distinction.

By the same reasoning, in SetSchedule, SourceURI is the manager and
TargetURI is the agent.

In ExecuteAction, SourceURI is still the Manager but TargetURI  must
identify managed entity? And it is single valued?

And I need help on the use of  target objects  (such as Job Object) and the
distinction in reference from WMSManagedObjects (which I apparently mistook
as referring to the actual variables being managed ..i.e., MIB Objects)

Bill Wagner



-----Original Message-----
From: McDonald, Ira [mailto:imcdonald at sharplabs.com]
Sent: Tuesday, August 03, 2004 6:02 PM
To: Wagner,William; Harry Lewis; 'wims at pwg.org'
Subject: RE: WIMS> Prototype questions


Hi Bill,

Serious confusion here about systems, agents, managed entities
(such as Printer object, application services/devices), and 
managed objects (such as Job object, contained _within_ managed 
entities).

Both the spec and Schedule schema are currently wrong.

ActionTargetURIs is a set of URIs of _legacy_ or WIMS agents
(that is they identify management agents on systems, not just
WIMS management agents).  The documentation in the Alert schema
for NotifyTargetURIs (for Subscription) shows examples:

<xsd:element name="NotifyTargetURIs">
  <!-- OPTIONAL - MAY be multi-valued -->
  <!-- list of legacy or WIMS agent URIs to be monitored -->
  <!-- (sources of all later notifications for this subscription) -->
  <!-- e.g., 'pwg-wims://example.com' (a WIMS agent) -->
  <!-- or 'snmp://example.com:162' (an SNMP trap generator) -->
  <xsd:complexType>
    <xsd:sequence>
      <xsd:element name="NotifyTargetURI" type="xsd:anyURI"
        minOccurs="0" maxOccurs="unbounded"/>
    </xsd:sequence>
  </xsd:complexType>
</xsd:element>

And the corresponding NotifySourceURI in Alert schema says:

<xsd:element name="NotifySourceURI" type="xsd:anyURI"/>
  <!-- REQUIRED - MUST be single-valued -->
  <!-- source legacy or WIMS agent URI for this notification -->
  <!-- see notify-printer-uri - section 5.4.5 [IPP-NOT] -->

It is the TargetURI element that unambiguously names the 
system to be managed (not just the WIMS proxy intermediary).

The WIMS proxy forwards a given action to a legacy device
(in SNMP, or whatever) and retrieves the data to formulate
a correct SendReport (for GetElements) or SendAlert (for
admin actions or warnings/errors).

Whereas, the TargetObjects is _already_ in all Report and
Alert instances, because it's part of 'PlanAction' which
is returned in a Report or Alert.

In the near-term managed devices will ALL be legacy and
WIMS proxies will always have to convert operations and
elements accordingly.

I hope this helps.  A good diagram of the URIs and the
addressed entities would obviously be an improvement
in the spec.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: imcdonald at sharplabs.com

-----Original Message-----
From: Wagner,William [mailto:WWagner at NetSilicon.com]
Sent: Tuesday, August 03, 2004 4:37 PM
To: McDonald, Ira
Subject: RE: WIMS> Prototype questions


Ira,

Seeing your comment to Harry, note that end of fourth paragraph should refer
to alert schema rather than event schema. 

Bill Wagner

-----Original Message-----
From: Wagner,William 
Sent: Tuesday, August 03, 2004 4:27 PM
To: McDonald, Ira; Harry Lewis; wims at pwg.org
Subject: RE: WIMS> Prototype questions


Ira,

That was pretty much the gist of the question I ask last Friday.  As with
the schedule actions, there are other places where perhaps the distinction
between the agent and the managed entity should be made. First, let me seek
to confirm that we have agreement on the following:

1. Since we have added the TargetObjects parameter to all schedule actions
that relate to managed objects (as distinguished from agent actions such as
UpdateSchedule), it can be assumed that a single schedule may refer to many
managed objects. Further, since the specific actions identify the managed
entity, the schedule itself is agent oriented.

2. We agreed that the parameters "Source URI" and "Target URI"  refer to the
Agent and Manager respectively  in operations and actions executed by the
Agent and that these parameters refer to Manager and Agent respectively  in
operations executed by the Manager. But that the term TargetURI must not be
interpreted to refer to the managed entity. Rather, the new term
TargetObject will always refer to the managed entity. (you do not seem to
agree with this in your answer to Harry)

3. The  SendReport and SendAlert Operations from a given agent may deal with
multiple manageable entities, and these entities are not identified by the
Target URI term.  Rather, they must be identified by a TargetObject term in
the Send Report or Send Alert Operation (which is not now included) or e4ach
report or alert entry must include a TargetObject term. I may just be
missing it but I do not see this terms in either the report or event
schemas.


If indeed,  a given SendReport (or SendAlert) conveys the results of the
atomic action for a single one of the ActionTargetURI values, I think we
need to add the TargetObjects parameter to this operation. Alternatively, if
each report or alert entry includes the TargetObject, then a given operation
can handle multiple managed entities.

But I think we need to distinguish the agent from the managed entity.

Bill Wagner


-----Original Message-----
From: McDonald, Ira [mailto:imcdonald at sharplabs.com]
Sent: Tuesday, August 03, 2004 3:31 PM
To: 'Harry Lewis'; wims at pwg.org
Subject: RE: WIMS> Prototype questions


Hi Harry,

My intent all along (I guess not well-documented) is that a given
SendReport conveys the results of the atomic action for a single
one of the ActionTargetURI values (identified by the parameter
'sourceURI' and also the element ReportSourceURI embedded
in the Report object instance).

Note that the Source URI identifies EITHER a WIMS Agent
(such as the proxy running the Schedule) OR a legacy agent
(such as the SNMP URI of a legacy printer).  That's why the
source is NOT implicit in the originator of the connection.

Does that help?

Cheers,
- Ira

PS - A refinement would be to have SendReport send a SET
of Report object instances (one or more), one for each target.

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: imcdonald at sharplabs.com 
-----Original Message-----
From: owner-wims at pwg.org [mailto:owner-wims at pwg.org]On Behalf Of Harry Lewis
Sent: Tuesday, August 03, 2004 1:09 AM
To: wims at pwg.org
Subject: WIMS> Prototype questions



I've run into the following question 

When the schedule specifies more than one ActionTargetURI, how do we
differentiate (in ReportRequestedElements) which ReportElementAny
corresponds to which ActionTargetURI?   

---------------------------------------------- 
Harry Lewis 
IBM STSM
Chairman - IEEE-ISTO Printer Working Group
http://www.pwg.org
IBM Printing Systems 
http://www.ibm.com/printers
303-924-5337
---------------------------------------------- 



More information about the Wims mailing list