Ira,
I have been making the ExecuteAction changes, but have some reservations. We have changed what was intended as an alternate way of entering a single scheduled action with an inherent scheduled execution time of immediate into a completely distinct and complex operation. The problems appear when the requested action is an agent operation, particularly an operation where the response of the Manager is significant. This is particularly apparent with an UpdateSchedule action. (Since a SetSchedule operation exists, this action is unnecessary and I indicated in the text that it is not allowed in a ExecuteAction request.)
We have addressed actions that previously resulted in a SendReports by saying that the report is in the ExecuteAction response. What about actions that previously resulted in a SendAlerts? (i.e. Administrative Actions).
I agree that the revised ExecuteAction is much more like traditional management approaches: one makes a request and gets a response. I also agree that one might expect the response to an ExecuteAction to be relate to the embedded action rather than to just acknowledge (or reject) the request itself. But the results of actions given in a ExecuteAction are now different from the nominally same action in a Schedule.
I am trying to address these differences, but will I miss some. The text will need careful review to catch other ramifications of this change. I think we need to consider whether this disruption is really necessary.
Bill Wagner
-------------- Original message --------------
From: "McDonald, Ira" <imcdonald at sharplabs.com>
> Hi folks, Wednesday (7 December 2005)
>> After a thorough review by Bill Wagner at today's WIMS telecon...
>>> The Enterprise Management sequence diagram is broken - it shows both
> Managers and Agents initiating operation _requests_ in the SAME session
> - which is impossible - because HTTP is NOT a peer-to-peer protocol.
>> Further, the current WIMS ExecuteAction definition is broken - because
> it REQUIRES that two sessions (in opposite directions) must be used to
> complete a single immediate action - this design flaw is because we
> tried to leverage the SendReports operation in the WIMS Agent Interface.
>>> Therefore, below is a new simplified ExecuteAction operation.
>> While this solves the problem of two sessions (with serious firewall and
> security constraints because of opposite directions), it also requires
> a few global edits to sections 6.4, 6.5, or 6.6. See below.
>> Cheers,
> - Ira
>> PS - I'll revise my plaintext Enterprise Management sequence diagram
> and the associated numbered notes based on this change. I'll also have
> to do a global edit for documentation in the Schedule XML Schema.
>>> 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>> ------------------------------------------------------------------------
>> 6.3.4 ExecuteAction
>> ExecuteAction (managerURI : URI, agentReference : AgentReference,
> action : Action) statusString : StatusString,
> unsupportedElements : UnsupportedElements,
> report : Report
>> Description:
> Sends an request to process a single WIMS action to a WIMS Agent.
> The receiving WIMS Agent:
>> (a) MUST immediately validate this action request;
> (b) MUST immediately attempt to process any well-formed action;
> (c) MUST send a response with a Report of results from this action;
> (d) MUST NOT send any SendReports or SendAlerts due to this action
> (instead use 'statusString' in ExecuteAction response above).
>> Method Support:
> WIMS Agent - OPTIONAL to support
> WIMS Manager - OPTIONAL to support
>> ------------------------------------------------------------------------
>> ** WARNING: Do not make these edits outside the specified sections. **
>> (1) In section 6.4 and 6.5 only:
>> Change:
> SendReports operation
> To:
> SendReports request or ExecuteAction response
>> (2) In section 6.4 and 6.5 only:
>> Change:
> a SendReports to
> To:
> a SendReports request or ExecuteAction response to
>> (3) One place in section 6.6 only:
>> Change:
> WIMS SendAlerts operation only
> To:
> WIMS ExecuteAction response containing a Report or a
> WIMS SendAlerts request containing an Alert - only
> ^
> [because the only is limited to the SendAlerts case - state
> changes are always confirmed by ExecuteAction now]
>> ------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.pwg.org/archives/wims/attachments/20051211/cda21db1/attachment.html