SOA concepts

SOA concepts

Now let's take a look at some SOA concepts to better understand what SOA is.

Definition of a service in SOA

There are a lot of different definitions of services, but I think these do the best job of explaining what a service really is.

From Web Services and Service-Oriented Architecture: The Savvy Manager's guide (see Resources for a link):

"A service is a function that is well-defined, self-contained, and does not depend on the context or state of other services."

From SearchSystemChannel.com (see Resources for a link):

"...a service is defined as a unit of work to be performed on behalf of some computing entity, such as a human user or another program."

Back to top

The concept of loose coupling in SOA

To understand the concept of loose coupling in SOA, you should first examine the concept of loose coupling in general. The following items demonstrate what loose coupling is and why it's valuable:

• An entity is coupled if changes to the entity by one party in the interaction require corresponding changes by the other parties (for example, business data s).
• An entity is declared if its behavior is specified in the interface to the service, and service requesters and providers can only interact if they have matching declared behavior. Declared aspects include security, transactional behavior, and quality of service (such as response time and delivery).
• An entity is transformed if it's declared by both service requesters and service providers, but the infrastructure provides some transformation capability to enable interactions between service requesters and providers that declare mismatched behavior.
• An entity is negotiated if both requester and provider declare a spectrum of behaviors they are able to support, and the intermediary infrastructure is capable of negotiating an agreed-upon behavior between them for each interaction.
• An entity is decoupled if changes to the aspect by one party in the interaction don't require corresponding changes by the other parties.

Loose coupling manifests itself in the SOA paradigm as follows:

• It helps to have an abstraction layer between the service producers and service consumers.
• Loose coupling promotes flexibility in changing the service implementation without impacting the service consumers.
• In the SOA approach, functionality is organized as a set of modular, reusable shared services. These services have well-defined interfaces that encapsulate the key rules for accessing the services. They're also built without making any assumptions of who will use or consume these services. Thus, they are loosely coupled to the consumer of these services.

Back to top

How does XML contribute in an SOA?

Based on open standards and promoting platform-independent business integration, SOA needs a common platform to base its infrastructure on. This infrastructure needs to be supported by all involved parties to form a common base of understanding. XML is at the core of this infrastructure for the following reasons:

• XML is the foundation for virtually all Web services standards, such as XML schema, SOAP, Web Services Description Language (WSDL), and Universal Description, Discovery, and Integration (UDDI). These standards leverage the core concept of XML-based representations, a worldwide supported format that carries out information interchange between service providers and requesters in an SOA.
• Using XML resolves the challenge of working with different data formats in different applications across multiple platforms.
• XML has the benefit of ease of representation, being text-based, flexible, and extensible by nature.

Examples of standards built on XML that SOA leverages include:

• SOAP: This simple XML-based protocol lets applications exchange information over transportation protocols like HTTP. Using XML in SOAP guarantees that the SOAP protocol is:
  • Platform independent.
  • Internet usable.
  • Humanly readable, structured, and text based.

  With the benefits above, SOAP is the recommended and most widely used communication protocol for Web services. Knowing that Web services are the cornerstone for SOA, it's therefore also the basic communication protocol for SOA solutions.

• WSDL: WSDL is a document written in XML to describe a Web service. It specifies the location of the service and the operations (or methods) the service exposes to let individuals access those services. A WSDL file describes four main things:
  • Services available by the Web service interface, such as listing names of methods and attribute messages
  • Data types of messages
  • Binding information for the transport protocol, such as HTTP and JMS
  • Service address to be used when calling it
• Electronic Business using eXtensible Markup Language (ebXML): ebXML is a standard way to define the business transactions that can be performed between different businesses. ebXML defines standard methods for business messages exchange, establishing trading communications and registering business processes between companies

Back to top

Service registries

A service registry is a directory of services available in an SOA system. It contains the physical location of services, versions and validity periods of services, service documentation, and policies. A service registry is one of the main building blocks of an SOA architecture. Its role is described below:

• The service registry realizes the SOA promise of loose coupling. By holding the service endpoint locations, it removes the high coupling resulting from hard-wiring the consumer to the provider. It also eases the potential difficulties in replacing one service implementation with another if needed.
• A service registry is highly scalable; it evolves seamlessly should the system it serves grow.
• It enables systems analysts to survey an enterprise's business services portfolio. They can then determine which services are available to automate processes to address pressing business needs and which aren't, letting you know what needs to be implemented and added to the portfolio, providing a catalog of the available services.
• A service registry can step into the role of governing services by enforcing compliance for subscribing services. This helps ensure the integrity of service governance and policies. You'll learn more about governance and its importance in SOA later in this tutorial.
• Visibility of the available services and their interfaces allows speedier development, greater application reuse, improved governance, and better business planning and management. The lack of a service registry leads to redundancy and inefficiency.
• Service registries help reduce time wasted in locating service information.
• Without a registry to track services and their relationships, an SOA environment not only lacks coherence and control, it invites chaos.

Back to top

What's a business process?

Business process is a term you hear used frequently in this environment. Here are two definitions of a business process:

From "Business processes and workflow in the Web services world" (developerWorks, Jan 2003):

"A business process can be defined as a set of interrelated tasks linked to an activity that spans functional boundaries. Business processes have starting points and ending points, and they are repeatable."

Another definition is: A business process can be seen as a set of activities performed by a business entity in response to an event. This set of activities is harmonized, described and integrated within the business process.

Issuing an identification card for a person is an example of a business process. You present your certificate of birth, your educational and professional papers, and a photograph to initiate the process. Then an internal file is created, a security investigation is conducted on you, and finally, after all the processing is done, you get an ID card.

In the SOA paradigm, the business process controls the flow of services. The business process drives the flow of events, calls and coordinates services, and creates a context for them to intercommunicate. Business processes represent the business abstraction; decoupled from the implementation of services, a process cares about the flow of business. This separation of concerns not only allows more focus on process creation, it makes it easier to edit processes according to need without having to edit the underlying service implementations.

Elements of a business process

It might be better to define a business process in terms of its composing elements; this provides some technical insight into a business process.

• Input: The information needed by the activities of the process to produce a result. In the example of the ID card, the inputs would be your credentials, birth certificate, and photograph.
• Output: All the data and information generated by the process. The output represents business goals and measurements needed for the business. In the ID card example, this would be an internal file for you and a physical ID card as well as measurements on how the process proceeded.
• Events: Notifications of some occurrence of importance. An indication, for example. They can occur before, during, and after the of a process. In the ID example, this might be the input of a new document that wasn't present at first and that needs to be included.
• Subprocess: Smaller process, or process steps, inside a process. A subprocess is used when it's not possible to represent the scope of work with only a set of activities. It has the same elements as the process. In the ID example, this might be the subprocess of investigating your criminal record and getting the results.
• Activity: The lowest level of work in a process. In the ID example, this can be the creation of a new internal file for you, the person getting the ID card.
• Performance metrics: Attributes that represent the effectiveness of a process to determine if it meets the required performance. These metrics help determine the performance and compare it to the required figures. They also point out potential areas of improvement in the process, ultimately, and ideally, realizing the cycle of improvement that the SOA promises. In the ID example, measurements would calculate which part of the process consumed most of the time or had the highest processing hit. This helps later on in improving the process.

Back to top

How does SOA address transaction control?

Because a process spans multiple activities, business transactions occurring within an SOA environment can be very complex. This is due to the nature of the services in long-running processes within the SOA context, which are often asynchronous, stateless, distributed, and opaque.

Web services are a perfect representation of services in an SOA environment. Being self-contained as needed by SOA, they are limited when it comes to the need of a cross-service transaction. As long as a service is at the root of a transaction and the scope of the transaction is limited to activities that are performed by the service's underlying solution logic, there's no need for cross-service transaction functionality, and the transaction can be managed by whichever proprietary technology (component-based, legacy, or otherwise) it encapsulates. But as the number of services in an environment grows, the need to span transactions across those services increases.

Some Web services specifications were developed to address the problem of transactions. These include:

• WS-Coordination: Enables registered processes to participate in an activity to create a shared context that's responsible for holding the stateful data and information propagated between them as well as the transaction state. The framework enables existing transaction processing, workflow, and other systems for coordination to hide their proprietary protocols and to operate in a heterogeneous environment. This protocol provides the infrastructure for other protocols, such as WS-AtomicTransaction or WS-BusinessActivity, which make use of its framework.
• WS-AtomicTransaction: Is used with short-lived distributed activities. It provides three types of protocols that can be used with the WS-Coordination framework for two phase commit ACID-type transactions (transactions supporting atomicity, consistency, isolation, and durability) to choose from:
  • Completion
  • Volatile two-phase commit
  • Durable two-phase commit
• WS-BusinessActivity: This protocol is used with long-running transactions with compensation processes. As with the WS-AtomicTransaction protocol, it uses the WS-Coordination framework to provide two protocols for business activity coordination:
  • BusinessAgreementWithParticipantCompletion
  • BusinessAgreementWithCoordinatorCompletion

Back to top

What's the role of standards in SOA?

In general, SOA projects are highly reliant upon standards, and leverage them because of these critical benefits:

• Standards ensure interoperability across system and partners.
• Using standards speeds up development and delivery through processes and tools.
• Standards enable better management and visibility of IT assets.
• Standards ensure quality of service (QoS).
• Standards help with flexibility by reducing dependencies on a specific implementation.

Next, explore a few examples of standards leveraged by SOA and see how they help realize its promises.

WS-Security

The WS-Security protocol is based on adding SOAP extensions to the message header to store security metadata that's intended to provide protection through message integrity, confidentiality, and authentication. Those extensions provide a general-purpose mechanism to associate security tokens to the message rather than a fixed security mechanism. The generic platform supports different security mechanisms. The protocol is designed to be extensible.

BPEL4WS

Business Process Language for Web Services (BPEL4WS) is defined in the OASIS online community for BPEL:

"This protocol defines a and a grammar for describing the behavior of a business process based on interactions between the process and its partners. It also defines how multiple service interactions with partners are coordinated to achieve a business goal, as well as the state and the logic necessary for this coordination."

As they are clearly needed, BPEL4WS introduces methods to deal with business exceptions and faults, as well as ways to compensate other committed processes that may need to be reversed in case of errors. Because BPEL needs to be supported universally, it's based on the universally acknowledged WSDL protocol, which, itself, is layered on XML.

WS-I

As declared on the WS-I Web site (see Resources for a link):

"The Web Services Interoperability Organization (WS-I) is an open industry organization chartered to establish Best Practices for Web services interoperability, for selected groups of Web services standards, across platforms, operating systems and programming languages."

This group is concerned with the development of Web services standards among different implementations, platforms, and their actual interoperability. Its main goal is to guide and advise organizations on how to ensure interoperability while interconnecting systems using Web services.

WS-I has four main deliverables:

• Profiles that are versioned specifications describing implementation guidelines and best practices for Web services that are interoperable and work together as a set
• Use cases and usage scenarios to demonstrate the guidelines in the profiles
• Sample applications
• Testing tools for profile conformance