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: [OASIS Issue Tracker] Updated: (ENERGYINTEROP-534) It is not clear in the spec whether the response operation for both EIEvent and and EIQuote services are mandatory or not.


     [ http://tools.oasis-open.org/issues/browse/ENERGYINTEROP-534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

William Cox updated ENERGYINTEROP-534:
--------------------------------------

    Resolution: 
Using Event as an example, if an Event is created using CreateEvent I believe that a CreatedEvent should always follow. We have allowed for asynchronous communication to be initiated in the PULL pattern wherein a list of events is queried for and then a CreatedEvent is issued in response; but this implies that the CreateEvent already existed.

A rule of thumb:

Create is always followed by Created
Request is always followed by Reply

Cancel and Delete do not necessarily require Canceled and Deleted operations. Normally in implementation an identifier is passed to reflect the object to be canceled of deleted and an optimistic operation is assumed, that is, if you have received an HTTP 200 Status OK you know the other system received the request and if you don't later hear back via an error return that something failed, that the operation completed successfully. The only time a Canceled or Deleted operation would normally be done is if something other than "yep canceled/deleted" is needed to be passed to the calling system.

Distribute never gets a return. 
      Assignee: William Cox  (was: Gerald Gray)

As described in GGray comment. All operations are one-way; there is no requirement to respond to a cancel unless there's an error. Distribute does not have a return. Information is returned from a Create (the Pull operation has a response to the Create).

Transport level semantics could be applied in a particular deployment to ensure delivery, but in the general case an application level acknowledgement is often needed. This could use (as Gray say) an HTTP 200 OK, where you PRESUME that the action took place. But that doesn't work for Create.

> It is not clear in the spec whether the response operation for both EIEvent and and EIQuote services are mandatory or not.
> --------------------------------------------------------------------------------------------------------------------------
>
>                 Key: ENERGYINTEROP-534
>                 URL: http://tools.oasis-open.org/issues/browse/ENERGYINTEROP-534
>             Project: OASIS Energy Interoperation TC
>          Issue Type: Sub-task
>    Affects Versions: wd27
>         Environment: Ed Koch
>            Reporter: Ed Koch 
>            Assignee: William Cox
>
> There is a requirement that the EIEvent and EIQuote services need to support interaction patterns that allow the messages to be PUSH'ed and/or PULL'ed from the VTN without requiring a response by the VEN, (e.g. broadcast prices or event information). The diagrams seem to imply that a response is always required and it should be made clear in the text that responses are not mandatory in order to support the broadcast use cases.
> See also ENERGYINTEROP-544 and  ENERGYINTEROP-533

-- 
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

        


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