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
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.
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.
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.