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