The new XMPP transport says hello world

February 25 2010

5 comments
motif

It has been a while since I last blogged about the new XMPP transport for Mule ESB. I’ve been making slow progress since then, but I’ve finally arrived at a point where the transport is starting to be useable. I’d like to show that by building a simple jabber client using the XMPP and stdio transports.

Before I can even start sending something I need to connect to a Jabber server. All server information is configured on the connector element.


<xmpp:<a href="https://www.mulesoft.com/exchange#!/?types=connector" target="_blank" rel="" title="Cloud Connectors" >connector</a> name="xmppConnector" host="localhost" 
    user="dirk" password="secret"/>

Now, let’s send out a message to a chat partner. The input is read from the console so I can interactively play with the transport:


<service name="stdio2xmpp">
    <inbound>
        <stdio:inbound-endpoint system="IN"/>
    </inbound>
    <outbound>
        <pass-through-router>
            <xmpp:outbound-endpoint recipient="mule@localhost" type="CHAT"/>
        </pass-through-router>
    </outbound>
</service>

Now when I type something on the console and press return, a message is created, flows through Mule, and the XMPP transport forwards it to the Jabber server.

Chatting is typically a two way communication so I need a second flow to receive my chat partner’s replies:


<service name="xmpp2stdio">
    <inbound>
        <xmpp:inbound-endpoint type="CHAT" from="mule@localhost" 
            transformer-refs="xmpp2object"/>
    </inbound>
    <outbound>
        <pass-through-router>
            <stdio:outbound-endpoint system="OUT"/>
        </pass-through-router>
    </outbound>
</service>

The -to-object-transformer (referenced as xmpp2object above) is necessary to extract the payload from the xmpp message that’s received from the Jabber server into a plain String that is displayed on the console.

Did I whet your appetite? You can play with the new transport yourself. Snapshot builds are available from our continuous integration server. I’d be very interested in any feedback you have.


We'd love to hear your opinion on this post


5 Responses to “The new XMPP transport says hello world”

  1. One thing that seemed to be
    missing in the old xmpp transport (or maybe I just missed it) was the ability to “broadcast” a message to a chat room.
    One idea we wanted to try was to isolate rogue & extraneous messages that were hitting our JMS. It would have been fun to broadcast that into a room, so that the culprit would get a little embarrassed. 😉
    Any sign of that in this version?

  2. Andy, I assmue you mean multi user chat here? Yes, I’m working on making the new transport MUC capable right now.

  3. […] been blogging recently about the usefulness of the transport. That blog post included a link to a custom bamboo build plan […]

  4. It seems it is not possible to receive inbound XMPP messages from multiple senders, something like JMS queue behavior. The xmpp:inbound-endpoint requires the attribute ‘from’ which can’t be wildcard or omitted. So, this can be a show stopper for some use cases. What do you think?

  5. This is a known shortcoming, see http://www.mulesoft.org/jira/browse/MULE-5139

    If you want to help with the issue, roll it into a patch and include a FunctionalTestCase and attach back to the issue.