SOA Helps to Preserve OPEN/CLOSE Principle

Today major two technologies are used such as JAX-WS/JAX-RS and WCF to write Service Oriented Architecture based applications or rather to be more certain write services.

Whatever the technology is used, SOA enables lot of advantages. OPEN/CLOSE is one such indirect.

As everyone knows SOA is an Architectural Style where the services play an important role in the application. 

The major reason of using SOA is to expose the public and most used functionality as services while set of heterogeneous consumers can utilize the published services to complete their defined jobs. A good PDF about SOA can be found here.

If a sample SOA based application is drawn, it can be visualized as follows.

How SOA Works?

In simple terms, The service layer objects are (typically) deployed in an Application Server/Web Server where the service objects are deployed and Service Endpoints are exposed to the outside world. Service consumers can only see the service agreement which defines how to use service endpoints which ultimately lead to use the service objects. Each service object or rather a service knows when and how the data layer should be used to carry out the requested operation.

SOA gives well known advantages such as;

Interoperability: 

Where the service layer can be written in one technology and each consumer can be written in completely different technology. The is due to the machine independent communication mechanism.

Independency: 

Service can be written in complete isolation where consumer is given the service contract that defines (WSDL) how to access the service layer objects via service endpoints.

Heterogeneity: 

Services and Consumers can be in any platform and can have any hardware architecture. Each service is meant to deliver a unique service and service layer knows exactly when and how to incorporate data layer to process the necessary business logic.

Further: Advantages of SOA. click to OpenGroup or click developer.com 

Apart from the above mentioned features, SOA enables to protect OPEN/CLOSE principle.

What is OPEN/CLOSE principle? 

In Simple terms; it means that the code is OPEN (or allowed) for extension but CLOSE (or prohibited) for modification.Let’s take a look at what this means.

Traditional non-SOA type application has classes and methods where the operations are defined..

For example, a method skeleton that defines a search customerID and returns customer object.

public Customer SearchCustomer(Customer id)
{
    if(id.exists())
    {
        Customer obj= do_search(id);
        return obj;
    }
    else
    {
        return null;
    }
}

The method simply does its job for the moment. 

But in a later stage a new requirement is brought up such that customer object should be modified to cater specific customer types, in the sense that Platinum, Gold and Silver and also during the search, if the customer is platinum apart from returning the customer object the method should initialize the Platinum Offers and also the offer values may change time to time. This is the reality, "change requests" are mandatory to think in your design as well as in your code.

For more information about OPEN/CLOSE principle, please have a look here.

Now what the typical approach is change the existing method by adding necessary ‘if’ or "case" conditions and initialize Platinum Offer type object. This is is violating the OPEN/CLOSE principle. 

The consequence of keep on modifying the existing implementation is: poor maintainable, spaghetti, less performance oriented and less secure code or rather poor and UN-reliable application. 

Imagine if such modifications are in a large scale software then there would be quite many actions which should be completed to make sure that the modification done is accurate and well in quality. Few such actions would be;

• Need to exercise new and old test scenarios because the inserted code should not violate the existing (or old) functional requirements.
• May need to check and re-test the performance module
• May need to check and re-test security module
• etc.

This would be a burden which costs time and money.

This drawback is secured through the proper use of SOA. 

But HOW?

Each service is a loosely coupled and highly cohesive in standard practice. So the simple answer is:

Expose the two requirements as two separate services. 

SearchCustomer(Customer ID)

SearchSpecificCusomter(Customer ID)

In this approach, SearchCustomer(Customer ID) remain untouched.(CLOSE for modification) But introduce a new service SearchSpecificCusomter(Customer ID) (OPEN for Extension) which would satisfy the new requirement. If a new and unique requirement comes then it is just matter of extending the service agreement to another service to cater the new demand.

This approach may have code duplication but it is paid off easily by the amount of codes that may change in the existing code during the life time of the software. But remember that this is a decision that should be taken with care.

The same strategy can be used for different versions of the application too. For example;

version 1.0 has 4 services which do,

SearchCustomer(Customer id)

SearchSpecificCusomter(Customer ID)

UpdateCustomer(Customer id)

DeleteCustomer(Customer id)

And in version 1.1, the nature of the customer has been totally changed but still need to cater the same set of operations. So it would result to publish set of services that accomplish the changed requirements which can be drawn as follows.

As it is shown, the same container can be used to access version 1.0 and version 1.1 operations via the relevant service agreement.

Satisfying OPEN/CLOSE principle gives another set of advantages among the dozen of rewards of using SOA.