The more I think about the Crossbar.io/Autobahn/Python mix the more clear
the
picture is becoming. The fog is slowly clearing as I think about and
understand a little better what is involved in
achieving a simple pubsub demo where, essentially and conceptually, data is
pushed from
a simple Web Server to an HTML page displayed in a Web Browser; This
happens automatically, as new
data becomes available at the Web Server, and does not require intervention
by a person(eg pressing the browser refresh button)
sat in front of the Web Browser. The problem in trying to understand
the Crossbar.io/Autobahn/Python mix is that to achieve the above goal
requires a staggering amount
of complexity for something that sounds so simple. Complexity
that is hidden away inside Crossbar.io/Autobahn, together with many other
software layers,
and us newbies need to identify what we can safely ignore and where to
focus.
Writing this entry is helping me understand Autobahn and Crossbar.io and
hopefully others will
correct my mistakes and thereby help clarify many things for other
newbies.
First there is the concept of pubsub, pushing data into a pipe at the
server end and that data dropping
out the other end of the pipe into our lap, our browser lap. This simple
concept is immediately complicated
by one of the amazing autobahn features that lets any number of clients
subscribe to the data published
by the server; Autobahn effectively adds a new ‘pipe’ between the server
and each subscribed client and
copies the data out to each client. So in the simple pubsub demo, the data
at the server end can be displayed
in any number of web browsers, without the server knowing how many browsers
are watching or how
to route the information to them. The data routing is all taken care of by
Autobahn.
At Coastform we are experimenting with Autobahn/Crossbar.io to offer access
control features.
In a simple example the data is the name of a user who has just walked
through a security door, together with
the time of access and a pathname to a photograph of the person. This data
is extracted from an
event-driven firebird database by a simple Python script and pushed across
to the waiting web browsers
by Autobahn, in near real time. Somebody scans their tag at a door reader
and within a fraction of a second
their name and picture are displayed in a remote web browser(s) perhaps
located at the entry door or
perhaps at a security desk elsewhere in the building. What a fantastic
result ! And all with a few lines
of Python code plus a little more HTML and Javascript. All thanks to the
supporting framework provided
by Autobahn, Crossbar.io, and the many other layers they are built
on.
One critical development in all of this, that slipped in under my radar
until just recently, is webSockets.
WebSockets essentially add native HTML support for bi-directional
communication between web server and
browser, so the server can deliver data over to the browser as it becomes
available rather than waiting
for a user to refresh their web page. Although many other solutions have
been created to allow
similar bi-directional comms, these are typically convoluted. WebSockets
are a much, much cleaner solution.
It is something that has been sadly lacking in HTML for way too long. Web
browsers have become very
sophisticated graphics rendering engines over recent years, capable of
formatting data and graphics presentation
any which way desired, and remote from the data source, but until the
introduction of webSockets it has
been difficult to tap into that powerful display. With Autobahn and
Crossbar.io making it easy to use
webSockets, they have opened up a new universe of opportunity and will
change the way many applications
are written to display data and graphics. Finally there is an easy way to
exploit the powerful features of web browsers.
Hardware products no longer need to have a dedicated user interface;
The user interface can run on a smartphone, tablet, or any other device
capable of running a modern Web browser.
Many applications no longer need to include complicated code
to format data and display graphics, they can use the sophisticated
rendering engine built-in to modern
browsers. Networked device and apps do not need to solve the problem of
offering a remote user interface or transmitting data
long distances to be displayed on remote terminals; Autobahn and
Crossbar.io handle all of that, freeing products
and applications to focus much more on things specific to them. Wow! What
flexibility and power!
What does Crossbar.io do? Hmmm, a lot! I think that’s part of the problem
trying to understand where
it fits in. I think another hurdle in the way of understanding is that the
authors of Crossbar.io have added
a very powerful feature that enables a single command to start any number
of client or server application
components, as well as crossbar itself, and have used this feature in many
of the examples/demos, so a newbie
has to dig deeper and understand a lot more to try and figure out what is
going on.
All the necessary information is held neatly in a single
(JSON)configuration file, but that introduces another hurdle
in the learning process. A newbie tries to dig a little to see what is
going on and finds a JSON file, whatever that is,
and then encounters a list of apparently disjoint string pairs...
I think a better place for a newbie to start would be Autobahn because it
is the thing offering an easy
way to use webSockets (via another layer called WAMP). It also includes a
basic WAMP router, something
that is necessary to actually get the data to the right destination. ie
Autobahn includes everything needed
to see a simple PubSub demo in operation. You can clearly see an example
broken down into three components:
router, backend(or server), and frontend(or user interface). You can start
these components separately too,
so there is less black magic to worry about.
Once you can see these components, the delightful simplicity of the system
becomes apparent. The communication
is limited and directed using a couple of strings, which can be anything
you like(I think),
to define a realm and topics. The realm is simply a way of ring fencing
those speakers and listeners that want to talk about the
same things (topics). A topic is just a way of tagging or identifying a
specific bit of information, such as a person’s name.
The backend and frontend components can be just a few lines of code,
communicating using nothing more than
a few string identifiers to couple them together, with the coupling
performed by Autobahn and its router. Amazing.
Maybe the Crossbar.io demos page should point newbies at the Autobahn demos first ?
Maybe the demos should all start out as Autobahn demos that
are tweaked to show where
Crossbar adds more?
ie each demo could have an Autobahn variant, so the
boundaries between
components is clear and easily identified, and a
crossbar.io variant which
allows the advanced features of Crossbar.io
to be equally easily identified and tested. As I said
earlier Crossbar.io uses a single (JSON) configuration file to pull
together all the configuration information
for a communicating application components, no matter how many of them
there are. Application
components can be referenced in the configuration file, in which case
Crossbar will automatically start them.
Furthermore, if an application component is written as a Python script, the
main class (or entry point) can be referenced in the
configuration file, in which case Crossbar will start the Python script at
your specified entry point.
Crossbar.io does much more than offer this convenience though. It includes
a more advanced WAMP router than
Autobahn, one that supports authorisation and authentication, so the
components you write can communicate
securely but without the need to write security code.
It includes a Web Server for static pages. We use this with our simple
access control example to deliver the HTML, CSS
and javascript files across to the browser for formatting and displaying
the name and photo of the person walking
through the security door. This feature alone is fantastic, it means we
don’t have to install and run yet another application
(web server).
And, much more that I don't understand yet...
WAMP, Autobahn, Crossbar.io, etc are all open-source, BTW. I can't find
enough superlatives for that !
Tim