OBIX Design Considerations

["Doug Ransom" <Doug.Ransom@pwrm.com>]

Title: OBIX Design Considerations

Here are some interesting background articles:

http://www.ingorammer.com/ArchitectureBriefings/TheFlowChartLie.pdf
http://www.ingorammer.com/ArchitectureBriefings/SoapIsNotARemoteProcedureCall.pdf

I believe OBIX, targeted at the enterprise, should not fall into exclusively applying the XML as RPC paradigm.

A link to WS-Eventing was posted earlier.  This is a very simple and very cool spec.
http://msdn.microsoft.com/webservices/default.aspx?pull=/library/en-us/dnglobspec/html/ws-eventing.asp

The basic gist is that if you register a callback with the service, and it calls you back when there is data for you.  It supports one-time events "notifications" and recurring events.

Of particular interest is the filtering scheme.  A request contains a filter which is used to specify the type of data we would like to be notified of.  Typically it is an xpath string, but as far as I can tell, it can be anything - a string or an xml element (here is the type definition from the WSDL for the filter - it looks wide open):

. 
<xs:complexType name="FilterType" mixed="true">
    <xs:sequence>
      <xs:any namespace="##other" processContents="lax"
        minOccurs="0" maxOccurs="unbounded" />
    </xs:sequence>
    <xs:attribute name="Dialect" type="xs:anyURI" use="optional" />
    <xs:anyAttribute namespace="##other" processContents="lax" />
  </xs:complexType>

We could design our own filter language or xml dialect if desired.

I suggest we consider WS-Eventing be used in OBIX for:
   - annunciating new information like alarms, a price change in electricity,  daily reports (i.e. maybe a daily lighting system summary in xml), or other stuff someone might like to subscribe to.  I think polled data should perhaps be an anti-use case.

I propose/request that we include in the design document now a related specs section, even if we don't describe how they are used or related in OBIX just yet. I think these should include:

   - WS-Addressing (Which I believe should be used in OBIX.  By the time our spec is out, this will be everywhere).
   - WS-Eventing
   - WS-Reliability http://www.oasis-open.org/committees/wsrm/faq.php
   - WSDL
   - XPATH
   - SOAP
   - UDDI
   - XML 1.0

Maybe we can just add a TODO section to the current spec and paste the above list in for now?
  
If we think some of these key specs are anti-use cases or just not relevant, we should perhaps give them a mention as to why they are not to be used in OBIX, or why they aren't relevant.  I am a proponent of XPATH for discovery, I believe Brian isn't.  Either way I feel it would be wise to capture the consideration somewhere.

I feel it would be helpful to have soap examples in the spec as well - even if they are just prototypes typed in by us as opposed to actually generated by a SOAP stack.  I think this would help comittee members understand what we are doing, and be able to contribute/critique meaningfully as work proceeds as opposed to waiting till the spec is thought complete.

I request we put in a protocol bindings section in the document as well.  This would indicate how we feel about how SOAP is moved around within OBIX.  HTTP RPC Style Request/Response is how VS.Net, SOAPpy, and probably Java, lead developers to produce RPC style services. This can be a TODO;  my feeling is there will many important things in OBIX that will be best served using a scheme other than synchronous SOAP request/responses and document rather than RPC style messages. 

I know its work, mainly for Brian, but can we have these ideas included in the doc, even if they are in a todo or even out-of-scope section?

Finally, does anyone understand the concepts of web service choreography and orchestration and BPEL4WS (and supporting software like biztalk) http://xml.coverpages.org/bpel4ws.html enough to know if they are relevant to our applications?

Doug Ransom
Energy Analytics Domain Expert
Power Measurement
2195 Keating Cross Road
Saanichton, BC, Canada  V8M 2A5
Tel: (250) 652-7100  ext. 7558
Fax: (250) 652-0411
E-Mail: mailto:doug.ransom@pwrm.com
Website: http://www.pwrm.com
 
ION®  smart energy everywhere™