Re: [energyinterop] FW: Ack Ack

So the question I am wrestling with, in the specific context of the recently published schemas for EI, is what to do with all the ACK strings that are in messages.

(1) They should be in an overall transaction framework, and are outside of scope

(2) They have specific meaning and purpose, and give hints to the overall transaction framework on how to track messages

(3) They have specific enumerations for each interaction type, and those enumerations need to be understood by the consuming programs

Etc.

"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

From: Girish Ghatikar [mailto:gghatikar@lbl.gov]
Sent: Saturday, March 26, 2011 4:03 PM
To: Considine, Toby (Campus Services IT)
Cc: energyinterop@lists.oasis-open.org
Subject: Re: [energyinterop] FW: Ack Ack

It was my understanding that the ACK is part of the message transport requirements. This visits TCP or UDP requirements (reliable vs. not reliable transport). If the ACK is used in this context, we're suggesting specific implementations (of course, version of UDP, reliable UDP, acts mostly like TCP).

In OpenADR, we had a message "confirmation" on top of the implementation-specific ACK. The confirmation goes beyond sending the ID to confirm the receipt of message -- it also includes returning some specific information as part of the message.

Thanks,

-Rish

On Sat, Mar 26, 2011 at 12:51 PM, Considine, Toby (Campus Services IT) <Toby.Considine@unc.edu> wrote:

Bringing back to the list.

From: Gerald Gray [mailto:gerald.gray@guiding-principle.com]
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:Toby.Considine@unc.edu]
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

Description: Bill the Cat sez 'ACK!'

"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

-----Original Message-----
From: OASIS Issues Tracker [mailto:workgroup_mailer@lists.oasis-open.org]
Sent: Thursday, March 24, 2011 2:57 PM
To: energyinterop@lists.oasis-open.org
Subject: [energyinterop] [OASIS Issue Tracker] Commented: (ENERGYINTEROP-348) Use of "Ack" as a string

[ http://tools.oasis-open.org/issues/browse/ENERGYINTEROP-348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=24965#action_24965 ]

Toby Considine commented on ENERGYINTEROP-348:

----------------------------------------------

My favorite issue that I hhad not yet entered.

Do we need a Bool and the 61698, or one, or....

dateTime

reason - not enumerated, do we need to?

remark free form

status, recommend app specific enum...

Note that for types of documents, the status is regarding the subject matter (e.g., TroubleTicket, SwitchingSchedule, Work, WorkTask, Specification, TypeAsset, AssetModel, etc.) of this particular type of document. It is not the status of the document, which is found in 'docStatus'.

> Use of "Ack" as a string

> ------------------------

> Key: ENERGYINTEROP-348

> URL: http://tools.oasis-open.org/issues/browse/ENERGYINTEROP-348

> Project: OASIS Energy Interoperation TC

> Issue Type: Bug

> Components: model, schema

> Affects Versions: wd22

> Reporter: Gerald Gray

> Assignee: William Cox

> Throughout the model there are various uses of "ack" type attributes which have been set to the data type of string. An ack type action is probably best reflected as a Boolean.

> However, the repeated uses of "ack" attributes throughout the model suggest this attribute may be abstracted out. In addition if more information about an acknowledgement is needed there may be an opportunity to leverage the Status class from CIM.

> IEC61968.Common.Status (compounded class) This class contains

> dateTime, reason, remark, value that may be leveraged for this purpose.

This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa

For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------

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:

https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

--
Rish Ghatikar
Lawrence Berkeley National Laboratory
1 Cyclotron Road, MS: 90-3111, Berkeley, CA 94720
GGhatikar@lbl.gov | +1 510.486.6768 | +1 510.486.4089 [fax]

This email is intended for the addressee only and may contain confidential information and should not be copied without permission. If you are not the intended recipient, please contact the sender as soon as possible and delete the email from computer[s].

energyinterop message