02 May 2016, 09:39

Sample XMPP use cases

How do XMPP components become useful to us? What use cases can XMPP components be applied as a solution?

Status querying and subscribing

We can define an XMPP component which allows people to ask for information and subscribe to information:

 John Doe@chat.local: get-status machine1
 My Component@mycomponent.chat.local: machine1 is currently running for 3 hours

 John Doe@chat.local: subscribe machine1
 My Component@mycomponent.chat.local: John Doe is now subscribed to changes to machine1
 ... later ...

 My Component@mycomponent.chat.local: machine1 has gone down.

The details of get-status and subscribe are defined within the component using its own code to query the status of the machines and handle subscription requests and responses

Protocol Bridging

We can use an XMPP component to bridge from one Protocol to another. As we stated above, a component has a domain, such as mycomponent.chat.local. In this use case, we can define each username within the “username@mycomponent.chat.local” as being a username within a non-XMPP system.

For example: we can send to 555-555-5555@sms.chat.local and the component written bound to “sms.chat.local” will forward the message to the phone number “555-555-5555”.

John Doe@chat.local: Hey when do you want to do lunch?
... later ...
555-555-5555@sms.chat.local: 15 minutes sound good?

The communication between “John Doe” and our phone number is handled via the XMPP component and SMS service.

Exposing Data

We can use an XMPP component to expose some data in a viewable and editable form:

John Doe@chat.local: list events
   1 - Interview in Meeting room A - 3:30 PM:4:00PM - Today
   2 - Standup - 9:00AM:9:15AM - Tomorrow
John Doe@chat.local: rsvp 1
   John Doe just RSVPed to “Interview in Meeting room A”. Will send reminder 15 minutes before start of meeting.

In this example an XMPP client, John Doe, is able to interact with the ‘scheduling’ feature of a fictional data services component ‘ds.chat.local’.

Centralized Service Bus

With XMPP components, each component can communicate and subscribe to any other component. This can make your XMPP server a makeshift service bus.

For example: We can have an XMPP component send a message to another XMPP component.

This is an incoming issue tracking workflow built as decoupled processes connected to an XMPP server:

Email Server --->
   email:issues@mydomain.com --->
       **XMPP Component acting as an email client** ---->
            **XMPP Component which attempts to translate message into native language** --->
                **XMPP Component acting as a chatbot for issues notifications** --->
                     XMPP Clients within chat room --->
                          Developer eyes
                          Product management eyes
                **XMPP Component acting as a data store for issues** --->
                **XMPP Component acting as an email client auto-responder and FAQ** --->
                          Email Server

Each bold item is an XMPP component. If an XMPP component goes down, the message will be queued within the XMPP service until the XMPP component comes back up (TODO: verify!).

The top level XMPP component is configured to send to the translation service and wait for a response. On response, the top level XMPP component then sends to the three sub services: chatbat, data storage, and auto-responder. The only component that knows about the other components is the top level component. And even that can be avoided with the right configuration.