RE: [obix-xml] OBIX Design Considerations

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

Title: Message

I also agree the WS-* namespace is confusing.  It is also irritating the major vendors can't cooperate early.  Maybe its better they produce competing specs and toss the worst one.

 

WS-Eventing is getting a lot of press, probably because of Microsoft and Don Box's weblog publicizing it, and its very simple. 

 

WS-Notification http://www-106.ibm.com/developerworks/library/ws-pubsub/ has more features.  Some are interesting, like the idea of the topics and brokered notification.  It is not as simple. 

 

Sometimes what appears to be the simple solution turns out to be the naïve one.  There may be good uses of the advanced features of WS-Notification over the simplicity of WS-Eventing.  I think this will fall out (again) from the use  cases.

 

Doug

---

From: Sam Yang [mailto:syang@echelon.com]
Sent: Tuesday, September 21, 2004 5:28 PM
To: Doug Ransom; OBIX XML
Subject: RE: [obix-xml] OBIX Design Considerations

I agree that we should not reinvent the wheel.  It does look like there are a lot of similar efforts underway that we should look at.

 

For instance, OASIS has its own "WS-Notification" effort, which overlaps "WS-Eventing".  IBM is a chief sponsor of WS-Notification, but in August also jumped on the WS-Eventing bandwagon.  Pretty confusing, but I gather that the two efforts will be merged somehow.  At least both efforts are based on WS-Addressing.

 

Another effort that overlaps ours is also already underway in OASIS: "WS-Resource Framework".  Not only does it also rely on WS-Addressing, but it is for "modeling stateful resources with web services", which sounds a lot like points in a control network.

 

It is indeed possible that our efforts may be fulfilled with a little bit of oBIX stuff, and a lot of WS-* stuff.

 

-----Original Message-----
From: Doug Ransom [mailto:Doug.Ransom@pwrm.com]
Sent: Tuesday, September 21, 2004 12:58 PM
To: OBIX XML
Subject: RE: [obix-xml] OBIX Design Considerations

My main concerns are:
- we don't reimplement what we can reuse
- that our spec isn't obsolete at the time or shortly after its released because we aren't compatible with ws-this and ws-that.  That is a bit of a challenge for us.  If these are truly orthogonal specs, mabye it is not an  issue.  

I am hoping when the use-cases are flushed out, it will be clear how they are fulfilled with OBIX and related (WS-* etc) stuff.  We may very well be able to simply define a few interfaces for OBIX and say "compose these with whatever WS-* you want" and achieve sufficient interoperability.

I admit that I  do not understand how the design so far fits into the bigger picture of what I would do with obix specifically (and how big a peice of the puzzle it currently is).

Doug

________________________________

        From: Aaron Hansen [mailto:ahansen@tridium.com]
        Sent: Friday, September 17, 2004 9:37 AM
        To: Doug Ransom; OBIX XML
        Subject: RE: [obix-xml] 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
<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/
<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