Effective SOA Governance

Now a day it is of paramount importance that an enterprise that is strategizing around SOA needs an efficient governance mechanism. SOA governance is more than just providing governance for SOA efforts; it is how IT governance should operate within an enterprise that has adopted SOA as its primary approach to enterprise architecture.

Steps for effective SOA governance

1.       Governance should be included from very beginning of SOA initiative.

·         Because of the nature of discrete, well-defined services within a SOA, governance is not exclusively a runtime or design-time activity. SOA governance happens all the time—design time, run time, and change time—and architects understand this.

2.       Effective SOA starts with governance but a governance solution need to be sold to business to get necessary funding. Approach executive management with the justification for SOA governance. Business should understand the benefit of SOA governance for getting support. E.g.  Hartford case study. There was firm commitment from Leadership team of Hartford to put governance in place.

Business team need to understand the benefit of codifying best practices, processes and rules into reusable services based on

·         Better control of business solution

·         Enabling business and IT teams to collaborate based on business requirements.

Business team needs to provide support for SOA governance

·         Cross organizational oversight

·         Centralize management of adoption of SOA across organization

·         Encourage collaboration across business units with different perspectives.

3.       Create a comprehensive plan to create high value and right business service with executive support. Roadmap is needed to ensure success.

·         Begin with understanding of the corporate goals and objectives of the business. Establish a governance process before your organization begins building business services.

·         Choosing projects that integrate and automate business processes that have the most widespread, visible, and positive impact across the organization enables IT to both qualitatively and quantifiably demonstrate the value of well-governed SOA to the business.

·         Develop a process to catalog information about each service- definitions, control, and change management.

·         Plan to ensure services are safe to use i.e. security

4.       Establish process for organizational change-managing change is as important as creating SOA services.

·         Put processes in place to keep track of which business services are developed and when/how they are changed

·         Avoid chaos by creating systematic approach to notification and approval for changes.

·         Business need to agree on business rules to ensure stability and trust.

·         Create business services in a predictable manner based on corporate governance requirements.

5.       Balancing risk with oversight to find proper balance for SOA governance.

·         How much risk can you afford to take?

·         Which business need high level of oversight at corporate and IT level? Some business process require high level of oversight other not. There should always be room for innovation. Future innovation should not be constrained.

·         Build flexibility into your governance model.

6.       Governing Service Lifecycle – ongoing process

Governance process needs to be ongoing. Step to manage service over their lifecycle

·         Decompose parts of business processes

·         Identify the service owner.

·         Identify the source of funding.

·         Govern services from an end to end perspective, so they are not viewed as isolated elements.

·         Provide support to ongoing services.

·         Ensure service meet the corporate objectives. As corporate objective change services change

In the end some important points

·         SOA demands a business focus to be effective

·         SOA demands that you codify business processes into reusable services

·         Trust is the heart of SOA governance – predictability is the foundation of trust

Business and IT are jointly responsible for ensuring that software reflects best business and IT practices

Singleton Design Pattern

The Singleton creation pattern is a common programming idiom.The Singleton is a useful Design Pattern for allowing only one instance of your class to be created, but common mistakes can inadvertently allow more than one instance to be created.

The classic example is:

This is a good solution and design of this class ensures that only one Singleton object is ever created. The constructor is declared private and the getInstance() method creates only one object  In the general case, however, it is not thread-safe. This implementation is fine for single threaded program but when multiple threads are introduced then getInstance() method must be protected.

Consider two threads calling the getInstance() method concurrently and the following sequence of events.

1. Thread A calls the getInstance() method and determines that instance is null at //1.
   
2. Thread A enters the if block at //1, but is preempted by thread B before executing the line at //2.
   
3. Thread B calls the getInstance() method and determines that instance is null at //1.
   
4. Thread B enters the if block at //1 and creates a new Singleton object and assigns the variable instance to this new object at //2.
   
5. Thread B returns the Singleton object reference at //3.
   
6. Thread B is preempted by thread A.
   
7. Thread A starts where it left off and executes line //2 which results in creation of another Singleton object.
   
8. Thread A returns this second object at //3.

The above classic example creates two Singleton objects when it should create one. This problem can be corrected by synchronization of getInstance() method, which would allow only one thread to execute at a time in getInstance() method.

 

The synchronized code mentioned above works correctly for a multithreaded access to getInstance() method. But on carefully looking at the code, you can easily make out that instead of synchronizing whole of getInstance() method, synchronization is required only for the first invocation of the method. Subsequent invocations to getInstance() method does not require synchronization because the first invocation is the only invocation that executes the code at line //2. Synchronization has performance cost associated with it, so in order to make above program more efficient we have following third approach.

SyncSingleton_2 class also exhibits the same problem as was there with the Classic approach.

Consider two threads calling the getInstance() method concurrently and the following sequence of events.

1. Thread A calls the getInstance() method and determines that instance is null at //1.
   
2. Thread A enters the if block at //1, but is preempted by thread B before entering the Synchronized block..
   
3. Thread B calls the getInstance() method and determines that instance is null at //1.
   
4. Thread B enters the if block at //1 and creates a new Singleton object and assigns the variable instance to this new object at //2.
   
5. Thread B returns the Singleton object reference at //3.
   
6. Thread B is preempted by thread A.
   
7. Thread A starts where it left off and executes line //2 which results in creation of another Singleton object.
   
8. Thread A returns this second object at //3.

To fix the above problem there is solution which require that a second check should be made before creating the object. This method is called Double Checked locking.

The concept behind double-checked locking is that the second check at //2 makes it impossible for two different SyncSingleton_3 objects to be created.
The concept behind Double Check Locking makes it perfect, but this is not the case.The problem with double-checked locking is that there is no guarantee it will work.This is because of Java Platform memory model which allow out-of order writes. We won't be covering that here.

The bottom line is that double-checked locking, in whatever form, should not be used because you cannot guarantee that it will work. So there are only two options left which are as follows.

1. First is to synchronize getInstance() method, which we have already covered above.
2. Second is to let go synchronization and use static instead, which we will cover now.

In the above scenario StaticSingleton object is not created until call is made to static getInstance() method. This is a good alternative is you donot wish to use synchronisation.The Java specs guarantees that the static initializer will be executed only once, at class load time. There could be an argument that, this would create an object if someone refers to the class or at class loading time even if it is not used and this becomes a valid argument when the object is heavy.

An embedded static final class can defer this as shown below

 
If someone happens to refer to StaticSingleton.class , the singleton object would not be created unless explicit call to getInstance() method is not done.At that time, SingletonHolder is referred to; its class loads; and its static member instance is instantiated.

There is one thing clear after above discussion on Singleton, that any implementation should be matched carefully to the application at hand.