Uploaded image for project: 'OASIS Energy Interoperation TC'
  1. OASIS Energy Interoperation TC
  2. ENERGYINTEROP-458

792 : Section 5.6 Push and Pull Patterns needs to be generalized to all EI Operations

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: wd24
    • Fix Version/s: None
    • Component/s: spec
    • Labels:
      None
    • Environment:

      Ed Cazalet

    • Proposal:
      Hide

      5.6 Push and Pull Patterns

      The Service Operation naming includes application-level acknowledgements, which in nearly every case carry application-level information, and allow for both push and pull of messages. This description applies to both transactive and VTN/VEN interactions as both are performed by Parties taking on various roles.

      Push and Pull are with respect to the invoker of the operation. So if a Party produces information that describes a price quote, it can (in the case of Push) invoke an operation to send it to one or more other Parties. In the alternative, each Party (in the case of Pull) can invoke a request for information by polling, or pulling it, another Party respect to a particular relationship or Market Context.

      The Pull operation is performed by the Party invoking the Request service operation pattern and fulfilled with a Sent service operation pattern invoked by the receiving Party.

      So a series of Push operations from one Party to a counterParty is analogous to a series of Pull operations from the counterParty to the Party.

      Show
      5.6 Push and Pull Patterns The Service Operation naming includes application-level acknowledgements, which in nearly every case carry application-level information, and allow for both push and pull of messages. This description applies to both transactive and VTN/VEN interactions as both are performed by Parties taking on various roles. Push and Pull are with respect to the invoker of the operation. So if a Party produces information that describes a price quote, it can (in the case of Push) invoke an operation to send it to one or more other Parties. In the alternative, each Party (in the case of Pull) can invoke a request for information by polling, or pulling it, another Party respect to a particular relationship or Market Context. The Pull operation is performed by the Party invoking the Request service operation pattern and fulfilled with a Sent service operation pattern invoked by the receiving Party. So a series of Push operations from one Party to a counterParty is analogous to a series of Pull operations from the counterParty to the Party.
    • Resolution:
      Hide

      5.6 Push and Pull Patterns

      Replace lines 793-803 with the following:

      "The Service Operation naming includes application-level acknowledgements, which in nearly every case carry application-level information, and allow for both push and pull of messages. This description applies to both transactive and VTN/VEN interactions as both are performed by Parties taking on various roles.

      Push and Pull are with respect to the invoker of the operation. So if a Party produces information that describes a price quote, it can (in the case of Push) invoke an operation to send it to one or more other Parties. In the alternative, each Party (in the case of Pull) can invoke a request for information by polling, or pulling it, another Party respect to a particular relationship or Market Context.

      The Pull operation is performed by the Party invoking the Request service operation pattern and fulfilled with a Sent service operation pattern invoked by the receiving Party.

      So a series of Push operations from one Party to a counterParty is analogous to a series of Pull operations from the counterParty to the Party."

      CHANGE the entire paragraph lines 803-806 with

      "In the VTN-VEN context, a series of Push operations from a VTN to its VENs is analogous to a series of Pull operations from the VEN to its VTN; by examining (e.g.) the absence of an Event that was visible on a previous Pull the VEN can infer that that Event was canceled. The VEN could then send a Canceled service operation as if it had received a Cancel service operation."

      Show
      5.6 Push and Pull Patterns Replace lines 793-803 with the following: "The Service Operation naming includes application-level acknowledgements, which in nearly every case carry application-level information, and allow for both push and pull of messages. This description applies to both transactive and VTN/VEN interactions as both are performed by Parties taking on various roles. Push and Pull are with respect to the invoker of the operation. So if a Party produces information that describes a price quote, it can (in the case of Push) invoke an operation to send it to one or more other Parties. In the alternative, each Party (in the case of Pull) can invoke a request for information by polling, or pulling it, another Party respect to a particular relationship or Market Context. The Pull operation is performed by the Party invoking the Request service operation pattern and fulfilled with a Sent service operation pattern invoked by the receiving Party. So a series of Push operations from one Party to a counterParty is analogous to a series of Pull operations from the counterParty to the Party." CHANGE the entire paragraph lines 803-806 with "In the VTN-VEN context, a series of Push operations from a VTN to its VENs is analogous to a series of Pull operations from the VEN to its VTN; by examining (e.g.) the absence of an Event that was visible on a previous Pull the VEN can infer that that Event was canceled. The VEN could then send a Canceled service operation as if it had received a Cancel service operation."

      Description

      Recomend replacing Section 5.6 text as in the Prposal below.

      The following is not in the new Section 5.6 and should be clarified: or put elsewhere:
      And by examining (e.g.) the absence of an Event that was visible on a previous Pull the
      VEN can infer that that Event was canceled. The VEN could then send a Canceled service operation as if
      it had received a Cancel service operation.

        Attachments

          Activity

            People

            • Assignee:
              ecazalet Edward Cazalet (Inactive)
              Reporter:
              ecazalet Edward Cazalet (Inactive)
            • Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: