Using a service registry that doesn’t suck part II: Dear registry, do you have to be a message broker?
Continuing our series of posts about service registry patterns that suck, we decided to address one of the most common techniques that Service Oriented (SOA) governance tools use to enforce policies.
Scenario
Service registries and repositories serve typically as a mechanism for storing service policies that model behaviors such as security, trust, reliable messaging, SLAs, etc. This makes perfect sense given that SOA governance registries were conceived as a mechanism to store and manage the policies associated with a service. When implementing a SOA governance strategy, you quickly need to decide how are you going to author and enforce policies across the services and clients in your SOA infrastructure.
The screwed-up traditional solution: Centralized policy enforcement
In recent years, it has become more obvious than ever that traditional SOA Governance tools have major challenges managing and enforcing policies on services built on the recent releases of the major web services stacks.
Why is that?
Well, the answer has to do with the fact that web services stacks such as Windows Communication Foundation(WCF), Oracle Metro or Apache Axis2 have evolved way faster than SOA governance technologies such as SOA software or Systinet. To think on a good analogy, think about trying to fix a modern airplane in a car garage; whereas you might be able to pull it off, you will certainly be very constrained to the types of problems you can fix ;)
![airplane[1]](http://weblogs.asp.net/blogs/gsusx/airplane1_thumb_2116F4F9.png "airplane[1]")
Similarly to this somewhat silly analogy, the policies that are available with traditional SOA governance tools are very limited compared to the capabilities of modern web services engines. What is an even worse, traditional SOA governance frameworks rarely provide native integration with web service stacks in order to apply these type policies.
Think about it, when a tool built on a very limited web service stack attempts to manage all web service frameworks in the market chances are that will end up not managing any of them very well J Don’t you think?
To overcome these limitations, SOA governance tools have taken a very simplistic approach of not only being the single policy repository but also acting as the centralize policy enforcement point. The following diagram illustrates this concept.
![CentralizeMessaging[1]](http://weblogs.asp.net/blogs/gsusx/CentralizeMessaging1_thumb_01F085C1.png "CentralizeMessaging[1]")
In this model, the SOA governance engine will enforce the service policies by brokering the communication between client and services. Looks beautiful to me J Do you see anything wrong with this approach? One simple thought, IT DOES NOT SCALE!!!!! Time and time again we’ve witnessed SOA governance tools that follow this pattern become a performance and scalability bottleneck in SOA infrastructures. Bottom line, SOA governance tools should act as metadata repositories and NEVER as message brokers.
Can we do better?
The SO-Aware way
In SO-Aware, we decided to take a different approach to this problem by not acting as a message broker and instead let developers host and scale their web services using traditional hosting infrastructures such as IIS, WAS or the Windows Server AppFabric. How do we accomplish this? Very simple, SO-Aware exposes policy artifacts such as WCF configuration files as RESTful resources accessible via an HTTP GET. We then have specific extensiblity points for the various Web Services technology stacks that are responsible for downloading the policies and applying to the respective services and clients. The following figure illustrates this concept.
![FedPolicies[1]](http://weblogs.asp.net/blogs/gsusx/FedPolicies1_thumb_6D1E8D40.png "FedPolicies[1]")
In the case of WCF, this approach allows to completely centralize the configuration of WCF service and client applications. For instance, we have current production deployments on which SO-Aware is centralizing the binding and behavior configurations for hundreds of WCF services and clients across different environments. This approach enforces the configuration management and consistency without really imposing constraints in the performance or scalability of the solution.
I hope this makes some sense? I would love to hear your thoughts ;)