Enterprise Integration Patterns – the basics

Integration is a massive topic with hundreds, if not thousands of solutions, questions and answers. How do we pick our way through this minefield and come up with a solution that fits or enterprise?

It is vital that before we start to make decisions that could cost our business millions of pounds it is well worth taking the time to understand the basics of integration so that we fully understand the impact of the decisions we are about to make.

It may surprise you to know that there are only actually a few patterns on which all the enterprise architecture patterns are based.

  • Basic Synchronous Pull Pattern
  • Basic Synchronous Push Pattern
  • Basic Push/Pull Pattern with Persistence
  • Basic Push/Push Pattern with Persistence
  • Basic Asynchronous Pattern

(Actually the first two are all you need, the others are just the major variants…)

Lets first explain the patterns and then look at how we can make them more ‘enterprise ready’ and how we can make them work better with changes like transitional architectures.

Lies and Damn Lies

Ok those of you who are technically minded out there may already be saying – hold on we are missing out a whole raft of technical details about OSI models, networking, operating systems etc. The answer is yes, I know, but that’s another discussion, for another day and whilst it is important I am going to make the assumption that the appropriate layers are there below us, and are working but I am not going to assume they don’t fail.

For those who do care about this kind of thing, for the purpose of this discussion we will typically be hanging around OSI Layer 7 (application) and occasionally considering aspects of Layer 5 (session) although this will hopefully be transparent to the general reader.

Scene Setting

Before we start on the examples lets set the scene, for arguments sake we are in a pretty bog standard office environment, we use standard networking protocols (TCP/IP) we have a something in the way of network storage (e.g. NAS or NFS mounts), and we have a mix of Unix (various flavours), and Microsoft based servers to mess around with.

For our purposes we are going to assume we have two systems that need to talk to each other, and we are going to choose two hypothetical COTS (Commercial Off the Shelf) packages that allow us to customise interfaces to each other:

  • System 1 – ‘WizAStore’: a storefront web application that is there to display certain information about products to a user, create accounts, manage shopping baskets, and create orders
  • System 2 – ‘EntMine’: an ERP (Enterprise Resource Planning suite) this will be responsible for everything else in the organisation, product management, order fulfilment, stock management, finance – the works.

Whilst this is a very simple infrastructure it actually allows us to explore the basic range of the integration patterns that most organisations actually use.

ESB or Not to ESB…

Notice that our infrastructure does not include an Enterprise Service Bus (ESB). This is not a reflection on my preference for or against this technology, it is simply that for the purpose of this discussion we can consider an ESB as simply another level of indirection and that the patterns used either side of the ESB will follow one or more of the patterns that we are defining between our two systems.

If you do want my opinion though, ESB’s when used correctly can offer huge advantages both in terms of speed to develop integrations, minimizing effort to integrate COTS packages into our landscape, and also they can be a massive help when it comes to transitional architectures.