Tuesday, May 6, 2008

SOA Façade Pattern

In the last post, I discussed the value of the canonical modeling and described how to minimize the impact of canonical model changes on the service consumers. The solution was to use the façade pattern. I would like to elaborate on this topic since a more in-depth discussion is needed to define the pattern and understand its uses.

A good definition of the façade pattern can be found on Wikipedia: http://en.wikipedia.org/wiki/Facade_pattern. In general terms, it is described as “a simplified interface to a larger body of code”. This is exactly how it should be applied to SOA. A façade should be built in front of any service whose interface is based on the canonical model. Consumers would not access the service directly but rather through its exposed façade interface. In fact, the canonical interface should only be exposed for internal consumption. Each façade should be designed to be specific for each consumer or a group of consumers and not directly tied to the canonical model. The diagram below depicts the pattern details and its usage.


There are several distinct benefits of using the façade pattern.

  1. Façade shields service consumers from the changes in the canonical model.
    If every consumer was dependent on the canonical model, even the smallest change could have disastrous effects. All of the services as well as potentially all of the service consumers would need to be re-tested. Lacking automated regression and functional tests already developed, this would be a major undertaking. Using the façade pattern would minimize the impacts of any canonical model changes. Since the facades are specific to each consumer and are not directly tied to the canonical model, the only thing that would need to change is internal mapping between the façade interface and the canonical model.
  2. Façade hides the complexity of the canonical model.
    Modeling the whole business domain is not a simple task. Therefore, canonical models are usually large and complex. Service consumers do not typically want to know the entire canonical model and understand all of its intricacies. They want to get the data they need and continue performing their business functions. Exposing a consumer-specific interface via the façade prevents service consumers from having to know any canonical model details. Additionally, since canonical models are fairly generic, most of the data elements in the returned entity may not be relevant to the consumer. A façade simplifies the request and response data structures and ensures that only relevant information is returned.
  3. Façade returns data representation understood by the consumer.
    A canonical model is generic. It is designed to describe the whole organization. However, service consumers typically operate in their own specific domains. Service façade that is designed to return data in a format that consumers understand simplifies the overall consumption experience and reduces the overall efforts. The consumer does not need to perform any translations and can start working with the data right away. Additionally, a façade can help representing the same entity differently for different consumers if so required. There may be instances, for example, when one Line of Business (LoB) thinks of a customer one way while another LoB views a customer completely differently. These views may even be largely incompatible but as long as they are represented in the canonical model, a façade can be created to address specific LoB needs.

The façade pattern introduces a small translation layer between the service consumer and the canonical service interface. It should not contain any generic business logic but can perform some consumer-specific operations. While it may cause reduction in performance and increased development costs, the negative impacts should be minimal and will be offset by the benefits described above.

5 comments:

Aloha!! said...

1>Looks like the Middleware/ESB do the transformation between Canonical Model ( also known as Common Information Model) to the Consumer specfic Facade.

So which service WSDL does providers distribute when consumers want to consume a service. DO they distrubute WSDL based on the Cannonical Model or the WSDL based on Facade.

Vinaaayreddy said...

Its an awesome blog for ..
architects in bangalore as modern architectural firm working asinterior designers in bangalore know more about Green eco architectural designs are reusable materials, green designs etc.. ..… Create an Eco friendly Green design… Save Earth.. interior designers in Bangalore as of natural materials interior designers in Bangalore with almost modern concepts architects in bangalore eco friendly architectural solutions for architects in bangalore Carbon Footprint is a measure of the impact human activities have on the environment in terms of the amount of greenhouse gases produced, measured Architects in bangalore so save earth for a better future..

Michael Poulin said...

What is the purpose of FACADE in your cases? A user interface is a Facade for the user to something; it is a trivial statement and Facade Pattern has very little to do with this.

Mahesh V.C said...

I have seen Adaptor pattern used for the same scenarios explained too.

A.Armin said...

HI every body.
I am new at SOA architecture world. I have to implement a kind of chain of reaction in SOA architecture but I do not know which way is correct.
I have an object that contains other objects within the main object(nested object).
In front end user want to make some change in nested objects and I want to find a right solution to implement this one.
1- I thought I can have a flag in child objects and when I receive parent object I have to chech the child objects to make sure about changes on them, then I have to call related service for this child object to update it.
2- I can ask front end guys to force user first make change on child object and then use new values of the child objects?
please advise me.
Thank you