BEA recently announced that it is broadening its SOA consulting practice, and that it has created a tool companies can use to learn about SOA and figure out how prepared they are to transition to the new architectural model.

While BEA and other major vendors, such as IBM and Microsoft, continue to deepen their investments in SOA, many of us are still struggling to understand what SOA actually is.

How well do you know SOA? If you were asked to write a definition right now, what would it be? One of the challenges has always been to distinguish SOA from a standard distributed architecture that use Web Services. Another has been to pinpoint exactly what the well-publicized service-orientation paradigm includes.

To help with these questions, we asked noted SOA expert Thomas Erl to provide some clarity. Thomas wrote "Service-Oriented Architecture: A Field Guide to Integrating XML and Web Services," last year's top-selling book in both Web Services and SOA. He is releasing his second book, a 700 page effort entitled, "Service-Oriented Architecture: Concepts, Technology, and Design," later this year.

Below is an excerpt from his upcoming book introducing us to the basics of SOA and service-orientation.

Service-Oriented Architecture
There is no single, official definition of service-oriented architecture. Because the term "service-oriented" has existed for some time, it has been used in different contexts and for different purposes. One constant through its existence, though, is that it represents a paradigm based on the concept of decomposition. Something, anything that can be better constructed or carried out or managed if it is done so as a well-defined collection of related units. Service-orientation is therefore not always a technical paradigm. The Yellow Pages are full of service-oriented businesses. Individual companies are service-oriented in that each provides a distinct service that can be used by multiple consumers. Collectively, these businesses comprise a business community. It makes perfect sense for a business community not to be served by a single business outlet providing all services. By decomposing the community into specialized, individual outlets, we achieve an environment in which these outlets can be distributed. Even in a distributed model, if we impose overbearing dependencies, we could inhibit the potential of individual businesses. Although we want to allow outlets to interact and leverage each other's services, we want to avoid a model in which outlets form tight connections that result in constrictive inter-dependencies. By empowering businesses to self-govern their individual services, we allow them to evolve and grow relatively independent from each other. Though we encourage independence within our business outlets, we must still ensure that they agree to adhere to certain baseline conventions. For example, a common currency for the exchange of goods and services, a building code that requires signage to conform to certain parameters, or perhaps a requirement that all business employees speak the same language as the native consumers. These conventions standardize key aspects of each business for the benefit of the consumers without significantly imposing on the business's ability to exercise its self-governance.

When coupled with "architecture" service-orientation takes on a technical connotation. "Service-oriented architecture" is a term that represents a model in which automation logic is decomposed into smaller, distinct units of logic. Collectively, these units comprise a larger piece of business automation logic. Individually, these units can be distributed. Service-oriented architecture (SOA) encourages individual units of logic to conform to a set of design principles, one of which is to exist autonomously. This allows units to evolve independently from each other, while still maintaining a sufficient amount of commonality. It also results in a business automation environment with distinct characteristics and benefits.

SOAs can be extremely sophisticated. Current development tools and server platforms are constantly broadening the feature set and capabilities in support of the creation of service-oriented solutions. However, before we can discuss the many ways in which SOA can support enterprise-level automation, we must first look at SOA in its most fundamental form. This primitive model establishes the core architecture that underlies all variations of SOA. It consists of three primary components that form a unique relationship to achieve automation.

Services
Every business process consists of a series of steps. Larger processes typically include one or more sub-processes that support the parent process. These sub-processes also consist of a series of steps that reside within a logical boundary. The boundary encloses a distinct task or function provided by the sub-process.

Services represent real-life actions. The size or scope of the action is not pertinent to the task or function being encapsulated within a service. What's relevant is that the boundary of the task or function be distinct. Therefore, a service can represent any part of a process. It is important to note that in doing so the service establishes a standardized entry point into the process's business logic.

An extension of this concept into a physical implementation environment establishes a service as a self-contained unit of processing logic. The service also has a distinct functional boundary, and is designed to perform a specific task. Its task may be elaborate or limited. For example, a service may execute a series of actions involving other services. Or, a service's sole function may be to provide access to a fixed resource, such as a repository. Regardless, its most fundamental characteristic is that it is relatively independent or loosely coupled from other services.

Loose Coupling
Within SOA, loose coupling represents the basis of a communications agreement between services. The agreement consists of an understanding that in order for services to communicate with each other, they must be aware of each other. This awareness is achieved through the use of service descriptions. A service description, in its most basic format, establishes:

• the name of the service
• a description of the data expected by the service
• a description of any data returned by the service

An additional part of the loosely coupled agreement is that communication between services be self-contained as well. Meaning, each transmission of a unit of communication passed between services should occur independently from others.

So, having acquired service B's service description, service A communicates with service B. Service B receives the (unit of) communication but may not be obligated to respond to service A. Further, the communication itself occurred without any direct connection to service B. If service A had established a direct connection to service B, upon which it would have transferred data and received a response, the services would be considered tightly coupled.

Another characteristic of tight coupling is a dependency between units of processing logic. The logic is programmed in such a way that a change to one piece of logic could easily affect others that it references or that are referencing it. Therefore, if service A and B are tightly coupled, changes to one may require changes to the other. In a loosely coupled architecture, changes to either service would not affect the other as long as the original communication agreement (as expressed by the service descriptions) is preserved.

How do we achieve loose coupling? We need a communications framework that is based solely on the aforementioned "independent units of communication." This is where messaging comes in.

Messaging
Messages are a cornerstone technology of SOA. They are what implement and make many service-orientation principles possible, and form the basis for all inter-service communication. As with the concept of SOA itself, messaging-based communication is nothing new. It's been used by middleware products for years.

However, the preferred way to implement messaging in SOA is very specific. Once a service sends a message on its way, it loses control of what happens to the message thereafter. That is why we require independent units of communication to achieve true loose coupling. Messages, like services, need to be relatively self-contained. That means putting as much intelligence in a message as required. This includes the actual structure and typing of the message data.

Messaging provides SOA with the option of communicating synchronously or asynchronously. While SOA fully supports synchronous message exchanges, its emphasis on loose coupling and communication independence encourages asynchronous interaction scenarios. The net result is the ability to support a variety of communication models ("message exchange patterns"). Service-oriented messaging in contemporary environments relies on a sophisticated framework that supports the transmission and runtime processing of information-heavy messages. Messages can be equipped with a variety of composable features that can handle everything from security and reliable delivery to routing and the processing of polices.

Note how we just discussed the components of the primitive SOA model without referencing Web Services, WSDL, or SOAP. These technologies, of course, have become the most successful means by which to deliver service-oriented solutions. In today's SOA, services exist as Web Services, service descriptions are primarily realized through WSDL definitions, and messaging is standardized through the SOAP format. It is important to remember, though, that SOA, in a primitive form, is technology-agnostic. The same applies to the principles of service orientation.

Principles of Service Orientation
So far, we established that a fundamental SOA consists of a set of services that use service descriptions to remain loosely coupled and rely on messaging as a means of communication. These core characteristics are shaped and supported by the principles of service orientation, which form the basis for service-level design.

Earlier we established that there is no formal definition of SOA. There is also no single governing standards body that defines the principles behind service orientation. Instead, there are many opinions, originating from public IT organizations to vendors and consulting firms, about what constitutes service orientation. (See www.serviceorientation.org/ for more information.)

Service orientation is said to have its roots in a software engineering theory known as "separation of concerns." This theory dictates that it is beneficial to break down a problem into a series of individual concerns. By doing so, complexity is reduced and the overall quality of the collective concerns is increased. This theory has been implemented in different ways with different development platforms. Object-oriented programming and component-based programming approaches, for example, achieve a separation of concerns through the use of objects, classes, and components.

Serviceorientation can be viewed as a distinct manner in which to realize a separation of concerns. The principles of service orientation provide a means of supporting this theory while achieving a foundation paradigm for SOA as a distinct architectural model.

As previously mentioned, there is no official set of service-orientation principles. There are, however, a common set of principles most associated with service orientation. These are listed below and described in detail throughout this book.

• Services are reusable - Regardless of whether immediate reuse opportunities exist, services are designed to support potential reuse.
• Services share a formal contract - In order for services to interact, they need not share anything but a formal contract that defines the terms of information exchange and any supplemental service description information.
• Services are loosely coupled - Services must be designed to interact on a loosely coupled basis, and they must maintain this state of loose coupling.
• Services abstract underlying logic - The only part of a service that is visible to the outside world is what is exposed via the service's description. Underlying logic, beyond what is expressed in this description, is invisible and irrelevant to service requestors.
• Services are composable - Services may compose other services. This allows logic to be represented at different levels of granularity and promotes reusability and the creation of abstraction layers.
• Services are autonomous - The logic governed by a service resides within an explicit boundary. The service has complete autonomy within this boundary, and is not dependent on other services for it to execute this governance.
• Services are stateless - Services should not be required to manage state information, since that can impede their ability to remain loosely coupled. Services should be designed to maximize statelessness even if that means deferring state management elsewhere.
• Services are discoverable - Services should allow their descriptions to be discovered by and understood by humans and service requestors that may be able to make use of their logic.

Contemporary SOA
This introduction has only scratched the surface of this broad subject matter. The principles behind service orientation and the architectural paradigm established by SOA can be applied throughout an enterprise. When married with the open Web Services technology framework, it establishes an enormous benefit potential for increasing organizational agility and improving the lines of communication across previously disparate environments. Once taken to this level, a service-oriented architecture evolves into what we classify as "contemporary SOA." Implementing this comprehensive and complex model can significantly impact an organization. Business modeling, resource allocation, and technical infrastructure are just some of the areas that can be affected. The remainder of this book is dedicated to exploring the many aspects of contemporary SOA.

This has been an excerpt from: Service-Oriented Architecture: Concepts and Technology by Thomas Erl, approximately 700 pages, ISBN: 0131858580, Prentice Hall/PearsonPTR, Copyright 2005. (For more information, see www.serviceoriented.ws/.)