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
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 “email@example.com” as being a username within a non-XMPP system.
For example: we can send to firstname.lastname@example.org 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 ... email@example.com: 15 minutes sound good?
The communication between “John Doe” and our phone number is handled via the XMPP component and SMS service.
We can use an XMPP component to expose some data in a viewable and editable form:
John Doe@chat.local: list events firstname.lastname@example.org: 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 email@example.com: 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:firstname.lastname@example.org ---> **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** ---> Postgres JIRA **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.