OASIS Open Mailing List Archives  ·  All Lists  ·  energyinterop  ·  2011-03

energyinterop — archive

[Date Prev]  |  [Thread Prev]  |  [Thread Next]  |  [Date Next]   —  [Date Index]  |  [Thread Index]  |  [Month Index]  |  [List Home]

FW: Ack Ack


Bringing back to the list. From: Gerald Gray [mailto:[email protected]] Sent: Friday, March 25, 2011 4:30 PM To: Considine, Toby (Campus Services IT) Subject: RE: Ack Ack Hi Toby, let ??s see if I can explain further.  I didn ??t know how much detail I should go into the jira; didn ??t want to write a book if it was something we were going to discuss on the call. As noted in the jira we have various and sundry Ack types (love the image below BTW ?? big Bill The Cat fan).   For my part I am not certain of the use of the Ack in the different payloads, hence my lack of clarity in suggesting a fix. It looks like this is something we want to set once we return the call in the service operation.  Is this your understanding?  For example, are we trying to do the following: That is, after we have sent a message to System B, are we trying to let System A know that we have received it? If that is the purpose I think we can simply remove the various Acks from the message payloads.  This is because normally an ??ack ? of this sort is an implementation thing.  For example, if someone was going to implement a web service there would be a message header associated with the service that is going to contain bits of information important to both System A and System B.  There would probably be a unique ID for the message itself for example.  The ??ack ? aka return (the dashed line in the diagram) would reference this ID (or other identifying information) that tells System A ??yep we got it ?.  For this reason we don ??t need to include an Ack in the message payload; as I said, it ??s an ??implementation thing ?. If Ack is not used for this purpose, i.e. some sort of status used by System B, then we can delve into how we can abstract this out. Does that makes sense? Cheers - Gerald R. Gray, PhD Guiding Principle Consulting PO Box 381 Laingsburg, MI 48848 cell: 517.455.4824 fax: 517.913.6024 From: Considine, Toby (Campus Services IT) [mailto:[email protected]] Sent: Friday, March 25, 2011 2:26 PM To: Gerald Gray Subject: Ack Ack Can you give me more specific detail or say if I am on the right track? Thanks tc "It is the theory that decides what can be observed."   - Albert Einstein Toby Considine Chair, OASIS oBIX Technical Committee U.S. National Inst. of Standards and Tech. Smart Grid Architecture Committee Facilities Technology Office University of North Carolina Chapel Hill, NC Email: Toby.Considine@ unc.edu Phone: (919)962-9073 http://www.oasis-open.org blog: www.NewDaedalus.com

[Date Prev]  |  [Thread Prev]  |  [Thread Next]  |  [Date Next]   —  [Date Index]  |  [Thread Index]  |  [Month Index]  |  [List Home]