What Is Service-Oriented Architecture?

It is not practical to build monolithic systems in current multinational enterprises. These systems often take many years to implement and usually address a narrow set of objectives. Today a business needs to be agile and adapt processes quickly, and SOA is a design principle that can help address this business need. SOA is a well-defined services, where each individual service can be modified independently of other services to help respond to the ever-evolving market conditions of a business.Unlike traditional point-to-point architectures, an SOA implementation comprises one or more loosely coupled and interoperable set of application services. Although some of these aspects might be similar to a component-based development (which is based on strict interfaces), the key difference is SOA provides a message-based approach based on open standards. As a result ofbeing based on open standards and using messages that are generic and not representative of any specific platform and programming language, you can achieve a high degree of loose coupling and interoperability across platformsand technologies. Each of these services is autonomous and provides one or more sets of business functions; in addition, since the underlying implementation details are hidden from the consumer, any change to the implementation will not affect the service as long as the contract does not change. This allows systems based on SOA to respond in a quicker and more cost-effective manner for the business.

For a business it is usually cheaper to "consume" an off-the-shelf application service that constitutes the solution instead of writing all the functionality. If a specific module needs to be updated for some reason, the company also benefits from the changes being confined to the specific service.

When coupled with industry-standard frameworks, service-based solutions provide the highly flexible "building blocks" that business systems require to compete in this age. Services encapsulate business processes into independently deliverable software modules. A service alone is just a building block; it is not a business solution but instead is an autonomous business system that is able to accept requests and whose interoperability is governed by various industry standards. These building blocks also provide the basis for increased improvements in quality and reliability andin the decrease of long-term costs for software development and maintenance.

In addition, even though there is a lot of talk about SOA today, point-to-point architectures are not disappearing. Many companies have investeda lot of resources in implementing proprietary solutions that mostly fulfill their business needs. SOA makes it easier to integrate point-to-point systems more easily because one system does not need to know the detailed mechanics of the other system. For those new to SOA, it is a little difficult to grasp this concept initially. This is primarily because SOA implementations target back-end systems. As a result, from a user's perspective, there are few user interface (UI) changes. However, you can also utilize SOA to provide front-end UI implementations. You can achieve this by combining service output XML with XSL to produce target HTML.

The SOA paradigm departs significantly from the OO model, where you are encouraged to encapsulate data. Therefore, an object will hold and protect the data to facilitate a business need. The enterprise will consist of multiple objects that are specialized to handle "specific scenarios" with the data protected within the objects. SOA instructs you to utilize loosely coupled services. The service describes the contract to the consuming entities. It does not tightly couple data to theservice interface. It is also difficult to implement a single interface across all platforms and languages because of the nature of distributed systems. To fulfill the goals of SOA, it is essential to implement the interfacesin a generic fashion. As a result, you need to express application-specificsemantics in messages. The following are a few constraints for the messagesthat you need to consider when designing an SOA:

Descriptive

Messages need to be descriptive instead of prescriptive.

Limited structure

For different providers to understand the request, they need to understand the format, structure, and data types being used. This ensures maximum reach to all entities involved and limits the structure of the message. It also encourages you to use simpletypes, which are platform neutral.

Extensibility

Messages need to be extensible; only this provides the flexibility that allows SOA implementations to be quicker, faster, and cheaper than OO implementations.

Discoverability

Consumers and providers of messages need them to be discoverable so they know what is out there and how toconsume the available services.