OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

energyinterop message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [energyinterop] Ack Ack - a way forward?

 The key is to make sure one is not mixing ACKs across OSI Stack -- e.g., level 6 ACK used for a level 7 confirmation.

Looks like you all are on the correct track.

I have seen http ACK s (404) used this way and even though efficient confuses things for testing and developers. 

I would avoid it if possible.


Sent from Rik's IPAD

Rik Drummond
CEO, Drummond Group Inc

On Apr 1, 2011, at 10:47 AM, "Gerald Gray" <gerald.gray@guiding-principle.com> wrote:

Hi folks, in reviewing the EI wd22 document and reflecting on this thread I wanted to suggest a couple of activities that may add clarity to the intended interaction between actors. 


One issue is that it appears that the message exchange pattern (MEP) is not clear for each use case.   Very briefly for those unfamiliar with what I mean here are some examples.


The one-way example shown below shows an interaction where there is no expectation of an acknowledgement.  However, this interaction may still generate normal http errors, e.g. 404.  I believe this pattern is used for EIDistributeQuote and EIDistributeProgCall


<image001.gif>  <image002.gif>


In a two-way MEP there is an acknowledgement which is typically a standard reply message, e.g. MultiSpeak replies with an array of errorObjects (no errors means an empty array), and the message header of the response supplies all the acknowledgement that the service consumer requires.  I think the vast majority of operations that are described in the working draft fall into this two way pattern.  I have shown the EIWithdrawTender as an example.  If Party1 withdraws a tender Party2 does not need to respond with a unique payload or operation, simply receiving the acknowledgement will suffice.


<image003.gif>  <image004.gif>


A callback MEP is where the service consumer calls a service, the service provider then acts on that, and in turn calls an operation of the service consumer (wherein the service consumer and provider exchange roles).  A good example of this would be the EICreateEvent operation.  Rather than returning an event payload the VEN simply sends back an acknowledgement, unless for example, it optionally has determined that it needs to opt out of part of the event, which in this case it uses an EICreateOptStatus.


<image005.gif>  <image006.gif>


I propose that each operation be reviewed to determined what the appropriate MEP is.  In my brief review of the operations listed I get the sense that most of these are probably one-way MEPs. 


I have created a spreadsheet with the service operations listed, with a column for Ack (indicating a minimum of a one-way MEP), a column for callback (we may want to add a column to indicate what the calling back operation is post review, or simply update the EI working draft). 


I also added columns for the various security aspects since that drifted into this thread (although we may want to make that a separate activity).  I did not complete the spreadsheet, but made a stab at attributes that I think fit.  This would probably be a good activity for the whole team.  We may also want to consider crafting a set of sequence diagrams for each use case and to add clarity for the MEP assessment.  


Regards -



Gerald R. Gray, PhD

Guiding Principle Consulting

PO Box 381

Laingsburg, MI 48848

cell: 517.455.4824| fax: 517.913.6024


To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]