Messaging as a service can deliver agility to your cloud

Explore an easily deployable alternative to VPNs for disparate location applications

Agility is a necessity for IT in organizations, but it is not always an easy state to attain, especially with the constant pressures of budget and people management. A question that every organization has to ask itself is, "Given restraints, how do we delivery agility, respond to changing priorities and demands, without incurring capital expenditures, dusting off long-forgotten source code, or re-writing security policies?" One tool that can help is the concept of messaging as a service. This article explores that concept.


Andy Pinkard (, Product Manager, CloudPrime

Andy Pinkard manages the full product lifecycle of the Cloud-based Business Messaging product portfolio for CloudPrime. Prior to CloudPrime, Pinkard was responsible for NAS gateway business in EMEA, for LSI Logic, following the acquisition of ONStor, where he was the WW Head of Systems Engineering and European Ops Director. Earlier, Pinkard served at Quantum 3D, the leader in COTS-based embedded real-time visual computing, spearheading the adoption into European and Asian Mil-Aerospace markets. He holds a Bachelor of Science in Physics from Birmingham University.

15 February 2013

Life would be much easier for IT provisioning if an organization's needs remained static. But it's just a fact of being an IT professional that you have to respond to scenarios such as:

  • A simple request to bring on a new supply chain partner who needs to both submit and receive data from that enterprise resource planning system that is scheduled for replacement "as soon as our budgets allow."
  • A need to move a series of applications to one or more cloud providers to free up in-house capacity, but also continue to use the existing long-haul network supplier for the balance of the contract.
  • A visit from your compliance officer saying that you need to track data sent out of the organization to that sweet enterprise dashboard software as service/cloud tool that you're bringing online.

These scenarios require an agile and adaptable application plumbing approach that augments existing infrastructure but can be provisioned quickly; one that provides the logging and reporting capabilities that your organization requires. We're going to suggest considering messaging as a service as one concept to address the needs illustrated in these scenarios.

Let's look at messaging as a service in more detail.

Messaging as a service

The "messaging" we’re contemplating is not an outsourced email or text messaging. In this context, we’re talking about the transfer of loosely structured data between endpoints in a secure, compliant, flexible way. The "as a service" part describes how it is implemented and the business model by which such data movements take place.

We could redefine messaging as a service as "a means of adding, extending, or replacing existing application to application data transfer in a way that requires few additional resources (software, hardware, people) while offering rapid bring up and ability to reconfigure, in a pay-as-you-consume model."

How would this work in a traditional approach?

The traditional approach

Typically, in order to extend a supply chain, the hosted applications of one partner need to talk to those of the other, and this generally requires a virtual private network connection between the two locations. Establishing an outside tunnel into your datacenter is not something to be undertaken lightly. It requires appropriate due diligence by all parties and close, secure administration guidelines.

Because allowing a VPN into the heart of your data isn't a simple task due to the security requirements, as the number of partner connections grow, so does the complexity and administration overhead.

A new partner may have to modify their application to conform to the other partner's requirements, which will extend the bring-up period with development and test cycles. And if the applications are "legacy" versions, such changes may not even be desirable or indeed possible.

We've actually developed a messaging as a service approach to avoid having to use a VPN tunnel. "Messaging" meaning the definition proposed earlier:

"a service to detail a means of adding, extending, or replacing existing application-to-application data transfer in a way that requires few additional resources (software, hardware, people) while offering rapid bring up and reconfigurability in a pay-as-you-consume model."

Let's look at this approach.

CloudPrime's messaging as a service approach

The architecture of the CloudPrime provision is shown schematically in Figure 1.

Figure 1. The CloudPrime component architecture
The CloudPrime component architecture

In Figure 1, all the components are certificated under the management of the CloudPrime Control, allowing for explicit access control during data exchange. The components within the Message Delivery Network can be established across regional zones within a single cloud provider or replicated across many independent providers. Message routing is under the command of the CP Control and can be constrained to meet any geographic compliance needs.

The key component in terms of application connectivity is the CP Connector. This small Java™-based software-only component establishes outbound secure connections to well-known addresses in the CP Message Delivery Network (delivered to the Connector at initialization and refreshed at appropriate intervals). At no time are connections required to be established from outside the partner's organization — that means no inbound ports are required to be opened and managed in the existing firewalls.

The CP Connector is configurable to support a wide variety of connection protocols including simple file collection and delivery from within a file system hierarchy. This is implemented via a channel:protocol mechanism in which a Connector is able to support as many channels as the system resources allow.

Each independent channel is configurable to differing levels of data protection, spanning from simple digital signing through to 256-bit AES. The CP Connector wraps the encrypted payload within an XML envelope containing the metadata used by the CP Managed Delivery Network (including destination address, time to live, archive retention period, etc.) This metadata includes optional fields that can be populated from the specific channel:protocol fields. Such optional metadata is archived alongside the payload (where enabled) for later analysis.

The enveloped data is then passed over SSL links to two or more CP Routers according to configuration. Once the Router acknowledges receipt, the Connector is relieved from any subsequent responsibility to take part in message recovery and retransmit.

The Router will forward according to its routing table and archive as required. All intra-instance messaging is via SSL links.

The receiving CP Connector manages sequenced delivery, eliminating duplicates and initiating message recovery where required. The receiving channel:protocol is independent of the sending channel:protocol pairing.

The CP Portal provides browser-based access to the logging and archive data. Since all data moved across the Message Delivery Network is logged at the "message" level, it allows administrators to quickly review when and where such messages originated and when they are ultimately delivered. If such a message was indeed a file, then the file metadata would be available for review; in cases where archiving has been enabled, the file itself would be available. Compare that setup to scanning endless VPN packet logs with cryptic commands and filters.

Any data (or file) captured by the Connector is guaranteed to be delivered to the destination connector, relieving any need for the application to be network-aware in terms of retries and acknowledged delivery. This feature allows applications originally designed to be co-resident with their peers on a highly reliable local network to be dispersed into clouds without recourse to explicitly dealing with network transients.

Example scenarios

Following are some scenarios that you may encounter using this approach. We mentioned these earlier, now we'll dig a little deeper into the details.

The new partner

In this scenario, a new supply chain partner needs to both submit to and receive data from an ERP system that is scheduled for replacement:

  • Neither party will have an appetite for lots of custom integration costs that will be lost when the ERP system is replaced. The integration role is provided by configuration of the CP Connector to deliver the data payload direct to the ERP system. The new partner can send data to the CP Connector at their end independent of the ERP system needs.
  • Only the CP Connector needs to be installed at each end; the rest of infrastructure is provided as a service.

Moving datacenter apps

This scenario entails moving a series of datacenter-based application data to one or more cloud providers using existing long-haul network supplier:

  • From a schematic point of view, what is required is a CP Connector channel:protocol pair to be inserted into existing application communication paths. Only a single Connector is required in each geographic instance, supporting multiple channels.
  • The addressing scheme by which the transmitting channel targets the receiving channel is independent of IP or DNS considerations, so Connectors can be relocated at will. This integration is "elastic" such that if at future time the partner application is moved to a public, private, or hybrid cloud, the connector moves with the application. No other reconfiguration is required. The communication paths between the Connector and within the Message Delivery Network can be over whatever network provider the partner wishes.

Tracking data

Here we track data sent out of the organization to an enterprise dashboard software as service tool.

As long as that data passes through a CP Connector, the compliance needs can be met. The location of this connector can be an instance in the same geographic location as the enterprise dashboard provider, in which case data transmitted over the public network can be further encrypted. It could also be hosted with the CP Managed Data Network as a proxy service.


CloudPrime offers IT administration staff and developers an easily deployable alternative to VPNs when applications at disparate locations need to be integrated quickly, reliably, and in an auditable way. Evaluation connectors can be simply installed to test the viability and ease of use.


developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into Cloud computing on developerWorks

  • developerWorks Premium

    Exclusive tools to build your next great app. Learn more.

  • Cloud newsletter

    Crazy about Cloud? Sign up for our monthly newsletter and the latest cloud news.

  • Try SoftLayer Cloud

    Deploy public cloud instances in as few as 5 minutes. Try the SoftLayer public cloud instance for one month.

Zone=Cloud computing
ArticleTitle=Messaging as a service can deliver agility to your cloud