Integration Discussions and Vendor Strategies

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. 

Following quickly on from my last post about the  WSO2 MessageStore and Processor overview  - Here's a quick guide to actually using the stuff and setting it up using WSO2's own message broker

All of the Enterprise Integration Patterns are supported by WSO2 ESB and the store and forward pattern is one such pattern [1] The Store and Forward EIP pattern That page gives you a nice view of the pattern at a high-level and I thought I'd embellish it a little with my findings in this blog entry and the next to bring you all the info in one place.

When we first set up our PureApplication Practice, DevOps was not an issue that customers came to us with, but, as time has gone on, more and more customers are starting to identify with having a “DevOps” problem. Here I try to define the DevOps problem and discuss how IBM tools like PureApplication and UrbanCode could help.

I’ve recovered from all the excitement at IBM’s InterConnect and I’m ready to share the latest and greatest with you on the recent announcements around PureApplication.