One thing that I often get asked is "why do I need Adapters if I am moving to SOA?". My take on this is to think back to all those lovely legacy applications and the vital pieces of business logic and data contained within them.

The problem is that most people equate SOA to web-services, its not! Web-Services are a great way to implement SOA- BUT guess what, that creaking old application that hosts your purchasing system doesn't expose its business logic as a web service.

Furthermore, it is a massive business impact to move away from that reliable old legacy application to a new all singing all dancing application or a collection of services. I recently read that an IDC report estimates 70% of all business data is still stored in mainframes, this is a statistic that further backs up the lack of will to replace trusty old legacy applications.

The question is really how can I exploit these legacy assets in a service based architecture? The answer is of course to use adapters to enable us to break often brittle point-2-point links and expose the data and services contained within these applications in a way that lets us actualy implement SOA.

There is however, a grey area in what most people term "Adapter", I personally feel that the term has become synonymous with low level communications and vastly complicated integration engines. Actually, in my opinion, an "Adapter" is more of a plugin between an application and whatever solution is being used to deliver the SOA implementation. This could be a link to an Enterprise Service Bus (ESB) or simply a plugin that mediates a legacy application and allows it to be exposed as a web service that can participate in a BPEL process.