Service Oriented Architecture

What is Service Oriented Architecture?

SOA is a business architecture where business functionality, or application logic is made available to users or consumers as shared, reusable services on an IT network.
“Services” in an SOA are modules of business or application functionality with exposed interfaces, and are invoked by messages.

What exactly the above definition means?

Business: Every business has these aspects that don't change very frequently. They
often represent a huge part of the business. We call these things the Core Business 
functions.

Example: Gas station sells gasoline in gallons.

Restaurants sells meals from a menu.


These are the core functions of both of the business mentioned above.

There are other things in a business that change very frequently. Prices, Tax rates, catalogs, new products, new customer areas etc. Indeed, business must be able to change, and change quickly, in order to survive. And yet, it is very important that those changes do not affect the core business functions.We know that software that changes frequently should be decoupled from software that changes infrequently. When it is applied to the information management of an enterprise, it is called SOA.

SOA is the practice to separate the core business functions into independent services that don't change frequently. These services are glorified functions that are called by one or more presentation programs. The presentation programs are volatile bits of software that present data to and accept data from, various users.

SOA is nothing more than separating changeable elements from unchangeable elements.

Let us see example –

In internet store-front. Customers use a browser to talk to the presentation software that displays the store’s website. The presentation software interprets the gestures of the customer and invokes services that do things like acquiring the data for the current catalog, or registering the customer’s order. The services have no idea they are talking to a website. They simply accept and return data in a standard format that the web system happens to be able to use.

Why is the separating important?
Consider that internet store-front again. It presents the user with a catalog, allows the user to move items into, and out of a shopping cart, and accepts the eventual order. The presentation of these concepts is very volatile. Marketing people are likely to want to change it frequently. For example, They may wish to present more or less descriptive data in the product list. But none of this has anything to do with the core business functions encapsulated by the services. Those services that acquire catalogs and register orders remain unchanged despite all the presentation thrashing. That’s why the separation is important. It protects the information processing assets of the business .But presentation is not the only thing that will change, but the business processes too. 

Again, consider our store-front. Perhaps our business has decided to offer fine wines as one of the products it sells. Selling alcohol requires that the age of the customer be verified. Let us say that we have a service that provides this verification. This service must be called for any order that contains alcohol products. The decision to call this service is neither a presentation decision, nor a service decision. Rather it is part of the business process for a particular kind of order. Business processes are volatile. As businesses grows they add more and more complications. Therefore we want to separate the business process from the services and from the presentation.

SOA is not about any particular technology. Rather it is a design philosophy that decouples well heeled business functions from volatile processes and presentations. It is the Model-View-Controller of enterprise software 

Value for Quality Professionals and Engineers
Software professionals know testing early and often is essential to having reliable software and reducing the risk of costly failures. However for complex Service-Oriented Architecture (SOA) applications, testing can no longer simply be a phase in the development process. 

· How is testing SOA different from testing typical applications? To avoid the unintended consequences of change in SOA applications, continuous functional and performance monitoring of the business workflow must occur. 

· SOA is by nature a heterogeneous environment, so tests must be able to invoke and verify functionality and performance at every layer of the architecture.

· In SOA, most of the business logic does not reside in the user interface, so tests must span multiple layers of the architecture and support dynamic test data. 

· Management, Policy and Testing are the key supports for an SOA governance strategy. Good SOA testing practices contribute verifiable examples of Policy that are shared throughout the management process.

· Continuous testing must happen at both build and runtime, as each layer of SOA applications can be developed and introduced into the active deployment on its own lifecycle.

· Extensibility of SOA testing is important, since all enterprise environments contain legacy applications and custom components that contain key business functionality.