WIMS> Rewrite of broken ExecuteAction operation

WIMS> Rewrite of broken ExecuteAction operation

WIMS> Rewrite of broken ExecuteAction operation

McDonald, Ira imcdonald at sharplabs.com
Sun Dec 11 16:34:29 EST 2005

Hi Bill,
Yes, the result of all actions is that they always send one or more Report
(one per target system in 'TargetObjects').  
In the case of an Action embedded in a Schedule, that's by a SendReports
In the case of an Action in an ExecuteAction request, it's by an
ExecuteAction response.
The old specification was completely broken.  It forced TCP connections in
directions for every single Execute operation.  That's not a protocol.
That's a bug.
Thank goodness for your critique of my sequence diagrams.
By the way, the production I sent below for the operation is still wrong in
one respect.
It should have 'reports : Reports' (because of multiple target systems for
an action).
That's already reflected in the new WIMS Message schema I just posted.
- 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: wamwagner at comcast.net [mailto:wamwagner at comcast.net]
Sent: Sunday, December 11, 2005 4:20 PM
To: McDonald, Ira; 'wims at pwg.org'
Subject: Re: WIMS> Rewrite of broken ExecuteAction operation

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, 
> act! ion : Action) statusString : StatusString, 
> unsupportedElement s : 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: 
> Se! ndReports 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/cc7adfcd/attachment.html

More information about the Wims mailing list