RE: [obix] Groups - obix-websocket-v1.0-wd03.pdf uploaded

IBM Deutschland Research & Development GmbH Schönaicher Straße 220, 71032 Böblingen Vorsitzender des Aufsichtsrats: Martina Köderitz, Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen, Registergericht: Amtsgericht Stuttgart, HRB 243294

From: "Gemmill, Craig" <craig.gemmill@tridium.com>
To: "Johnson, Gareth" <gjohnson@tridium.com>, Markus Jung <mjung@auto.tuwien.ac.at>, Matthias X Hub/Germany/IBM@IBMDE
Cc: "obix@lists.oasis-open.org" <obix@lists.oasis-open.org>
Date: 30.08.2013 13:49
Subject: RE: [obix] Groups - obix-websocket-v1.0-wd03.pdf uploaded
Sent by: <obix@lists.oasis-open.org>

Good point Gareth-
I hadn’t thought of it that way, but that seems to me to be a very strong argument for keeping the watch semantics as is. I think it’s definitely a bad idea to have something that is binding-specific in the core. (As I write that, I’m just hoping we don’t already have that with our existing spec J).

From: Johnson, Gareth
Sent: Friday, August 30, 2013 4:26 AM
To: Markus Jung; Matthias Hub
Cc: obix@lists.oasis-open.org; Gemmill, Craig
Subject: RE: [obix] Groups - obix-websocket-v1.0-wd03.pdf uploaded

My apologies for not being able to attend yesterday’s meeting, I was already booked up. I realize if I did, it would make things easier. I’ll do my best to attend the next one J.
There’s something else I’d like to add to my argument of trying to keep a Watch ‘as is’ without the additional makePush changes…
- If I create a Watch with HTTP, I can access the same Watch to the same URI using SOAP. After all, a Watch has its own unique URI.
- If I create a special Watch just for the chosen Transport layer (i.e. using makePush for WebSockets), what happens when I try to access this same Watch over HTTP or SOAP? Really you can’t because that Watch is effectively locked to that WebSocket hence making oBIX even less RESTful.
From: Johnson, Gareth
Sent: 29 August 2013 11:05
To: 'Markus Jung'; Matthias Hub
Cc: obix@lists.oasis-open.org; Gemmill, Craig
Subject: RE: [obix] Groups - obix-websocket-v1.0-wd03.pdf uploaded

Options 1 and 2
When an HTTP request is processed by a Server, there’s a fair amount of processing involved to match up sessions, authenticate etc.
With a WebSocket open, this is no longer the case which is great. For embedded platforms that host oBIX Servers, this makes everything far more scalable. Therefore, I recommend having everything routed through one WebSocket. Of course, even with this approach, there’s nothing to stop you still implementing something like option 2 using option 1. Hence option 1 is more flexible.
After reading the spec, I quite like what we have here at the moment because it’s pretty simple and does the job quite well. From a parsing perspective, it’s still all oBIX which is nice. I advise staying ‘as is’.
Some more feedback on the spec…
Changes to Watch
My advice is to keep a the concept of a Watch as is. Therefore, Watches can still be polled (I’m not sure a blank string request will cut it with some proxy servers), refreshed and deleted. There is no makePush.
WebSockets really are just a Transport layer. Using them should have as little impact on the Application layer as possible. Yes some impact is unavoidable (this extra framing and unsolicited messages) but everything else should be kept simple. Something like ‘pollChanges’ no longer working because of a change in the Transport layer sounds too restrictive and could lead to unexpected bugs in someone’s client code.
I guess my reasoning comes down the complexity of writing a client…
- For a WS client, everything starts off as HTTP. It’s important to note that a WS connection always starts off as HTTP.
- The client attempts to make a WS connection. While the negotiation is happening, everything is still good old HTTP.
- If the client successfully opens a WS then all communications switch over to it and any Watch polls only happen every 30 seconds.
- If the client can’t open a WS then everything carries on as HTTP. Perhaps there are some firewalls that prevent the WS from opening.
- If the WS shuts down, everything can switch back again to HTTP again so the client can still work. I guess the client would probably call pollRefresh on the available Watches when the WS gets terminated unexpectedly.
Therefore, using a WS should always be considered an upgrade from HTTP polling when writing a client rather than being the only transport one will use. Because of this, it’s important to keep the Application layer as consistent as possible for simplicity. I’d rather just turn down polling and expect events rather than having to worry about using ‘makePush’ and no longer using ‘pollRefresh’. It would make the client more complex when having to handle those scenarios.
Flow Control
With a WS established, a client can receive unsolicited ‘updates’ from the Server. Therefore, the client can be bombarded with ‘Update’ messages. When polling this wasn’t a problem. Within a reasonable timeframe, it was up to the client to decide when to poll and process the results. I admit it’s still not perfect.
When a Watch is opened, some extra information can be appended to the Watch to say…
- How many items in the list can be sent down at once.
- How long to wait before flushing the next set of unsolicited ‘Updates’ to the client (if standard HTTP polling is being used then this is just ignored or used later when an upgrade to use WS happens).
These hints provide extra information to the Server to prevent clients being flooded with events.
Now let’s say, the client says ‘only send me events every 5 seconds’. This is because the client is my wife’s old iPhone (that she consequently keeps dropping and damaging – don’t get me started on replacing screens on an iPhone 4). There may be some scenarios (like when an Action is invoked from a Graphic) that I may want to poll for changes after the invocation. Hence I still want to poll for changes.
obixjs
I’ve been writing a client library for oBIX called ‘obixjs’. It handles Watch management for any user of the API (the polling and recreation of Watches is all handled by the library). If WebSockets were used, then it would be nice for any users of my API to be unaware of this (the API just works and the transport is automatically upgraded in the background).
Because it’s _javascript_, it uses the new JSON oBIX standard.
I’m pushing to get this library open sourced in future. Certainly it’s pretty cool to work with an API that has the newer JSON standard of oBIX embedded in it (it currently just converts to XML on the fly).
From: obix@lists.oasis-open.org [mailto:obix@lists.oasis-open.org] On Behalf Of Markus Jung
Sent: 29 August 2013 08:08
To: Matthias Hub
Cc: obix@lists.oasis-open.org
Subject: Re: [obix] Groups - obix-websocket-v1.0-wd03.pdf uploaded

Hello,
I found some time to have a look on the proposed Web socket binding.
I have some suggestions for changes that can be split into two design options, which are mereley:
-) Option 1: Using SOAP for the Web Socket binding or
-) Option 2: A Web socket connection represents one concrete instance of a Watch acting as a per-client state object
Option 1:
The question is if we want to expose the full oBIX protocol over Web sockets. The issue is here the RESTful design that resides at the core of oBIX. Every object is identified using a URI and the protocol is mapped to the HTTP protocol verbs. Furthermore the oBIX protocol more or less assumes a request/response interaction for message exchange, since oBIX does not provide any means to map request and response messages.
Protocol messages:
You have addressed this by defining oBIX objects for request, response and update (Line 122 to 129) --> similar wrapping types have been defined for the SOAP binding. We could reuse them.
Mapping responses to requests:
For this problem you want to add a message id, as facet. This brings information that is related to the issues the transport protocol to the application layer. If we use SOAP, the WS-Addressing standard would provide according features to support correlation of messages for asynchronous transports that do not have a request/response interaction semantic.
So as a conclusion for this design option I would suggest to use SOAP + WS-Addressing over Web sockets to rely here on already established solutions.
Option 2:
Maybe the Web socket binding could be much simpler, since we just want to take the advantage of the async. communication capabilities of Web sockets. For "normal" protocol interaction we can stay with the regular HTTP binding.
Assume that if a client connects using Web socket a Watch is created and all the interaction over Web Socket is based on WatchIn and WatchOut messages. The Watch operations are not available and follow an implicit definition. Like if a WatchIn is passed with a list of hrefs, all referenced objects are observed. If href is passed again it is removed from the watch.
In this case we don't need to map the protocol interactions and the correlation of requests and responses is also not really an issue. Since the client can just assume to receive WatchOut objects with updated oBIX objects over the Web socket connection. PollRefresh is not available but in that case the client could also use the regular HTTP binding to poll the current state of objects.
Please take this just as my subjective comment. It would be really interesting to hear the opinion of the other TC members on this topic. Maybe we can have a discussion on this topic in one of the next telcos.
Unfortunately I cannot join the telco today.
Bests,
Markus

Am 15.08.2013 02:57, schrieb Matthias Hub:
Submitter's message
Incorporated review comments from Gareth (especially introducing a Request / Response / Update frame and a request ID facet)
-- Mr. Matthias Hub

Document Name: obix-websocket-v1.0-wd03.pdf

Description
WebSocket wd03

Incorporated review comments by Gareth Johnson:
- added Request / Response / Update frame
- added request ID to correlate messages

Added conformance section

Minor updates to detail the oBIX requests
Download Latest Revision
Public Download Link

Submitter: Mr. Matthias Hub
Group: OASIS Open Building Information Exchange (oBIX) TC
Folder: Standards
Date submitted: 2013-08-14 10:57:03

--
Dipl.-Ing. Markus Jung
Research Assistant
mjung@auto.tuwien.ac.at
Tel. +43 1 58801-18322
Fax +43 1 58801-18391
Institute of Computer Aided Automation
Treitlstr. 1-3/4. Stock/E183-1
Vienna University of Technology
-->

obix message