OBIX Design Considerations

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: 

Website: http://www.pwrm.com 

  

ION®  smart energy everywhere™