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] 30-day Public Review for Transport Protocol Bindings for OASIS Energy Interoperation V1.0

Thanks, Pim


So if I can summarize, although it may look od to some used to a different style, the language and pattern is natural and appropriate for ebMS. The result is that this is not a barrier to proceeding.





"If something is not worth doing, it`s not worth doing well" - Peter Drucker

Toby Considine
TC9, Inc

TC Chair: oBIX & WS-Calendar

TC Editor: EMIX, EnergyInterop

U.S. National Inst. of Standards and Tech. Smart Grid Architecture Committee


Email: Toby.Considine@gmail.com
Phone: (919)619-2104

blog: www.NewDaedalus.com



From: energyinterop@lists.oasis-open.org [mailto:energyinterop@lists.oasis-open.org] On Behalf Of Pim van der Eijk
Sent: Tuesday, September 11, 2012 2:47 AM
To: 'William Cox'
Cc: 'EITC'
Subject: RE: [energyinterop] 30-day Public Review for Transport Protocol Bindings for OASIS Energy Interoperation V1.0




The ebMS MEP is at a different level than the SOAP MEP,  as explained in section 2.2 of :



Specifically,  there is no requirement that the response in an ebMS Two Way MEP is to be carried synchronously using the HTTP back-channel.  It will be exchanged on a separate connection, possibly long after the request was exchanged.  The only requirement for support for Two Way exchanges is to provide correlation information in the ebMS header using a standard correlation element.  Such correlation information will also be present in the Energy Interoperation payloads,  so it can be argued that having such correlation information in the ebMS header is redundant.  However,  this enables use of ebMS toolkits or middleware that only use ebMS SOAP header information, for example to route a response message to a particular backend application or to invoke a particular callback, obviating the need to process the SOAP body or any attachment and for any awareness of Energy Interop schemas at the integration layer.  There is no impact on scalability as the nature of the communication remains asynchronous.    


I hope this clarifies.


Kind Regards,





From: energyinterop@lists.oasis-open.org [mailto:energyinterop@lists.oasis-open.org] On Behalf Of William Cox
Sent: 11 September 2012 06:04
To: Pim van der Eijk
Subject: Re: [energyinterop] 30-day Public Review for Transport Protocol Bindings for OASIS Energy Interoperation V1.0

Pim -

I'm talking to TC Admin about starting the formal ballot this week.

Two questions on the spec, which we went over the spec in our executive  meeting today.

In section2.2.2.1 (PDF line 127), the Energy Interoperation communication structure is one-way only; there are no two-way interactions in the WSDL. Are you suggesting using two-way in ebMS for those pairs of one-way operations listed in the table (Create-Created, etc) at PDF line 130?

Section makes sense, I think. The one-way operations in EI are structured to allow information to flow as needed for pull or push, typically by polling and then acting on the results. And you're right that it's a business concept, but the messaging is deliberately related one-way primarily for scalability.

Could you explain those two minor points to me and/or the list?



William Cox
Email: wtcox@CoxSoftwareArchitects.com
Web: http://www.CoxSoftwareArchitects.com
+1 862 485 3696 mobile
+1 908 277 3460 fax

On 8/22/12 4:30 AM, Pim van der Eijk wrote:

Bill and others,


The structure of the document is set up to allow other transport protocol bindings to be added easily.  Currently there is a chapter 2 for the ebMS 3.0/AS4 binding,  other transport protocols could be added as separate chapters 3, 4 etc.  The last chapter of the specification (currently chapter 3) has a subsection 3.1 on conformance for the ebMS 3.0/AS4 binding,  other similar subsections 3.2, 3.3 etc. could be added for other transport protocol bindings.  As long as no incompatible changes are made to the existing bindings and only new bindings are added and they all related to the same version 1.0 of Energy Interoperation, the update can be considered as a new minor version, "Transport Protocol Bindings for OASIS Energy Interoperation 1.0 Version 1.1".


FYI,  the AS4 specification is on track for OASIS Standard vote, the 60 day OASIS Standard public review will start soon: 





From: energyinterop@lists.oasis-open.org [mailto:energyinterop@lists.oasis-open.org] On Behalf Of William Cox
Sent: 07 August 2012 00:04
To: energyinterop@lists.oasis-open.org
Cc: Pim van der Eijk
Subject: Re: [energyinterop] 30-day Public Review for Transport Protocol Bindings for OASIS Energy Interoperation V1.0

This document completed public review with no public comments and no TC/Jira comments.

Accordingly I will re-read, and plan a Committee Specification Ballot.

Please note that the new TC process allows non-substantive changes as part of the CS process.  If you see typos, editorial, or other non-substantive changes please post to Jira and let the list know.

We may structure this as the start of a set of transport bindings, in which case the title and version may need tweaking.

Thoughts appreciated.



William Cox
Email: wtcox@CoxSoftwareArchitects.com
Web: http://www.CoxSoftwareArchitects.com
+1 862 485 3696 mobile
+1 908 277 3460 fax

On 6/13/12 4:08 PM, Chet Ensign wrote:

The OASIS Energy Interoperation TC [1] members have recently approved a Committee Specification Draft (CSD) and submitted this specification for 30-day public review:
Transport Protocol Bindings for OASIS Energy Interoperation 1.0 Version 1.0
Committee Specification Draft 01 / Public Review Draft 01
16 May 2012 
Specification Overview:
The OASIS Energy Interoperation (EI) Version 1.0 technical specification defines EI services and operations, XML, service and operation payloads and service operation interaction patterns. EI payloads can be exchanged using WSDL-based SOAP messages or using other transport protocols. For interoperability, any use of other networking technologies should be profiled and standardized. 
This version of this specification specifies standardized exchange of EI messages using the AS4 profile of the OASIS ebMS 3.0 OASIS Standard. 
TC Description: 
All work of the OASIS Energy Interoperation Technical Committee (TC) is publicly visible through the TCs home page at http://www.oasis-open.org/committees/energyinterop, including all correspondence and prior drafts. 
The committee includes members representing Independent System Operators and Regional Transmission Operators as well as the ISO/RTO Council, tilities, Lawrence Berkeley Laboratories, building automation standards, market communication, schedule communication, electronic commerce (B2B) and software architecture experts and more. 
The work of this committee is built in part on contributions of Requirements for Demand Response PAP09 (NAESB), OpenADR 1.0 (LBL), and business information requirements (IRC) as well as substantial contributions from members of the OpenADR Alliance. 
Energy Interoperation 1.0, completed in early 2012, provides a definition for SOAP-based web services; the specification under review is the first of several anticipated alternate tranport bindings. 
The committee maintains a list of work items at http://tools.oasis-open.org/issues/browse/ENERGYINTEROP. 
Public Review Period:
The public review starts 14 June 2012 and ends 14 July 2012.
This is an open invitation to comment. OASIS solicits feedback from potential users, developers and others, whether OASIS members or not, for the sake of improving the interoperability and quality of its technical work.
The complete package of the prose specification document and related files are available in the ZIP distribution file at:
Additional information about the specification and the OASIS Energy Interoperation TC may be found at the TC's public home page:
Comments may be submitted to the TC by any person through the use of the OASIS TC Comment Facility which can be located via the button labeled "Send A Comment" at the top of the TC public home, or directly at:
Comments submitted by TC non-members for this work and for other work of this TC are publicly archived and can be viewed at:
All comments submitted to OASIS are subject to the OASIS Feedback License, which ensures that the feedback you provide carries the same obligations at least as the obligations of the TC members. In connection with this public review of Transport Protocol Bindings for OASIS Energy Interoperation 1.0 Version 1.0, we call your attention to the OASIS IPR Policy [2] applicable especially [3] to the work of this technical committee. All members of the TC should be familiar with this document, which may create obligations regarding the disclosure and availability of a member's patent, copyright, trademark and license rights that read on an approved OASIS specification. 
OASIS invites any persons who know of any such claims to disclose these if they may be essential to the implementation of the above specification, so that notice of them may be posted to the notice page for this TC's work.
========== Additional references:
[1] OASIS Energy Interoperation TC 
[2] http://www.oasis-open.org/who/intellectualproperty.php
[3] http://www.oasis-open.org/committees/energyinterop/ipr.php
RF on Limited Terms 
Chet Ensign
Director of Standards Development and TC Administration 
OASIS: Advancing open standards for the information society
Primary: +1 973-996-2298
Mobile: +1 201-341-1393
To unsubscribe, e-mail: energyinterop-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: energyinterop-help@lists.oasis-open.org



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