OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

obix message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

I have a few questions about the wd03 version.  Please let me know if I’m off base here as I am not as familiar with websockets.  Some of my comments may not make sense, or may be addressed somewhere else in the stack.

·         In 2.1.3, makePush creates a ‘transient watch’ which is removed on disconnection.  I think this might not be necessary to explain, as all watches are inherently transient.  They are removed whenever the client stops polling for changes, and certainly if the connection is broken (because the client will not be able to poll for changes).

·         If the client has to keep the watch open by sending an empty websocket frame, how is this any different from simply invoking pollChanges?  That is exactly what pollChanges and pollRefresh are for – keeping the watch open.  It seems like we’ve unnecessarily removed the semantics of the pollChanges, only to require it anyway for the same reasons.

·         I’m not sure I like that the update to the bath light doesn’t get a response – how do I know as a client that it’s safe to display the new value?  I don’t want to show the new value if it didn’t actually change.  Could we require that the server respond with the new value of the resource that was updated?

·         I think the client should respond with an acknowledgment of an update.  How does the server know whether the update was received?  If it was not received, the server may need to resend the update.  Also, shouldn’t the update then have a request id, which should then be included in the client’s response id?







From: Johnson, Gareth
Sent: Thursday, August 29, 2013 6:05 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


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.


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



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.



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

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
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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]