RE: [obix-xml] OBIX Design Considerations

["Aaron Hansen" <ahansen@tridium.com>]

Title: OBIX Design Considerations

I liked the simplicity of WS-Eventing as well.  One issue mentioned in the past was server-to-client authentication.  First of all, is this really an issue?  If so, do any of the eventing specs handle it?  Can they?  Fodder for our next telecon.

 

I appreciate what you are doing Doug, but our job isn't to fend off a barrage of "how about WS-XYZ" requests.  Documenting why we didn't use a spec would be irrelevant to someone looking at our spec for implementation purposes.  We need an informed presentation about why we should consider WS-XYZ and the discussion will be recorded in our email archive or meeting notes.  If we use a specification, of course it will be documented.

 

There is a seperate committee for best practices and guidelines.  With that in mind, I don't think our committee should define relationships to orthogonal specs such as UDDI, WS-Reliability, SSL...

 

I found this nice article on WS-Addressing (http://www-106.ibm.com/developerworks/library/ws-address.html).  It has me thinking we should use that spec too.  Initially I thought all we wanted to do was provide and wsdl uri and an opague name/id for the piece of data.  I think WS-Addressing can be that simple (does anyone know for sure?) but I guess if someone wanted to reference an operation, why not!

 

Potential problem, ws-addressing is built on soap 1.2.  No one uses 1.2 yet, even MS who worked on ws-addressing doesn't support 1.2.  When do we want people to start implementing oBIX?  Is this a dead-on-arrival kind of issue?

 

BTW, WS-Addressing is a nice small spec:  http://www.w3.org/Submission/2004/SUBM-ws-addressing-20040810/

 

I'm in agreement that we don't use XML RPC semantics.  Earlier this year I had to implement a web service and had to decide on document versus rpc encoding.  I can't remember why I chose the path of document encoding, but unless someone feels strongly about using RPC I'd rather not spend anymore cycles on it.

 

I'm not sure polling is the anti use case.  Think about Rob Zivney's insighful comment about the future of this space.  Integrators are going to approach an enterprise and make a proposal based on the cost-savings by hooking up, for example, access control to HR.  Now imagine this enterprise is a government agency.  The number of points they may want to monitor could be massive (all government buildings in a city).  Is this example unrealistic?

 

Aaron

-----Original Message-----
From: Doug Ransom [mailto:Doug.Ransom@pwrm.com]
Sent: Thursday, September 16, 2004 4:29 PM
To: OBIX XML
Subject: [obix-xml] 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™