[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]