Ira,
I sketched out what I understand you to be referring to. Assuming that I
understand correctly, I have been regarding these as "internal interfaces",
even if it were seen necessary to remote the proxy agent from the proxy
manager (which, to me, seems unlikely). That is, I would regard these
interfaces as implementation dependent and not necessary for WIMS to
specify, aside from the implicit requirement that they preserve as much of
the WIMS protocol information as possible. I also suggest that the form of
this interface would probably be different in the case of a WINS-to-SNMP
proxy versus a WIMS-to-WIMS proxy or a WIMS-to-HTTP Web page proxy, etc.
Bill Wagner
-----Original Message-----
From: owner-wims@pwg.org [mailto:owner-wims@pwg.org] On Behalf Of McDonald,
Ira
Sent: Monday, February 21, 2005 11:43 AM
To: 'wims@pwg.org'
Subject: WIMS> Proposal for WIMS Proxy Interfaces
Hi folks, Monday (21 February 2005)
After recent work on the WIMS Object Model, I see a need for two more
WIMS interfaces:
(1) Proxy Agent Interface - operation requests forwarded by a WIMS Proxy
Agent to a (local or remote) subordinate WIMS Proxy Manager and
subsequently delivered to subordinate Agent(s) registered with that
Proxy Manager
(2) Proxy Manager Interface - operation requests relayed by a WIMS Proxy
Manager to a (local or remote) superior WIMS Proxy Agent, based on
operation requests received from subordinate Agent(s) registered
with that Proxy Manager
Comments?
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
------------------------------------------------------------------------
There are two possible network topologies for a WIMS Proxy:
Integrated WIMS Proxy
{DomainA} {............DomainB............}
*-------* *-------* *-------* *-------*
| Top | | Proxy | | Proxy | | End |
|Manager| | Agent | |Manager| | Agent |
*-------* *-------* *-------* *-------*
(HostA) (......HostB......) (HostC)
Distributed WIMS Proxy
{DomainA} {............DomainB............}
*-------* *-------* *-------* *-------*
| Top | | Proxy | | Proxy | | End |
|Manager| | Agent | |Manager| | Agent |
*-------* *-------* *-------* *-------*
(HostA) (HostB) (HostC) (HostD)
Notes:
(1) If DomainA and DomainB are different, then this is fleet management
and firewalls constrain the origin of connections.
(2) If DomainA and DomainB are the same, this is enterprise management.
(3) In all cases, Proxy Agent, Proxy Manager, and End Agent MUST be in
the same domain for any practical implementation.
(4) In the 'Integrated WIMS Proxy' case, Proxy Agent to Proxy Manager
communications MAY be proprietary.
(5) In the 'Distributed WIMS Proxy' case, Proxy Agent to Proxy Manager
communications MUST be standardized (so these new interfaces should
be CONDITIONALLY MANDATORY to support).
(6) These topologies are recursive, that is, the End Agent may in fact
be a Proxy Agent with further subordinate Proxy Managers.
------------------------------------------------------------------------
Proxy Agent Interface operations:
(1) ForwardAction
- forwarded ExecuteAction received from a superior WIMS Manager
- triggered Action in a current Schedule on the Proxy Agent
(2) ForwardSchedule
- forwarded SetSchedule received from a superior WIMS Manager and
possibly decomposed by the Proxy Agent
------------------------------------------------------------------------
Proxy Manager Interface operations:
(1) RegisterForProxy
- registers Proxy Manager with superior Proxy Agent
based on prior configuration (NOT dynamic discovery)
(2) UnregisterForProxy
- unregisters Proxy Manager with superior Proxy Agent
(3) RelayRegister
- relayed RegisterForManagement received from a subordinate WIMS
Agent and possibly aggregated or delayed by the Proxy Manager
(4) RelayUnregister
- relayed UnregisterForManagement received from a subordinate WIMS
Agent and possibly aggregated or delayed by the Proxy Manager
(5) RelayAlerts
- relayed SendAlerts received from a subordinate WIMS Agent
and possibly aggregated or delayed by the Proxy Manager
(6) RelayReports
- relayed SendReports received from a subordinate WIMS Agent
and possibly aggregated or delayed by the Proxy Manager
(7) RelayGetSchedule
- relayed GetSchedule received from a subordinate WIMS Agent
------------------------------------------------------------------------
Example Sequences of Operations:
*-------* *-------* *-------* *-------*
| Top | | Proxy | | Proxy | | End |
|Manager| | Agent | |Manager| | Agent |
*-------* *-------* *-------* *-------*
RegisterForProxy
<-----------/
RegisterForProxy.response
\----------->
*-------* *-------* *-------* *-------*
| Top | | Proxy | | Proxy | | End |
|Manager| | Agent | |Manager| | Agent |
*-------* *-------* *-------* *-------*
RegisterForManagement
<-----------/
RelayRegister
<-----------/
RegisterForManagement
<-----------/
RegisterForManagement.response
\----------->
RelayRegister.response
\----------->
RegisterForManagement.response
\----------->
*-------* *-------* *-------* *-------*
| Top | | Proxy | | Proxy | | End |
|Manager| | Agent | |Manager| | Agent |
*-------* *-------* *-------* *-------*
ExecuteAction
\----------->
ForwardAction
\----------->
ExecuteAction
\----------->
ExecuteAction.response
<-----------/
ForwardAction.response
<-----------/
ExecuteAction.response
<-----------/
*-------* *-------* *-------* *-------*
| Top | | Proxy | | Proxy | | End |
|Manager| | Agent | |Manager| | Agent |
*-------* *-------* *-------* *-------*
GetSchedule
<-----------/
RelayGetSchedule
<-----------/
GetSchedule
<-----------/
GetSchedule.response
\----------->
RelayGetSchedule.response
\----------->
GetSchedule.response
\----------->
------------------------------------------------------------------------
This archive was generated by hypermail 2b29 : Mon Feb 21 2005 - 14:58:29 EST