energyinterop — archive

Message headers in section 6.6 of wd30 spec

From: Bruce Bartell <[email protected]>
To: [email protected]
Date: Mon, 17 Oct 2011 16:25:00 -0000

Figure 6-2 looks like it came from the contribution from Jerry at: http://www.oasis-open.org/apps/org/workgroup/energyinterop/download.php/42764/EiMsgHeader.xsd Bruce Bartell Xtensible Solutions Mobile : +1.321.258.6500 [email protected] www.xtensible.net From: [email protected] [mailto:[email protected]] On Behalf Of Edward Koch Sent: Sunday, October 16, 2011 11:29 PM To: William Cox Cc: [email protected] Subject: Re: [energyinterop] Message headers in section 6.6 of wd30 spec It looks very useful. I just couldn't find it in the xsd files anywhere. On Oct 16, 2011, at 7:51 PM, William Cox wrote: Ed - That's how you compose in security, including non-repudiation information (see e.g. lines 1245-1247). The Alliance can put its information in the header; the EI payload is the Payload in figure 6-1 line 1241. And yes, it's more general than WSDL; any of the transports we've discussed (and I've talked to people doing EBXML, CIP, and others) have the same structure. The patterns for message exchange are OneWay, so there's no expected messaging system response unless that's built in - we're building for highly scalable systems without a lot of message chatter, hence the application level acknowledgements that combine a typical messaging system ACK with a real message, saving considerable interaction. You have a similar effect with responses on oneway messages when you're doing REST. Hope this helps. Yes, the spec could be more general there. Thanks! bill -- William Cox Email: [email protected] Web: http://www.CoxSoftwareArchitects.com +1 862 485 3696 mobile +1 908 277 3460 fax On 10/16/11 6:44 PM, Ed Koch wrote: Are the message headers described in section 6.6 simply being proposed at the moment or are they actually defined somewhere. They seem to address some of the issues that are being discussed in the Alliance and may have value beyond just the WSDL based interactions that the section implies they are for.