RE: [obix-xml] OBIX Design Considerations

[Sam Yang <syang@echelon.com>]

Title: Message

In order for a client to support asynchronous events pushed by a server, the client itself must also be a server (with a "process event" service of some sort) .  I don't see any way around that.  For example, WS-Eventing requires that the client (or event "subscriber") be a Web Server.

 

I bring this up because we need to be aware that clients that want to support pushed events will also have to be servers, and will therefore have a larger footprint, and will be slower (and/or might require better hardware).  Not all clients may need asynchronous events, either.

 

So, unless we want to force all oBIX clients to also be Web Servers (or some other kind of server), the use of the Alarm Service (maybe it should be called the "Event Service"?) should not be required, and should not be the only way to get "important" information.  It should be up to the client developer to decide if they really need to know "instantly" about an event.  I think that polling (presumably via the Read service) should always be supported as an alternate path to event-type information (which may mean that oBIX servers, perhaps the Alarm/Event Service, will need to cache events).

 

Samuel C. Yang
Echelon Corp. <http://www.echelon.com>

email: <mailto:syang@echelon.com>
phone: 408-938-5314
fax: 408-790-3430

 

-----Original Message-----
From: Doug Ransom [mailto:Doug.Ransom@pwrm.com]
Sent: Thursday, September 16, 2004 1: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(tm)