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@sharplabs.com]
Sent: Tuesday, August 03, 2004 6:02 PM
To: Wagner,William; Harry Lewis; 'wims@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@sharplabs.com
-----Original Message-----
From: Wagner,William [mailto:WWagner@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@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@sharplabs.com]
Sent: Tuesday, August 03, 2004 3:31 PM
To: 'Harry Lewis'; wims@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@sharplabs.com
-----Original Message-----
From: owner-wims@pwg.org [mailto:owner-wims@pwg.org]On Behalf Of Harry Lewis
Sent: Tuesday, August 03, 2004 1:09 AM
To: wims@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
----------------------------------------------
This archive was generated by hypermail 2b29 : Tue Aug 03 2004 - 19:03:12 EDT