As part of a service orientated architecture (SOA) I've been asked to create a web service which itself acquires data from a third party web service. I'm to hide any implementation specific details of the third party web service and map the data returned so as to avoid leaking any implementation details of the third party service.

I'm new to SOA. I would colloquially call this project something like "a web service bridge".
What is the correct SOA enterprise architecture pattern term for this?

I'm very confused as many of the enterprise architecture patterns seem to be describing the same thing (service facade?, message broker? message channel? proxy?). I don't think I'm quite in tune with the level of abstraction required.

  • 1
    No - the content is on an enterprise system that we paid for but we don't want to surface it in a proprietary form. We might want to change elements of the back end system (or swap it out for something else) without affecting the "enterprise" public interface to it. Commented Jun 19, 2014 at 8:52
  • 3
    A service gateway, perhaps? Commented Jun 19, 2014 at 8:53
  • Or maybe, just "service" (and in its implementation details it is seen that it calls another "service"). But "service gateway" is fine if you need an specific name.
    – SJuan76
    Commented Jun 19, 2014 at 9:59
  • Adapter patter?
    – Jim G.
    Commented Jun 19, 2014 at 17:09
  • I just discovered the term "Ambassador Pattern" in the context of container design patterns. I quite like that one. Commented Aug 7, 2018 at 7:02

2 Answers 2


Just by the question, one cannot pinpoint a single pattern because there are multiple aspects to a pattern. Depending on how your service is architected, the pattern can vary. In general, however, what you specified is the overarching Service Abstraction design principle.

Also, quite often a piece of software, especially at the scope of a web-service, is composed of multiple design patterns. Thus a web service may be designed with Model-View-Controller pattern while has a set of adapters, data mappers, (explained below) etc. in its various layers. You can still identify its primary business value and map that to a design pattern if that is important for your project. Thus, even though not all the patterns I talk about below may be considered enterprise design patterns by everyone, I find it more useful to use the pattern that conveys what the service does more than whether it is necessarily an enterprise design pattern or not.

From what you stated in your question, it seems most likely to be a Façade or its specialization Remote Façade. It would be a Façade if its primary purpose were to simplify the underlying API and hide the complexity (which is what you are stating). Remote Façade additionally also aims to reduce the number of calls between two systems if that's a concern.

An Adapter pattern is usually architected with an assumption that there are going to be multiple adapters (whether in present or in future). Thus, if your primary concern is to create a web service such that it would provide a consistent interface and be able to perform various operations on underlying service(s), then you are designing an adapter. A typical example would be when you are offering a new deployment service, and expose a method called Compile(). It implements two adapters, one for MSBuild and the other for nmake. Depending on which system a particular project is written in, it will pick up the correct adapter and issue appropriate commands.

A similar pattern is the Data Mapper which is mapping of a consistent set of data types to data types of various underlying data stores. Let's say if your service was exposing a UserId field to its client such that it mapped to a UserName and an UserPrincipal field in two different data stores, then this is what you are looking at. It does not mean that you necessarily have multiple data stores, it means that you are architecting with that possibility in mind.

The Bridge pattern is usually applied where there is an abstraction and its implementation, and yet both need to be varied. Typically, the implementation is achieved using an adapter pattern, so you end up with the Abstraction and its subclasses, as well as a set of adapters.

A Gateway is more around providing a consistent interface between services. So you could have a www.myservice.com which exposes a REST API, which in turn calls other services which may be using various protocols. It is the responsibility of the Gateway to ensure that clients always get the same interface, even when any of those services decides to change its protocols.


What you're describing is essentially the Adapter design pattern. You have an external component that you want to use, but it's implementation and interface is not what you want to use within your enterprise.

The fact that you're exposing your wrapper as a web service is irrelevant as the pattern is still the same. You're essentially wrapping an existing service with a new interface.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.