Enterprise Service Bus (ESB) – A software architecture model used for designing and implementing interaction and communication between mutually interacting software applications in service-oriented architecture (SOA).
The platform is based on SOA 2.0 and enables a bidirectional event based communication model unlike the request/response model used in first generation SOA (1.0). SOA 2.0 adds significant benefit, efficiency of real-time communications and a variety of services not easily available with SOA 1.0 or standard web-services like SOAP or REST.
The platform Structure and Services
The major functional layers and components of ConnectingYourThings Platform are shown in Figure 1. The Edge directly interacts with devices, external applications and other internal or XMPP services to control security and message flow. The Application Processing layer is responsible for hosting existing and future applications for messaging, content, transformation and exceptions as part of any integration or The platform based application function (existing ecosystem applications include Pub/Sub, MUC & Purposeful Engagement Eventing). The Core Engine is tasked with session/cache management, including across clustered deployment, routing of events and messages within the platform infrastructure, monitoring of performance exceptions accessible from the management UI and other services. Persistence configuration and software updates of the cluster and its hosted applications are also managed in the Core Engine.
Device ESB versus Standard ESBs
ConnectingYourThings focused their development on the Internet of Things (IoT) designing an ESB focused on the connection and use of device data for Remote Device Management (RDM), machine-to-machine communication (M2M), workforce management, command control and communication computers(C4) and other related applications.
The first significant challenge was developing an infrastructure that could support the vast number of concurrent connections required by the exponential growth in IoT devices and applications which can include computers, smartphones, airplanes, GPS, thermostats, air handlers, pace makers etc.
Utilizing XMPP and WebSockets, the platform provides a powerful and secure mechanism of communication that includes the standard command/response and one way messaging, but also includes presence. Presence is a unique and efficient way to deliver data and status of any endpoint to applications, individuals and other devices that need it automatically.
Logos used are for representation of verticals and do not necessarily represent current participants in ConnectingYourThings provider platform
Moving from a Network to a Fabric
The IoT is an ever changing, ever evolving infrastructure. With mobility being part of many “Things” it is impossible to conceive that today’s network topology based stationary objects and dedicated connections will be functionally sound and allow the IoT to develop. What is necessary is the ability to move objects from one communication point to another and shepherd them based on location or status while staying connected to the proper domain. In standard XMPP platforms, rostering of objects is the de facto setting, requiring all applications and endpoints to be aware of one another and each filtering through presence messages to determine which items are truly meaningful.
The platform enables Purposeful Engagements, applications built within the platform framework, or connected externally can receive only the presence message that relate to them. As presence packets are sent to the platform Cluster/Server the system looks for specific values in the presence and when conditions are met devices are automatically flocked into preconfigured groups and the owner(s) is notified and will start receiving presence from that device. Purposeful Engagements allows awareness to object location and state more expeditiously then other methods by reducing the time to analyze and direct the messages received, creating better efficiencies within the IoT.
Purposeful Engagements consist of filter criteria and three event triggers. Events are triggered when an endpoint enters, leaves or changes value within a purposeful engagement and can be configured or programmed to take an action. Some of the default actions include notifying roster owner(s), sending a command to the endpoint or running a process, the configuration of purposeful engagement is done by sending a configuration to the server. Configurations are easily added, removed or updated through UI or can be automated. This model allows BIG DATA analysis to be pushed toward the edge of deployment without having to update every device being monitored and your organization to take action from BIG DATA decision making in real-time.
Very interesting, but do you really think XMPP whith it primarily focus as IM protocol is the right fit? Isn’t it is quite heavyweight and its extensively XML usage making it verbose. Did you think about MQTT?
As Any Piper wrote a in a further comment “I know that folks at CEIT at the Uni of Brisbane have specifically studied the differences and optimal uses for the two protocols. MQTT is very lightweight and low power – it has been used for telemetry and sensor applications for over 10 years and has been deployed on a very large scale by IBM and partners. Folks are now finding that a simple protocol like this is ideal for mobile development.”
Since those days a lot of development and standardization of MQTT has happend, even that you now can get those edge components using MQTT – seems to be a good fit for your IoT ESB structure.
Wolfgang- Thank you very much for commenting, I have had these discussions with Joe Speed at IBM.
I have posted on the subject in both Knocking out the Heavywieght label of XMPP” and the “Choice of Protocol” on my blog as well as prepared a comparison document Prasaga vs MesssageSight that may change your mind.
IBM is trying to resurrect a protocol that is a one trick pony and not made for IoT, it is great for closed locked down networks.
IBM is trying to keep the bloated WebSphere product relevant by adding another appliance/point of failure to an infrastructure that is full of bloat, latency and points of failure which is what they are responsible to due as their master ins the share holder and margins.
Prasaga platform handles 1.5x concurrent connections as IBM’s and message per second is approx the same (actually if I benchmarked 1 bit messages I could do 120,000,000 per second).
In march of 2013 at Percom in San Diego, SAP presented a paper, A Service Infrastructure for the Internet of Things based on XMPP, along with Dresden University that concluded XMPP is their choice of protocol for XMPP.
I look forward to more discussions with you, please read the rest of my posts and let me know if you have any questions.
Pingback: SOA 2.0: XMPP como ESB para el IoT | Bosque Viejo·
Thank you very much for adding the article to your post.
Pingback: Oracle: Enterprise Service Bus | SOA Developers Blog·
Pingback: IBM: Patterns: Integrating Enterprise Service Buses in a Service-Oriented Architecture | SOA Developers Blog·
Pingback: Defining ESB: Exactly What Is It? | SOA Developers Blog·