attachment

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1"> <META content="MSHTML 6.00.2800.1522" name=GENERATOR></HEAD> <BODY> <DIV><SPAN class=984352221-11122005><FONT face=Arial color=#0000ff size=4>Hi Bill,</FONT></SPAN></DIV> <DIV><SPAN class=984352221-11122005><FONT face=Arial color=#0000ff size=4></FONT></SPAN> </DIV> <DIV><SPAN class=984352221-11122005><FONT face=Arial color=#0000ff size=4>Yes, the result of all actions is that they always send one or more Report objects</FONT></SPAN></DIV> <DIV><SPAN class=984352221-11122005><FONT face=Arial color=#0000ff size=4>(one per target system in 'TargetObjects').  </FONT></SPAN></DIV> <DIV><SPAN class=984352221-11122005><FONT face=Arial color=#0000ff size=4></FONT></SPAN> </DIV> <DIV><SPAN class=984352221-11122005><FONT face=Arial color=#0000ff size=4>In the case of an Action embedded in </FONT></SPAN><SPAN class=984352221-11122005><FONT face=Arial color=#0000ff size=4>a Schedule, that's by a SendReports request.  </FONT></SPAN></DIV> <DIV><SPAN class=984352221-11122005><FONT face=Arial color=#0000ff size=4>In the case of an Action in </FONT></SPAN><SPAN class=984352221-11122005><FONT face=Arial color=#0000ff size=4>an ExecuteAction request, it's by an ExecuteAction response.</FONT></SPAN></DIV> <DIV><SPAN class=984352221-11122005><FONT face=Arial color=#0000ff size=4></FONT></SPAN> </DIV> <DIV><SPAN class=984352221-11122005><FONT face=Arial color=#0000ff size=4>The old specification was completely broken.  It forced TCP connections in both</FONT></SPAN></DIV> <DIV><SPAN class=984352221-11122005><FONT face=Arial color=#0000ff size=4>directions for every </FONT></SPAN><SPAN class=984352221-11122005><FONT face=Arial color=#0000ff size=4>single Execute operation.  That's not a protocol.  That's a bug.</FONT></SPAN></DIV> <DIV><SPAN class=984352221-11122005><FONT face=Arial color=#0000ff size=4></FONT></SPAN> </DIV> <DIV><SPAN class=984352221-11122005><FONT face=Arial color=#0000ff size=4>Thank goodness for your critique of my sequence diagrams.</FONT></SPAN></DIV> <DIV><SPAN class=984352221-11122005><FONT face=Arial color=#0000ff size=4></FONT></SPAN> </DIV> <DIV><SPAN class=984352221-11122005><FONT face=Arial color=#0000ff size=4>By the way, the production I sent below for the operation is still wrong in one respect.</FONT></SPAN></DIV> <DIV><SPAN class=984352221-11122005><FONT face=Arial color=#0000ff size=4>It should have 'reports : Reports' (because of multiple target systems for an action).</FONT></SPAN></DIV> <DIV><SPAN class=984352221-11122005><FONT face=Arial color=#0000ff size=4></FONT></SPAN> </DIV> <DIV><SPAN class=984352221-11122005><FONT face=Arial color=#0000ff size=4>That's already reflected in the new WIMS Message schema I just posted.</FONT></SPAN></DIV> <DIV><SPAN class=984352221-11122005></SPAN><SPAN class=984352221-11122005><FONT face=Arial color=#0000ff size=4></FONT></SPAN> </DIV> <DIV><SPAN class=984352221-11122005><FONT face=Arial color=#0000ff size=4>Cheers,</FONT></SPAN></DIV> <DIV><SPAN class=984352221-11122005><FONT face=Arial color=#0000ff size=4>- Ira</FONT></SPAN></DIV> <DIV> </DIV> <P><FONT size=2>Ira McDonald (Musician / Software Architect)<BR>Blue Roof Music / High North Inc<BR>PO Box 221  Grand Marais, MI  49839<BR>phone: +1-906-494-2434<BR>email: imcdonald@sharplabs.com</FONT> </P> <BLOCKQUOTE dir=ltr style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px"> <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma size=2>-----Original Message-----<BR><B>From:</B> wamwagner@comcast.net [mailto:wamwagner@comcast.net]<BR><B>Sent:</B> Sunday, December 11, 2005 4:20 PM<BR><B>To:</B> McDonald, Ira; 'wims@pwg.org'<BR><B>Subject:</B> Re: WIMS> Rewrite of broken ExecuteAction operation<BR><BR></FONT></DIV> <DIV>Ira,</DIV> <DIV> </DIV> <DIV>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.) </DIV> <DIV> </DIV> <DIV>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).</DIV> <DIV> </DIV> <DIV>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.</DIV> <DIV> </DIV> <DIV>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.</DIV> <DIV> </DIV> <DIV>Bill Wagner</DIV> <BLOCKQUOTE style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">-------------- Original message -------------- <BR>From: "McDonald, Ira" <imcdonald@sharplabs.com> <BR><BR>> Hi folks, Wednesday (7 December 2005) <BR>> <BR>> After a thorough review by Bill Wagner at today's WIMS telecon... <BR>> <BR>> <BR>> The Enterprise Management sequence diagram is broken - it shows both <BR>> Managers and Agents initiating operation _requests_ in the SAME session <BR>> - which is impossible - because HTTP is NOT a peer-to-peer protocol. <BR>> <BR>> Further, the current WIMS ExecuteAction definition is broken - because <BR>> it REQUIRES that two sessions (in opposite directions) must be used to <BR>> complete a single immediate action - this design flaw is because we <BR>> tried to leverage the SendReports operation in the WIMS Agent Interface. <BR>> <BR>> <BR>> Therefore, below is a new simplified ExecuteAction ! operation. <BR>> <BR>> While this solves the problem of two sessions (with serious firewall and <BR>> security constraints because of opposite directions), it also requires <BR>> a few global edits to sections 6.4, 6.5, or 6.6. See below. <BR>> <BR>> Cheers, <BR>> - Ira <BR>> <BR>> PS - I'll revise my plaintext Enterprise Management sequence diagram <BR>> and the associated numbered notes based on this change. I'll also have <BR>> to do a global edit for documentation in the Schedule XML Schema. <BR>> <BR>> <BR>> Ira McDonald (Musician / Software Architect) <BR>> Blue Roof Music / High North Inc <BR>> PO Box 221 Grand Marais, MI 49839 <BR>> phone: +1-906-494-2434 <BR>> email: imcdonald@sharplabs.com <BR>> <BR>> ------------------------------------------------------------------------ <BR>> <BR>> 6.3.4 ExecuteAction <BR>> <BR>> ExecuteAction (managerURI : URI, agentReference : AgentReference, <BR>> act! ion : Action) statusString : StatusString, <BR>> unsupportedElement s : UnsupportedElements, <BR>> report : Report <BR>> <BR>> Description: <BR>> Sends an request to process a single WIMS action to a WIMS Agent. <BR>> The receiving WIMS Agent: <BR>> <BR>> (a) MUST immediately validate this action request; <BR>> (b) MUST immediately attempt to process any well-formed action; <BR>> (c) MUST send a response with a Report of results from this action; <BR>> (d) MUST NOT send any SendReports or SendAlerts due to this action <BR>> (instead use 'statusString' in ExecuteAction response above). <BR>> <BR>> Method Support: <BR>> WIMS Agent - OPTIONAL to support <BR>> WIMS Manager - OPTIONAL to support <BR>> <BR>> ------------------------------------------------------------------------ <BR>> <BR>> ** WARNING: Do not make these edits outside the specified sections. ** <BR>> <BR>> (1) In section 6.4 and 6.5 only: <BR>> <BR>> Change: <BR>> SendReports operation <BR>> To: <BR>> Se! ndReports request or ExecuteAction response <BR>> <BR>> (2) In section 6.4 and 6.5 only: <BR>> <BR>> Change: <BR>> a SendReports to <BR>> To: <BR>> a SendReports request or ExecuteAction response to <BR>> <BR>> (3) One place in section 6.6 only: <BR>> <BR>> Change: <BR>> WIMS SendAlerts operation only <BR>> To: <BR>> WIMS ExecuteAction response containing a Report or a <BR>> WIMS SendAlerts request containing an Alert - only <BR>> ^ <BR>> [because the only is limited to the SendAlerts case - state <BR>> changes are always confirmed by ExecuteAction now] <BR>> <BR>> ------------------------------------------------------------------------ </BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>