Title: Message
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:]
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:]
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
