Ramblings of an integration guy

IBM has just GA'd the API Connect Product offering. This offering is IBMs latest incarnation of their API-Management product set and combines several technologies. This entry discusses what it is and how you would use it in your business.

In my previous blog I discussed the various elements that go into making up API Management. In there I hinted that there is a strong relationship between API-Management and Enterprise Service Bus (ESB).  In this blog I'll explain what that relationship is...

API-Management and the 'API economy' is the a hot topic at the moment. Many customers have heard about it and seen the flurry of products that have been introduced into the market in recent years. However, when speaking with customers, it's clear to me that many are not clear on exactly what all the elements are that make up API-Management. This can lead to customers not understanding the architecture and sometimes the benefits of API-Management for their business. Here I'll break down API Management into its constituent parts and try to help you see why you might want them in your business.

Message Queuing at it's finest point is an art-form. It shouldn't be, of course, but it is. Most people won't need too high a quality of artist to work on their message system but, at the highest level of requirements you're going to need a Van Gogh working with you :-) I'm going to describe here a few pointers as to what to do when the message producers in a system are producing messages quicker than the consumers can process them or, as I would prefer to say, 'the consumers are processing the messages too slowly' ;-)

Customers often suggest that they want 'ordered messaging'. Many messaging providers suggest that they will give you ordered messaging. You'll see concepts like 'ordered queues' being discussed in many products. However, as always with one-liners, the devil is in the details.

I spend a lot of time at the moment doing things like capacity planning and telling people how many servers to put into their cluster. To my mind this sort of thing is how the world used to work and the future (looking from where we are today) is PAAS (Platform As A Service). In this blog I'll try to explain why I say that...

Often customers will say 'I want reliable messaging'. At this point I ask lots of questions – the main one being 'what happens if you lose that message'. Only then can I actually start to ascertain what *they* mean by 'reliable' In this blog I'd like to cover the messaging terms 'persistence', reliability', 'transactionality' and 'acknowledgements'. These are all terms used when talking about messaging. Unfortunately, it's the ease with which each term can interchange with the other that is the problem. Aligned to all these terms are the more specification like: at-most-once, at-least-once and once-and-once only.