Use Case: Message Broker

#1

Hi,

now that hixie has been incorporated into Autobahn, I'm about to
rewrite some parts of a system. Currently I'm only using a
broadcast_server type of functionality, but I'd like to know If I'm
missing out on something by not using pubsub.

My system contains a couple of data sources. These are a telco system
which notifies of incoming and outgoing phone calls, email clients
which notify when emails arrive or get deleted, an APScheduler based
notification system, among others. All these data sources use
categories to label the data, for example phone/incoming, email/push
or reminder/notify. The data sources also do set tags to whom this
data is targeted at, ie "all", "tablet", "user1", and so on.

The system also contains data consumers, which log into the message
broker and provide it with tags to indicate the type of recipient they
are, ie "tablet,android,user1"

So the phone system may send a "Incoming call from XYZ" message,
categorized with phone/incoming, targeted at "user1" to the message
broker, and the message broker, which is the broadcast_server, sends
it to all devices which told the broker that they where interested in
data tagged with "user1".

The consumers then use the category to decide what to do with the
message. So a browser would popup a div showing a phone icon with the
name of the callee and to whom it is destined to, or it would say it
via tts, or play a sound to indicate that the answering machine
answered the phone. A tablet on the other hand would would update a
widget with the event and so on.

It's a very simple system, that's the good thing about it, so I'm not
sure if I really have any benefit from using pubsub or rpc.

The message broker lives inside a cherrypy web server, so the data
sources make a url call to the web server notifying it that there's a
new event, and the server uses the message broker which routes the
message to the clients, which are connected via websocket.

I want to take the message broker out of the web server, and change
the data sources to use Autobahn's rpc system to push messages to the
broker, which then hands over the message to the devices. Is this too
much overhead? Currently everything works with urlopen, and apart from
the encoding annoyances, it seems to be a lightweight and nice system
to trigger the broker to distribute messages. Are there benefits from
using Autobahn's rpc in every data source and the broker? Or should I
use pubsub? I plan to extend the message broker to include tls,
authentication for data sources and sinks (devices), so what do you
think, which would be the best approach to rebuild this part of the
system? I'm definitely planning on using Autobahn, as the tech got me
completely convinced, I'm just not sure about which features to use.

Kind regards,
Daniel

0 Likes

#2

Hi Daniel,

Autobahn's PubSub system _is_ a message broker.

You can have clients subscribe to one or more topics like

http://yoursystem.de/user1
http://yoursystem.de/tablet
...

and have data source publish to those topics.

The broker (Autobahn PubSub) does the lifting of maintaining
subscriptions and dispatching messages accordingly.

On that level, the message dispatching logic is purely based
on topic URI.

If you need more flexibility, i.e. content-based dispatching
(like if call_duration < 10, then only publish to client1, but
if call_duration >= 10, then publish to client2) you can
have custom publish (and also subscribe) handlers.

Autobahn does have TLS .. for WS and for WAMP.

For authentication of clients and data sources, you can use
WAMP RPC ..

It's really the scenario for which WAMP is suitable .. WS is
too low level, but don't reinvent the wheel for each new app!

Cheers,
\Tobias

···

Am 30.03.2012 20:21, schrieb Daniel F.:

Hi,

now that hixie has been incorporated into Autobahn, I'm about to
rewrite some parts of a system. Currently I'm only using a
broadcast_server type of functionality, but I'd like to know If I'm
missing out on something by not using pubsub.

My system contains a couple of data sources. These are a telco system
which notifies of incoming and outgoing phone calls, email clients
which notify when emails arrive or get deleted, an APScheduler based
notification system, among others. All these data sources use
categories to label the data, for example phone/incoming, email/push
or reminder/notify. The data sources also do set tags to whom this
data is targeted at, ie "all", "tablet", "user1", and so on.

The system also contains data consumers, which log into the message
broker and provide it with tags to indicate the type of recipient they
are, ie "tablet,android,user1"

So the phone system may send a "Incoming call from XYZ" message,
categorized with phone/incoming, targeted at "user1" to the message
broker, and the message broker, which is the broadcast_server, sends
it to all devices which told the broker that they where interested in
data tagged with "user1".

The consumers then use the category to decide what to do with the
message. So a browser would popup a div showing a phone icon with the
name of the callee and to whom it is destined to, or it would say it
via tts, or play a sound to indicate that the answering machine
answered the phone. A tablet on the other hand would would update a
widget with the event and so on.

It's a very simple system, that's the good thing about it, so I'm not
sure if I really have any benefit from using pubsub or rpc.

The message broker lives inside a cherrypy web server, so the data
sources make a url call to the web server notifying it that there's a
new event, and the server uses the message broker which routes the
message to the clients, which are connected via websocket.

I want to take the message broker out of the web server, and change
the data sources to use Autobahn's rpc system to push messages to the
broker, which then hands over the message to the devices. Is this too
much overhead? Currently everything works with urlopen, and apart from
the encoding annoyances, it seems to be a lightweight and nice system
to trigger the broker to distribute messages. Are there benefits from
using Autobahn's rpc in every data source and the broker? Or should I
use pubsub? I plan to extend the message broker to include tls,
authentication for data sources and sinks (devices), so what do you
think, which would be the best approach to rebuild this part of the
system? I'm definitely planning on using Autobahn, as the tech got me
completely convinced, I'm just not sure about which features to use.

Kind regards,
Daniel

0 Likes

#3

Thanks Tobias,

I somehow have an aversion to pubsub, which is probably due to my lack of insight to it. Is it possible to use rpc and pubsub on the same port and interface? Currently I’m settled with the idea of the publishers communicating on one port and subscribers on another, so when only using pubsub, I guess that this makes them both use the same port. But what about authentication with rpc, would this work on the same port, even on the same connection, so that I can authenticate with rpc and then when all is ok use pubsub without building a new connection?

···

On Friday, March 30, 2012 9:24:30 PM UTC+2, Tobias Oberstein wrote:

Hi Daniel,
Autobahn’s PubSub system is a message broker.

You can have clients subscribe to one or more topics like

http://yoursystem.de/user1
http://yoursystem.de/tablet

and have data source publish to those topics.

The broker (Autobahn PubSub) does the lifting of maintaining
subscriptions and dispatching messages accordingly.

On that level, the message dispatching logic is purely based
on topic URI.

If you need more flexibility, i.e. content-based dispatching
(like if call_duration < 10, then only publish to client1, but
if call_duration >= 10, then publish to client2) you can
have custom publish (and also subscribe) handlers.

Autobahn does have TLS … for WS and for WAMP.

For authentication of clients and data sources, you can use
WAMP RPC …

It’s really the scenario for which WAMP is suitable … WS is
too low level, but don’t reinvent the wheel for each new app!

Cheers,
\Tobias

Am 30.03.2012 20:21, schrieb Daniel F.:

Hi,

now that hixie has been incorporated into Autobahn, I’m about to
rewrite some parts of a system. Currently I’m only using a
broadcast_server type of functionality, but I’d like to know If I’m
missing out on something by not using pubsub.

My system contains a couple of data sources. These are a telco system
which notifies of incoming and outgoing phone calls, email clients
which notify when emails arrive or get deleted, an APScheduler based
notification system, among others. All these data sources use
categories to label the data, for example phone/incoming, email/push
or reminder/notify. The data sources also do set tags to whom this
data is targeted at, ie “all”, “tablet”, “user1”, and so on.

The system also contains data consumers, which log into the message
broker and provide it with tags to indicate the type of recipient they
are, ie “tablet,android,user1”

So the phone system may send a “Incoming call from XYZ” message,
categorized with phone/incoming, targeted at “user1” to the message
broker, and the message broker, which is the broadcast_server, sends
it to all devices which told the broker that they where interested in
data tagged with “user1”.

The consumers then use the category to decide what to do with the
message. So a browser would popup a div showing a phone icon with the
name of the callee and to whom it is destined to, or it would say it
via tts, or play a sound to indicate that the answering machine
answered the phone. A tablet on the other hand would would update a
widget with the event and so on.

It’s a very simple system, that’s the good thing about it, so I’m not
sure if I really have any benefit from using pubsub or rpc.

The message broker lives inside a cherrypy web server, so the data
sources make a url call to the web server notifying it that there’s a
new event, and the server uses the message broker which routes the
message to the clients, which are connected via websocket.

I want to take the message broker out of the web server, and change
the data sources to use Autobahn’s rpc system to push messages to the
broker, which then hands over the message to the devices. Is this too
much overhead? Currently everything works with urlopen, and apart from
the encoding annoyances, it seems to be a lightweight and nice system
to trigger the broker to distribute messages. Are there benefits from
using Autobahn’s rpc in every data source and the broker? Or should I
use pubsub? I plan to extend the message broker to include tls,
authentication for data sources and sinks (devices), so what do you
think, which would be the best approach to rebuild this part of the
system? I’m definitely planning on using Autobahn, as the tech got me
completely convinced, I’m just not sure about which features to use.

Kind regards,
Daniel

0 Likes

#4

btw, are those URI topics mandatory? Basically they would replace my tags, or extend them, like you show in your example. I don’t undestand the benefit of this.

···

On Friday, March 30, 2012 10:50:01 PM UTC+2, Daniel F. wrote:

Thanks Tobias,

I somehow have an aversion to pubsub, which is probably due to my lack of insight to it. Is it possible to use rpc and pubsub on the same port and interface? Currently I’m settled with the idea of the publishers communicating on one port and subscribers on another, so when only using pubsub, I guess that this makes them both use the same port. But what about authentication with rpc, would this work on the same port, even on the same connection, so that I can authenticate with rpc and then when all is ok use pubsub without building a new connection?

On Friday, March 30, 2012 9:24:30 PM UTC+2, Tobias Oberstein wrote:

Hi Daniel,
Autobahn’s PubSub system is a message broker.

You can have clients subscribe to one or more topics like

http://yoursystem.de/user1
http://yoursystem.de/tablet

and have data source publish to those topics.

The broker (Autobahn PubSub) does the lifting of maintaining
subscriptions and dispatching messages accordingly.

On that level, the message dispatching logic is purely based
on topic URI.

If you need more flexibility, i.e. content-based dispatching
(like if call_duration < 10, then only publish to client1, but
if call_duration >= 10, then publish to client2) you can
have custom publish (and also subscribe) handlers.

Autobahn does have TLS … for WS and for WAMP.

For authentication of clients and data sources, you can use
WAMP RPC …

It’s really the scenario for which WAMP is suitable … WS is
too low level, but don’t reinvent the wheel for each new app!

Cheers,
\Tobias

Am 30.03.2012 20:21, schrieb Daniel F.:

Hi,

now that hixie has been incorporated into Autobahn, I’m about to
rewrite some parts of a system. Currently I’m only using a
broadcast_server type of functionality, but I’d like to know If I’m
missing out on something by not using pubsub.

My system contains a couple of data sources. These are a telco system
which notifies of incoming and outgoing phone calls, email clients
which notify when emails arrive or get deleted, an APScheduler based
notification system, among others. All these data sources use
categories to label the data, for example phone/incoming, email/push
or reminder/notify. The data sources also do set tags to whom this
data is targeted at, ie “all”, “tablet”, “user1”, and so on.

The system also contains data consumers, which log into the message
broker and provide it with tags to indicate the type of recipient they
are, ie “tablet,android,user1”

So the phone system may send a “Incoming call from XYZ” message,
categorized with phone/incoming, targeted at “user1” to the message
broker, and the message broker, which is the broadcast_server, sends
it to all devices which told the broker that they where interested in
data tagged with “user1”.

The consumers then use the category to decide what to do with the
message. So a browser would popup a div showing a phone icon with the
name of the callee and to whom it is destined to, or it would say it
via tts, or play a sound to indicate that the answering machine
answered the phone. A tablet on the other hand would would update a
widget with the event and so on.

It’s a very simple system, that’s the good thing about it, so I’m not
sure if I really have any benefit from using pubsub or rpc.

The message broker lives inside a cherrypy web server, so the data
sources make a url call to the web server notifying it that there’s a
new event, and the server uses the message broker which routes the
message to the clients, which are connected via websocket.

I want to take the message broker out of the web server, and change
the data sources to use Autobahn’s rpc system to push messages to the
broker, which then hands over the message to the devices. Is this too
much overhead? Currently everything works with urlopen, and apart from
the encoding annoyances, it seems to be a lightweight and nice system
to trigger the broker to distribute messages. Are there benefits from
using Autobahn’s rpc in every data source and the broker? Or should I
use pubsub? I plan to extend the message broker to include tls,
authentication for data sources and sinks (devices), so what do you
think, which would be the best approach to rebuild this part of the
system? I’m definitely planning on using Autobahn, as the tech got me
completely convinced, I’m just not sure about which features to use.

Kind regards,
Daniel

0 Likes

#5

Thanks Tobias,

I somehow have an aversion to pubsub, which is probably due to my lack
of insight to it. Is it possible to use rpc and pubsub on the same port
and interface? Currently I'm settled with the idea of the publishers

This is how it works out of the box today, yes. Both within the same
WS session. You can of course have multiple servers (within 1 running
Twisted instance), but forwarding the messages between different servers
for PubSub would require a couple of lines of code.

communicating on one port and subscribers on another, so when only using
pubsub, I guess that this makes them both use the same port. But what
about authentication with rpc, would this work on the same port, even on
the same connection, so that I can authenticate with rpc and then when
all is ok use pubsub without building a new connection?

This is exactly what we do for of our WAMP based apps. Until the client does not perform a 3-way RPC based authentication, it is not
able to do publish or subscribe to any topic. Only when the auth is
done, those are enabled.

The line of thought for _not_ integrating that into WAMP itself is that
the specifics and requirements for authentication and authorization do
vary widely. WAMP provides you with RPC messaging pattern, so you can
do (for example):

RPC1:
Request Auth Hello: C => S
Request Challenge: S => C

RPC2:
Request Auth: C => S
Request Auth Grant: S => C

···

Am 30.03.2012 22:50, schrieb Daniel F.:

On Friday, March 30, 2012 9:24:30 PM UTC+2, Tobias Oberstein wrote:

    Hi Daniel,

    Autobahn's PubSub system _is_ a message broker.

    You can have clients subscribe to one or more topics like

    http://yoursystem.de/user1
    http://yoursystem.de/tablet
    ...

    and have data source publish to those topics.

    The broker (Autobahn PubSub) does the lifting of maintaining
    subscriptions and dispatching messages accordingly.

    On that level, the message dispatching logic is purely based
    on topic URI.

    If you need more flexibility, i.e. content-based dispatching
    (like if call_duration < 10, then only publish to client1, but
    if call_duration >= 10, then publish to client2) you can
    have custom publish (and also subscribe) handlers.

    Autobahn does have TLS .. for WS and for WAMP.

    For authentication of clients and data sources, you can use
    WAMP RPC ..

    It's really the scenario for which WAMP is suitable .. WS is
    too low level, but don't reinvent the wheel for each new app!

    Cheers,
    \Tobias

    Am 30.03.2012 20:21, schrieb Daniel F.:
     > Hi,
     >
     > now that hixie has been incorporated into Autobahn, I'm about to
     > rewrite some parts of a system. Currently I'm only using a
     > broadcast_server type of functionality, but I'd like to know If I'm
     > missing out on something by not using pubsub.
     >
     > My system contains a couple of data sources. These are a telco system
     > which notifies of incoming and outgoing phone calls, email clients
     > which notify when emails arrive or get deleted, an APScheduler based
     > notification system, among others. All these data sources use
     > categories to label the data, for example phone/incoming, email/push
     > or reminder/notify. The data sources also do set tags to whom this
     > data is targeted at, ie "all", "tablet", "user1", and so on.
     >
     > The system also contains data consumers, which log into the message
     > broker and provide it with tags to indicate the type of recipient
    they
     > are, ie "tablet,android,user1"
     >
     > So the phone system may send a "Incoming call from XYZ" message,
     > categorized with phone/incoming, targeted at "user1" to the message
     > broker, and the message broker, which is the broadcast_server, sends
     > it to all devices which told the broker that they where interested in
     > data tagged with "user1".
     >
     > The consumers then use the category to decide what to do with the
     > message. So a browser would popup a div showing a phone icon with the
     > name of the callee and to whom it is destined to, or it would say it
     > via tts, or play a sound to indicate that the answering machine
     > answered the phone. A tablet on the other hand would would update a
     > widget with the event and so on.
     >
     > It's a very simple system, that's the good thing about it, so I'm not
     > sure if I really have any benefit from using pubsub or rpc.
     >
     > The message broker lives inside a cherrypy web server, so the data
     > sources make a url call to the web server notifying it that there's a
     > new event, and the server uses the message broker which routes the
     > message to the clients, which are connected via websocket.
     >
     > I want to take the message broker out of the web server, and change
     > the data sources to use Autobahn's rpc system to push messages to the
     > broker, which then hands over the message to the devices. Is this too
     > much overhead? Currently everything works with urlopen, and apart
    from
     > the encoding annoyances, it seems to be a lightweight and nice system
     > to trigger the broker to distribute messages. Are there benefits from
     > using Autobahn's rpc in every data source and the broker? Or should I
     > use pubsub? I plan to extend the message broker to include tls,
     > authentication for data sources and sinks (devices), so what do you
     > think, which would be the best approach to rebuild this part of the
     > system? I'm definitely planning on using Autobahn, as the tech got me
     > completely convinced, I'm just not sure about which features to use.
     >
     > Kind regards,
     > Daniel

0 Likes

#6

btw, are those URI topics mandatory? Basically they would replace my
tags, or extend them, like you show in your example. I don't undestand
the benefit of this.

The benefits of using URIs (from the HTTP scheme) are:

* well known hierarchical naming scheme
* an established global name registry / arbitration system (DNS)
* by virtue of the first two, ability to integrate apps from different vendors without naming conflicts
* as a potential feature in the future: have the ability to make those
URIs derefencable for obtaining metadata

URIs are mandatory for topic and procedures. The current AutobahnXX
implementations don't _yet_ enforce this, but will do so.

In your payloads (RPC args, PubSub event payload) you are free do
to anything of course.

We for our apps use URIs for anything which isn't a literal value,
that is all ID like things, vocabulary (verbs, adj, ..) describing
relations between entities .. everything.

···

Am 30.03.2012 22:52, schrieb Daniel F.:

On Friday, March 30, 2012 10:50:01 PM UTC+2, Daniel F. wrote:

    Thanks Tobias,

    I somehow have an aversion to pubsub, which is probably due to my
    lack of insight to it. Is it possible to use rpc and pubsub on the
    same port and interface? Currently I'm settled with the idea of the
    publishers communicating on one port and subscribers on another, so
    when only using pubsub, I guess that this makes them both use the
    same port. But what about authentication with rpc, would this work
    on the same port, even on the same connection, so that I can
    authenticate with rpc and then when all is ok use pubsub without
    building a new connection?

    On Friday, March 30, 2012 9:24:30 PM UTC+2, Tobias Oberstein wrote:

        Hi Daniel,

        Autobahn's PubSub system _is_ a message broker.

        You can have clients subscribe to one or more topics like

        http://yoursystem.de/user1
        http://yoursystem.de/tablet
        ...

        and have data source publish to those topics.

        The broker (Autobahn PubSub) does the lifting of maintaining
        subscriptions and dispatching messages accordingly.

        On that level, the message dispatching logic is purely based
        on topic URI.

        If you need more flexibility, i.e. content-based dispatching
        (like if call_duration < 10, then only publish to client1, but
        if call_duration >= 10, then publish to client2) you can
        have custom publish (and also subscribe) handlers.

        Autobahn does have TLS .. for WS and for WAMP.

        For authentication of clients and data sources, you can use
        WAMP RPC ..

        It's really the scenario for which WAMP is suitable .. WS is
        too low level, but don't reinvent the wheel for each new app!

        Cheers,
        \Tobias

        Am 30.03.2012 20:21, schrieb Daniel F.:
         > Hi,
         >
         > now that hixie has been incorporated into Autobahn, I'm about to
         > rewrite some parts of a system. Currently I'm only using a
         > broadcast_server type of functionality, but I'd like to know
        If I'm
         > missing out on something by not using pubsub.
         >
         > My system contains a couple of data sources. These are a
        telco system
         > which notifies of incoming and outgoing phone calls, email
        clients
         > which notify when emails arrive or get deleted, an
        APScheduler based
         > notification system, among others. All these data sources use
         > categories to label the data, for example phone/incoming,
        email/push
         > or reminder/notify. The data sources also do set tags to whom
        this
         > data is targeted at, ie "all", "tablet", "user1", and so on.
         >
         > The system also contains data consumers, which log into the
        message
         > broker and provide it with tags to indicate the type of
        recipient they
         > are, ie "tablet,android,user1"
         >
         > So the phone system may send a "Incoming call from XYZ" message,
         > categorized with phone/incoming, targeted at "user1" to the
        message
         > broker, and the message broker, which is the
        broadcast_server, sends
         > it to all devices which told the broker that they where
        interested in
         > data tagged with "user1".
         >
         > The consumers then use the category to decide what to do with the
         > message. So a browser would popup a div showing a phone icon
        with the
         > name of the callee and to whom it is destined to, or it would
        say it
         > via tts, or play a sound to indicate that the answering machine
         > answered the phone. A tablet on the other hand would would
        update a
         > widget with the event and so on.
         >
         > It's a very simple system, that's the good thing about it, so
        I'm not
         > sure if I really have any benefit from using pubsub or rpc.
         >
         > The message broker lives inside a cherrypy web server, so the
        data
         > sources make a url call to the web server notifying it that
        there's a
         > new event, and the server uses the message broker which
        routes the
         > message to the clients, which are connected via websocket.
         >
         > I want to take the message broker out of the web server, and
        change
         > the data sources to use Autobahn's rpc system to push
        messages to the
         > broker, which then hands over the message to the devices. Is
        this too
         > much overhead? Currently everything works with urlopen, and
        apart from
         > the encoding annoyances, it seems to be a lightweight and
        nice system
         > to trigger the broker to distribute messages. Are there
        benefits from
         > using Autobahn's rpc in every data source and the broker? Or
        should I
         > use pubsub? I plan to extend the message broker to include tls,
         > authentication for data sources and sinks (devices), so what
        do you
         > think, which would be the best approach to rebuild this part
        of the
         > system? I'm definitely planning on using Autobahn, as the
        tech got me
         > completely convinced, I'm just not sure about which features
        to use.
         >
         > Kind regards,
         > Daniel

0 Likes

#7

" URIs are mandatory for topic and procedures. " would procedures then
be the equivalent to my categories? ie phone/incoming ->
http://mysystem.de/phone/incoming Hmm. Sounds interesting, I'll check
out WAMP then.

How you map your domain to topics and procedures is completely free
for you to decide and that freedom is wanted and encouraged. There
is no "one size fits" all.

Here is 1 typical pattern in our apps:

Procedure URI = app1:createStory
Topic URI = app1:onStoryCreated

An app (client) then calls the procedure, the server side does it's validation/database thing and dispatches (server-side) an event
to the topic.

The app (client) has previsouly subscribed to the onStoryCreated topic,
so that it is notified when other instances of the app (clients)
create stories.

There are other patterns as well .. probably there should be some kind
of "pattern, idioms, cookbook" overview.

Currently my data sources use HTTP GET to "post" (It's really a GET) to
the message broker:

Tags: dev
Message: Test: だ
Category: notification/text
Options: { <--- these are specific to the data source and allow it to
provide additional information, ie about the caller on the phone, or a
suggested formatting
"store": false,
"test": "| ä & ? / ~ \" だ",
"color": "rgb(176,240,0);",
"background": "black",
"size": "250%",
"style": "color:rgb(176,240,0);font-size:250%",
"duration": 5000
}

This translates to a GET:
http://server.test/ws/publish2?tags=dev&message=Test%3A%20だ&category=notification%2Ftext&options={"store"%3Afalse%2C"test"%3A"|%20ä%20%26%20%3F%20%2F%20~%20\"%20だ"%2C"color"%3A"rgb(176%2C240%2C0)%3B"%2C"background"%3A"black"%2C"size"%3A"250%"%2C"style"%3A"color%3Argb(176%2C240%2C0)%3Bfont-size%3A250%"%2C"duration"%3A5000}
<http://server.test/ws/publish2?tags=dev&message=Test%3A%20だ&category=notification%2Ftext&options={"store"%3Afalse%2C"test"%3A"|%20ä%20%26%20%3F%20%2F%20~%20\"%20だ"%2C"color"%3A"rgb(176%2C240%2C0)%3B"%2C"background"%3A"black"%2C"size"%3A"250%"%2C"style"%3A"color%3Argb(176%2C240%2C0)%3Bfont-size%3A250%"%2C"duration"%3A5000}>
which gets pushed to the clients as JSON via websockets, and the broker
also adds a UUID and a processing status and other internal stuff to it.

How can I send all that additional information in an "publish" action?
Is is easy and an already included feature in WAMP or would I need to
extend it to be able to distribute this info? I'll spend some time
reading through WAMP's code and examples, but any hint is appreciated.

Thats all built in. In AutobahnJS you just do

RPC

sess.call("http://example.com/app1#createStory", "awsome story title", 1000, ["whatever", 2, 3]).then(function (res) { // process RPC res ...

or

PubSub

sess.publish("http://mytopic..", {"color": "rgb(111,..", "background": "black", ...]);

When you want to add information on the broker side to the event before
it gets dispatched to subscribers, you just register a custome publication handler: roughly

    @exportPub("foobar", True)
    def publish(self, topicUriPrefix, topicUriSuffix, event):
        event["myadditionalfield"] = whatever();
        return event

    def onSessionOpen(self):
       self.registerHandlerForPubSub(self,
"http://example.com/event/")

The custom handler above would fire for a publish of any topic
starting with the prefix

http://example.com/event/foobar

for example

http://example.com/event/foobar1
http://example.com/event/foobar2
...

and you would get

topicUriPrefix ==
http://example.com/event/foobar

topicUriSuffix == 1 or 2

You can extend the published event that you get in arg "event"
and return the extended object, you can replace to event completely,
or you can stop anything from being dispatched by returning None.

It's quite flexible ..

Of course you dont need to implement handlers if all you need is
some dispatching .. then you are done with

    def onSessionOpen(self):

       ## register a single, fixed URI as PubSub topic
       self.registerForPubSub("http://example.com/simple")

       ## register a URI and all URIs having the string as prefix as PubSub topic
       self.registerForPubSub("http://example.com/event#", True)

       ## register any URI (string) as topic
       #self.registerForPubSub("", True)

···

Am 30.03.2012 23:34, schrieb Daniel Faust:

On Fri, Mar 30, 2012 at 23:10, Tobias Oberstein > <tobias.o...@gmail.com <mailto:tobias.o...@gmail.com>> wrote:

    Am 30.03.2012 22:52, schrieb Daniel F.:

        btw, are those URI topics mandatory? Basically they would replace my
        tags, or extend them, like you show in your example. I don't
        undestand
        the benefit of this.

    The benefits of using URIs (from the HTTP scheme) are:

    * well known hierarchical naming scheme
    * an established global name registry / arbitration system (DNS)
    * by virtue of the first two, ability to integrate apps from
    different vendors without naming conflicts
    * as a potential feature in the future: have the ability to make those
    URIs derefencable for obtaining metadata

    URIs are mandatory for topic and procedures. The current AutobahnXX
    implementations don't _yet_ enforce this, but will do so.

    In your payloads (RPC args, PubSub event payload) you are free do
    to anything of course.

    We for our apps use URIs for anything which isn't a literal value,
    that is all ID like things, vocabulary (verbs, adj, ..) describing
    relations between entities .. everything.

        On Friday, March 30, 2012 10:50:01 PM UTC+2, Daniel F. wrote:

            Thanks Tobias,

            I somehow have an aversion to pubsub, which is probably due
        to my
            lack of insight to it. Is it possible to use rpc and pubsub
        on the
            same port and interface? Currently I'm settled with the idea
        of the
            publishers communicating on one port and subscribers on
        another, so
            when only using pubsub, I guess that this makes them both
        use the
            same port. But what about authentication with rpc, would
        this work
            on the same port, even on the same connection, so that I can
            authenticate with rpc and then when all is ok use pubsub without
            building a new connection?

            On Friday, March 30, 2012 9:24:30 PM UTC+2, Tobias Oberstein > wrote:

                Hi Daniel,

                Autobahn's PubSub system _is_ a message broker.

                You can have clients subscribe to one or more topics like

        http://yoursystem.de/user1
        http://yoursystem.de/tablet
                ...

                and have data source publish to those topics.

                The broker (Autobahn PubSub) does the lifting of maintaining
                subscriptions and dispatching messages accordingly.

                On that level, the message dispatching logic is purely based
                on topic URI.

                If you need more flexibility, i.e. content-based dispatching
                (like if call_duration < 10, then only publish to
        client1, but
                if call_duration >= 10, then publish to client2) you can
                have custom publish (and also subscribe) handlers.

                Autobahn does have TLS .. for WS and for WAMP.

                For authentication of clients and data sources, you can use
                WAMP RPC ..

                It's really the scenario for which WAMP is suitable .. WS is
                too low level, but don't reinvent the wheel for each new
        app!

                Cheers,
                \Tobias

                Am 30.03.2012 20:21, schrieb Daniel F.:
         > Hi,
         >
         > now that hixie has been incorporated into Autobahn, I'm about to
         > rewrite some parts of a system. Currently I'm only using a
         > broadcast_server type of functionality, but I'd like to know
                If I'm
         > missing out on something by not using pubsub.
         >
         > My system contains a couple of data sources. These are a
                telco system
         > which notifies of incoming and outgoing phone calls, email
                clients
         > which notify when emails arrive or get deleted, an
                APScheduler based
         > notification system, among others. All these data sources use
         > categories to label the data, for example phone/incoming,
                email/push
         > or reminder/notify. The data sources also do set tags to whom
                this
         > data is targeted at, ie "all", "tablet", "user1", and so on.
         >
         > The system also contains data consumers, which log into the
                message
         > broker and provide it with tags to indicate the type of
                recipient they
         > are, ie "tablet,android,user1"
         >
         > So the phone system may send a "Incoming call from XYZ" message,
         > categorized with phone/incoming, targeted at "user1" to the
                message
         > broker, and the message broker, which is the
                broadcast_server, sends
         > it to all devices which told the broker that they where
                interested in
         > data tagged with "user1".
         >
         > The consumers then use the category to decide what to do with the
         > message. So a browser would popup a div showing a phone icon
                with the
         > name of the callee and to whom it is destined to, or it would
                say it
         > via tts, or play a sound to indicate that the answering machine
         > answered the phone. A tablet on the other hand would would
                update a
         > widget with the event and so on.
         >
         > It's a very simple system, that's the good thing about it, so
                I'm not
         > sure if I really have any benefit from using pubsub or rpc.
         >
         > The message broker lives inside a cherrypy web server, so the
                data
         > sources make a url call to the web server notifying it that
                there's a
         > new event, and the server uses the message broker which
                routes the
         > message to the clients, which are connected via websocket.
         >
         > I want to take the message broker out of the web server, and
                change
         > the data sources to use Autobahn's rpc system to push
                messages to the
         > broker, which then hands over the message to the devices. Is
                this too
         > much overhead? Currently everything works with urlopen, and
                apart from
         > the encoding annoyances, it seems to be a lightweight and
                nice system
         > to trigger the broker to distribute messages. Are there
                benefits from
         > using Autobahn's rpc in every data source and the broker? Or
                should I
         > use pubsub? I plan to extend the message broker to include tls,
         > authentication for data sources and sinks (devices), so what
                do you
         > think, which would be the best approach to rebuild this part
                of the
         > system? I'm definitely planning on using Autobahn, as the
                tech got me
         > completely convinced, I'm just not sure about which features
                to use.
         >
         > Kind regards,
         > Daniel

0 Likes