Mashed Articles

When doing message level encryption, the public key of the recipient is used to encrypt the source message. But how to obtain the encryption key of the recipient? Is there some directory (X500?) containing all these keys? Nope. Encryption keys are usually exchanged via out-of-band mechanisms.

For message level signing, things are much easier: a sender attaches its certificate to the signed message. The receiver checks the certificate first and next uses the public key contained in the certificate to verify the signatures. If the sender switches to a new private key, a new certificate containing the new public key is sent along with each message.

But what if a receiver wants to switch to a new encryption key? How to inform all senders that they should start using a new encryption key? What I’ve seen happening is that a company informs its business partners that they should all switch to this new key at exactly the same date and time. Clumsy solution. This could easily be avoided if ESB’s and B2B tools supported the use of both the old and new encryption key for a while (try to decrypt with the new key, next try to decrypt with the old key). But products don’t support this simple feature.

Note: switching to new encryption key is typical when the same keys are used for signing and encryption; the certificate needs to be renewed and this often implies a new keypair and thus new encryption key.

EDIINT/AS2 is a popular protocol for B2B communication. AS2 uses message level security extensively, both for signing and encryption. So AS2 uses are confronted with this challenge of key renewal. Now AS2 has an optional profile called “Certificate Exchange Messaging” that allows the automated exchange of new encryption keys! And it requires the parallel use of an old and new key.

This optional CEM profile exists already for a while but support is still limited: Axway, Cleo Communications Inc. GXS,Inc., Inovis, and SEEBURGER.

When the Amazon Simple Queue Service appeared about 2 years ago, I looked into it as a solution of message exchange between business partners. With its limited message size (only 4K) and message retrieval based on simple Amazon user accounts, I put the offering aside. The Amazon offering did however trigger me into wondering when the big Internet players (Google, Microsoft, Salesforce or Amazon) would enter the integration market.

But the ‘big’ players aren’t entering the integration world (yet?). Alternatively, software vendors could cloud-enable their software. Or anyone could leverage the cloud and develop an integration system on system on top of it.

Some scenario’s that I can envision, probably lacking some imagination here

• upload messages to the cloud from which they can be polled and retrieved (e.g. some central FTP or JMS server)
• service composition (something like Splice)
• business processes managed in the cloud through BPEL process engine (like RunMyProcess)
• service enabled integration solution (like Grand Central Communications once tried)
• XML gateway/firewall that filters traffic, enforces policies and forwards requests to different back-ends
• B2B hub (re-invention of the VAN)
• SOA governance as a service (sharing services within a community)
• Centralized SAML provider used by federation(s) of business partners
• WS-Trust Security Token Service (STS)

To learn about cloud computing and see how it could be used for cloud based integration solutions, I went through the book “Programming Amazon Web Services” by James Murty.

Initial conclusion/impression after reading the book was that Amazon services still lack some important features. Some limitations of the Amazon services:

• no fixed IP addresses, use of dynamic DNS required; with no URL pointing to the Amazon servers, own server in own data center required as main entry point
• EC2 instances loose all state when they stop or die (partially addressed with backups at short intervals)
• no SLA (except for S3), EC2 and SimpleDB are still “beta” (but so is gmail)
• payment via credit card (no formal ordering/invoicing)
• only forums to report and track problems, no formal communication channels
• propagation latency of newly or updated S3 objects (without even guarantee that you retrieve the latest document yourself because there is no guarantee that S3 requests will be directed to the same location)
• no transactions, e.g. when retrieving messages from SQS service
• no relational database
• no guarantees, everything on best effort

But since the publication of the book, a number of shortcomings were already addressed.

• Elastic IP addresses now offer fixed IP addresses and do away with dynamic DNS. A single EC2 instance can load balance request to other instances.
• Availability zones allow instances to be started in specific zones (read data center).
• Persistent storage for EC2 now provides a real file system for EC2 surviving restarts (although file system can only be mounted by 1 instance).
• And AWS Premium Support starts addressing the support issue.

So it seems that AWS can be used for some of my envisioned scenario’s. Open source project will definitely offer their integration solution As A Service on the Amazon cloud. I’m curious to see if and when the 1st closed source integration vendor takes the same step.

A post on the eai-select newsgroup mentioned OnlineMQ as an alternative to Amazon SQS. As stated in earlier posts, I think there is room and there are opportunities for cloud based integration solutions. A hosted queuing solution is a first step.

Therefore, I looked a bit around at the OnlineMQ website. I created a free (“Silver”) account and played a bit around. The service will officially launch in September. The paid subscription (“Gold”) is 60$/connection, no mention is made about maximum number or volume of messages.

Maximum message size is 256 KB, which is reasonable. Interesting feature is the option to configure a number of fixed IP addresses that are allowed to reach the server. It is typical in B2B solutions to work with fixed IP addresses and add extra security by only allowing access from the fixed IP addresses of your business partners. Which obviously requires everyone to have fixed IP addresses.

OpenMQ talks about JMS but doesn’t seem to support the JMS API (yet). However, OpenMQ does support REST, POX (Plain Old XML) and SOAP interfaces. For the SOAP interface, it uses the (non WS-I compliant) rpc/encoding. And security is not based on WS-Security.

It would be interesting to know more about the company or individuals behind this initiative. Even more as the company seems to be located nearby in the Netherlands. The online agreement refers to UK law being applicable, so that points to a British initiative. From a reverse DNS lookup, I learn that the IP address is owned by Level3. So the servers are located at a Level3 facility.