Service Oriented Architecture (SOA)

Service Oriented Architecture (SOA) is a computer systems architectural style for creating and using business processes, packaged as services, throughout their lifecycle.^[1] SOA also defines and provisions the IT Infrastructure to allow different applications to exchange data and participate in business processes. These functions are loosely coupled with the operating systems and programming languages underlying the applications. SOA separates functions into distinct units (services), which can be distributed over a network and can be combined and reused to create business applications. These services communicate with each other by passing data from one service to another, or by coordinating an activity between two or more services. SOA concepts are often seen as built upon, and evolving from older concepts of distributed computing and modular programming.^[2]

Service Oriented Architecture (SOA) is a business-centric IT architectural approach that supports integrating your business as linked, repeatable business tasks, or services. It is an architectural style, which requires a service provider, requester, and a service description. SOA contains a set of architectural principles and patterns that address characteristics such as modularity, encapsulation, loose coupling, separation of concerns, reuse, and composability.

A manifesto was published for service-oriented architecture in October 2009. This came up with six core values which are listed as follows:^[3]

Business value is given more importance than technical strategy.
Strategic goals are given more importance than project-specific benefits.
Intrinsic interoperability is given more importance than custom integration.
Shared services are given more importance than specific-purpose implementations.
Flexibility is given more importance than optimization.
Evolutionary refinement is given more importance than pursuit of initial perfection.

SOA can be seen as part of the continuum which ranges from the older concept of distributed computing and modular programming, through SOA, and on to current practices of mashups, SaaS, and cloud computing (which some see as the offspring of SOA)

The technology of Web Services is the most likely connection technology of service-oriented architectures. The following figure illustrates a basic service-oriented architecture. It shows a service consumer at the right sending a service request message to a service provider at the left. The service provider returns a response message to the service consumer. The request and subsequent response connections are defined in some way that is understandable to both the service consumer and service provider.^[4]

source: Barry & Associates, Inc

SOA Characteristics^[5]

Reusable: depending on their granularity, services can be used by multiple processes and other coarse-grained services.
Autonomous units of business functionality: each service provides a business function that is independent of other services.
Contract-based: interface and policies are strictly described by an interface specification.
Loosely coupled: service contracts are designed to be as independent of the service implementation as possible, minimizing the need for service contract changes if the implementation changes. In a tightly coupled system, an implementation change (e.g. a change in a back-end data type) would require a change to the interface and therefore the connecting systems.
Platform-independent: both the consuming and SOA service systems can be on any platform that supports the service transport and interface requirements.
Discoverable and location independent: services are located through a service registry/catalogue and accessed via universal resource locators, and therefore may move over time without disruption to consuming systems.
Standards-based: services are built, consumed, and described using standards such as Web Services Definition Language (WSDL), which provides information about the service, and Simple Object Access Protocol (SOAP), a packaging mechanism.

The Importance of SOA^[6]
Service Orientated Architecture is important to several stakeholders:

To developers and solution architects, service orientation is a means for creating dynamic, collaborative applications. By supporting run-time selection of capability providers, service orientation allows applications to be sensitive to the content and context of a specific business process, and to gracefully incorporate new capability providers over time.
To the IT manager, service orientation is a means for effectively integrating the diverse systems typical of modern enterprise data centers. By providing a model for aggregating the information and business logic of multiple systems into a single interface, service orientation allows diverse and redundant systems to be addressed through a common, coherent set of interfaces.
To the CIO, service orientation is a means for protecting existing IT investments without inhibiting the deployment of new capabilities. By encapsulating a business application behind capability-based interfaces, the service model allows controlled access to mission-critical applications, and creates the opportunity for continuous improvement of the implementation behind that interface. Service orientation protects investments from the swirl of change.
To the business analyst, service orientation is a means of bringing information technology investments more in line with business strategy. By mapping employees, external capability providers, and automation systems into a single model, the analyst can better understand the cost tradeoffs associated with investments in people, systems, and sourcing.
To Microsoft, service orientation is a crucial prerequisite to creating applications that leverage the network to link the actors and systems that drive business processes. This application model transcends any single device, crossing boundaries respectfully, and rejecting the restrictions of synchronicity. SOA-enabled solutions pull together a constellation of services and devices to more effectively meet your business challenges than the disconnected applications of the past.

The architectural concepts associated with SOA enable loose coupling. Loose coupling is the fundamental principle behind SOA, enabling us to summarize the benefit of SOA in a single word: agility.

Basic Principles of Service-Oriented Architecture (SOA)^[7]

Explicit boundaries: The concept of explicit boundaries in SOA means that you can deploy the service anywhere, and this service should be easily accessible by other services, regardless of the platform or programming language of the other service. This enables programmers to develop highly flexible services that are easy to implement and deploy across multiple platforms.
Autonomous services: The principle of autonomous services in SOA states that each service should be independent of other services. Each service should be properly managed and versioned so that it does not affect other services in the process. Each service should be built to handle changes easily without affecting the current system where it exists. For instance, you have an online store that uses two services - Order Processing and Order Delivery. These services should be independent of each other. For example, if the Order Delivery service is not available, then it should not affect the Order Processing service. Every precaution should be taken to make sure that service should survive even if its dependent service is not available.
Policy-based compatibility: Policy-based compatibility of SOA states that services that interact with each other should look at each other’s policy, and should only communicate with each other if they satisfy each other’s policy requirements. These policies exist in the form of machine-readable language. If the services need to interact again in the future, then the services should check the policy again. These policies enable the developers to move the service from one platform to another without changing the behavior of the service.
Shared schemas and contracts: A schema usually represents the data that a service passes. The contract represents the behavior of the service and contains information regarding the structure of the message. To enable a loosely coupled system, services pass schemas and contracts instead of classes and objects. Loosely coupled systems can be defined as systems in which the executing environment of a service does not affect other services. The information passed by these services is completely platform-independent.

Benefits of SOA^[8]
By following the service-oriented mindset with even more rigor, combined with the component-based approach to software development, your organization will realize many benefits.

Better Return on Investment: The creation of a robust service layer has the benefit of a better return on the investment made in the creation of the software. Services map to distinct business domains. For example, a company might create an inventory service that has all of the methods necessary to manage the inventory for the company. By putting the logic into a separate layer, the layer can exist well beyond the lifetime of any system it is composed into. For example, if your organization needs to create a credit card authorization service, there are basically two options. Developers will either develop the functionality as part of the application that needs it, or they will develop it as a separate component. If credit card authorization is developed as a separate component and used as a service, then it is likely to outlive the original application.
Code Mobility: Since location transparency is a property of a service-oriented architecture, code mobility becomes a reality. The lookup and dynamic binding to a service means that the client does not care where the service is located. Therefore, an organization has the flexibility to move services to different machines or to move a service to an external provider.
Focused Developer Roles: A service-oriented architecture will force an application to have multiple layers. Each layer has a set of specific roles for developers. For instance, the service layer needs developers that have experience in data formats, business logic, persistence mechanisms, transaction control, etc. A client developer needs to know technologies such as SWING, JSP or MFC. Each layer requires a complex set of skills. To the extent that developers can specialize, they will excel at their craft in a particular layer of the application. Companies will also benefit by not having to rely on highly experienced generalists for application development. They may use less experienced developers for focused development efforts. The creation of a service layer by definition means that developers have created an additional network interface that can be used by multiple applications. When systems were built using monolithic or client-server methods, security was normally handled on the front end. Companies often did not even implement database security because it is too hard to maintain multiple security lists. Services on the other hand are used by multiple applications, so they have their own security mechanisms. An application will therefore have multi-level authentication at both the client level and at the service level.
Better Testing/Fewer Defects: Services have published interfaces that can be tested easily by developers by writing unit tests. Developers can use tools such as JUnit for creating test suites. These test suites can be run to validate the service independently from any application that uses the service. It is also a good practice to run the unit tests during an automated build process. There is no reason for a QA tester to test an application if the unit tests did not complete successfully. More and better testing usually means fewer defects and a higher overall level of quality.
Support for Multiple Client Types: As a benefit of a service-oriented architecture, companies may use multiple clients and multiple client types to access a service. A PDA using J2ME may access a service via HTTP, and a SWING client may access the same service via RMI. Since the layers are split into client and service layers, different client types are easier to implement.
Service Assembly: The services that developers create will evolve into a catalog of reusable services. Customers will come to understand this catalog as a set of reusable assets that can be combined in ways not conceived by their originators. Everyone will benefit from new applications being developed more quickly as a result of this catalog of reusable services.
Better Maintainability: Software archaeology is the task of locating and correcting defects in code. By focusing on the service layer as the location for your business logic, maintainability increases because developers can more easily locate and correct defects.
More Reuse: Code reuse has been the most talked about form of reuse over the last four decades of software development. Unfortunately, it is hard to achieve due to language and platform incompatibilities. Component or service reuse is much easier to achieve. Run-time service reuse is as easy as finding a service in the directory, and binding to it. The developer does not have to worry about compiler versions, platforms, and other incompatibilities that make code reuse difficult.
Better Parallelism in Development: The benefit of multiple layers means that multiple developers can work on those layers independently. Developers should create interface contracts at the start of a project and be able to create their parts independently of one another.
Better Scalability: One of the requirements of a service-oriented architecture is location transparency. To achieve location transparency, applications lookup services in a directory and bind to them dynamically at run-time. This feature promotes scalability since a load-balancer may forward requests to multiple service instances without the knowledge of the service client.
Higher Availability: Also because of location transparency, multiple servers may have multiple instances of a service running on them. If a network segment or a machine goes down, a dispatcher can redirect requests to another service without the client's knowledge.

Advantages of SOA^[9]
A service-oriented architecture (SOA) solution concentrates and modernizes your IT structures while, at the same time, addressing legacy system and application issues – with minimal or no disturbance to your business. The advantages of this approach are as follows:

Synchronizes your business processes with technology to make your organization more competitive and responsive to change
Measurably improves customer service, satisfaction, and loyalty
Reduces total cost of IT ownership, freeing funds for strategic business investments
Increases operational speed and efficiency, user productivity, and organizational flexibility
Extends the useful life of in-place investments
Consolidates and streamlines operations
Provides timely access to more accurate enterprise information
Eases the establishment of secure, real-time communications with partners and customers
Helps efficiently manage suppliers, allies, and distribution channels
Shortens development and time-to-market cycles
Creates, enables, and optimizes new long-term revenue opportunities

source: Tridens

SOA As A Liability^[10]
SOA provides benefits in almost all cases of business organizations. However, in very special cases, it might prove to be a liability more than a drive towards better business. These cases include:

A homogeneous IT environment: If an organization depends on a set of coherent products—belonging to the same vendor, for example—, has a limited scope of work, and has no need to add or change any of these products, an SOA might be a liability more than a useful strategy.
When true real-time performance is critical: To provide loose coupling between different consumers and producers, an SOA depends on interoperable protocols, which are slow by nature. It can also induce mediation logic and asynchronous protocols, which aren't suitable for real-time performance.
When things don't change: If the customer sees no change happening to the business logic, presentation, data flow, process, or any other aspect of the application, converting old systems to SOA might not return sufficient value to make the effort worthwhile.
When tight coupling is not an inconvenience: Loose coupling is of best use when it's used with a component that's not under your control and, this, you can't control its change. On the other hand, when the component is yours and under your control, loose coupling can be a burden, especially if the component isn't really reusable.

References

↑ Definition of Service Oriented Architecture (SOA) [1]
↑ Explaining SOA [2]
↑ Service-oriented architecture - Defining Concepts [3]
↑ Service-Oriented Architecture (SOA) - Connections [4]
↑ what are the Characteristics of Service Oriented Architecture Services [5]
↑ Why should I care about SOA? [6]
↑ What are the Basic Principles of Service-Oriented Architecture (SOA) [7]
↑ Describing the Benefits of A Service-Oriented Architecture (SOA) [8]
↑ Service-Oriented Architecture (SOA) - how can today’s enterprises meet these challenges [9]
↑ SOA fundamentals in a nutshell - Is SOA always a better solution? [10]

Service Oriented Architecture (SOA)

See Also

References

Further Reading