“Service-Oriented World” Cheat Sheet: A Guide to Key Concepts, Technology, and More — Part 1

It’s no secret that we are fans of services and service-oriented architecture. For years, we have been proclaiming the significance of service—oriented architecture and Web Services technology in creating an adaptive IT architecture for customer experience.

More recently, we have shared our belief that the current uses of SOA for integration and customer- (user-) facing applications are merely the first stages of the service-oriented evolution. Over the next few years, SOA will be the springboard for innovative IT shops to move towards business scenario development. In business scenario development, IT business solutions will be compositions of services, business events, and business processes. These compositions match the interactions of your business—with customers, partners, employees, and regulatory agencies—in support of commerce, collaboration, and information exchange.

Now, everyone is talking SOA, services and Web Services. If you Google “service oriented architecture,” you get almost 12 million hits. 12 million hits for an IT concept with “architecture” in it! And if you Google “Web Services,” over a billion hits! While that’s no indication of true adoption, it certainly does validate the buzz factor.

In fact, so many people are talking SOA, and labeling their products and services accordingly, OASIS has recently formed an SOA reference model technical committee. According to the May 3, 2005, OASIS news release¹, “the SOA reference model will offer an understanding of the core elements within a service oriented environment and the associations and relationships among those elements.” Essentially, the intent of the reference model is to separate fact from fiction—to provide software and application architects a starting point to delivering SOA solutions. This is good, but as we all know, it will take time (perhaps a lot) to complete.

In the meantime, as a service to our clients who are interested in, or are pursuing a service-oriented strategy, we have developed this overview report on services and SOA. This “SOA Cheat Sheet” report includes key service concepts, information on supporting technologies, a view of the SOA landscape, and some keys to SOA success.

Service and SOA Basics

What Is a Service?

Simply stated, a service is a thing that fulfills a purpose. A service is, in essence, a “worker,” employed to achieve a specific end goal for a requester. The end goal may be small in scope, such as retrieving information, or large in scope, such as executing a business process. Most services are in the middle, completing a function. The scope of a service is referred to as its grain, or level of granularity.

WHAT KIND OF THING IS A SERVICE? A service is an abstract resource that has a name, a job, job tasks, contact information and policies regarding security and service levels. To use (request) a service, you send a message—in accordance to the contact information and policies—and then (if appropriate), receive a reply message.

A SERVICE’S JOB. The job of a service is limited to a single distinct business concept, function, or process. This characteristic is referred to as the bounds of a service. Finding the correct bounds is a key factor in service definition. A service may call upon other services if it needs assistance to complete its job. This service-to-service relationship is called collaboration.

SERVICE COLLABORATION. Services collaborate through orchestration, business interaction, or interception:

• Orchestration is a type of collaboration in which the primary service directly invokes other services. The primary service knows the sequence of actions and the interfaces, responses, and return states of the called services.
• Business Interaction is a type of collaboration in which some coordination mechanism knows the sequence of actions, possible states, and paths of interaction among one or more services. The business interaction is usually long-lived involving requests/messages from multiple parties. The coordination mechanism may be a business process execution engine, a workflow engine, an event handler, or an enterprise service bus.
• Interception is a type of collaboration in which an intermediary service receives and acts on a request (or reply) and then forwards the request (or reply) to the original target. Interception is used to perform common functions such as security, policy, audit, and translation. In many interception scenarios, the requesting and providing parties are unaware of the intermediary service.

NOT ALL SERVICES ARE ALIKE. Not all services are simple information-oriented requests/replies. Beyond request/reply, a service may be a worker, a monitor, an agent, an aggregator, or even a process.

• Request/Reply is an information-bearing service. The service either retrieves information and/or performs a calculation/manipulation on behalf of the requester to produce a result. The Request/Reply may perform information update tasks, but it often calls upon a worker to add, change, or delete information.
• Worker performs a function, most likely changing the state of the thing it works on.
• Monitor is a service whose job it is to observe something and report on its findings based on monitoring and notification rules.
• Agent is a service whose job it is to observe something and then act on its findings. An Agent shares behavior with a Monitor in that it observes based on monitoring rules, however an Agent differs from a Monitor in that it may take action(s) based on its findings.
• Intermediary is a service that intercepts a service request (or reply), performs a value-added function (usually translation or policy), and then forwards the enhanced message to the original target.
• Aggregator is a service that combines results from federated sources or services. A Request/Reply service may use the Aggregator. Aggregator services will play a role in right-time architecture, business activity monitoring (BAM), and the Grid.
• Process is a long-running service, coordinating the actions of multiple parties through a series of work steps. The work step activities may also be services.

What Is SOA?

The term SOA is used interchangeably for three distinct concepts: the architectural concept, the style of the resulting business solutions, and the supporting infrastructure. In this section, we describe each concept.

SERVICE-ORIENTATION. Service orientation is an architectural concept that refers to the loose coupling of a service (an abstract resource with a defined job) and its provider (the physical asset(s) that perform the job tasks). A requestor only knows what the service’s job is and how to request it. The service is the only one that knows its implementation.

Typically, service-orientation is applied to functional assets that correspond to business concepts (Open Customer Account) or system concepts (Authenticate User). However, service-oriented thinking can apply to any domain, including integration, network, platform, or even programming services. If a requester knows what a service offers (job, service levels) and how to use it (contact, security), then it really is not important (to the requester) how that service works, as long as the results meet expectations.

SERVICE-ORIENTED ARCHITECTURE. SOA is an IT architecture strategy for business solution (and infrastructure solution) delivery based on the concept of service-orientation.

SOA STYLES FOR BUSINESS SOLUTIONS. The two primary styles of SOA used in business solution development are composite application development and flow.

Composite Application Development. In composite applications, the user interaction drives a request for one or many services. Most of the service invocations are synchronous in nature. A composite application typically serves one business domain. Composite applications are often delivered in a portal.

Flow. In flow, business process and/or events drive the service invocations. The service invocations are a mix of asynchronous and synchronous; however, the overall flow is usually long running and asynchronous. A flow typically crosscuts business domains and often extends outside of the enterprise.

• Business Process-Driven. In business processdriven architecture, the flow of work, as a series of activities, drives the requisite application and human behavior to complete a business transaction or process. The process is typically long running in nature, involving multiple parties and/or applications within an enterprise or across enterprises.
  
  In business process-driven SOA, a business process may implement as a service, and/or a business process step (activity) may invoke one or more services.



• Event-Driven. In an event-driven architecture, a notable thing happens inside or outside your business, which disseminates immediately to all interested parties (human or automated). The interested parties then take action. The eventdriven action may include the invocation of a service (thus event-driven SOA) or the triggering of a business process or workflow.

Closing the loop on flow, any service may generate an event or be invoked via an automated transaction (business process step, eventdriven activity). We believe this is the true power of SOA, combining services, events, and business process for human and automated (agent-based) interactions.

SOA ENVIRONMENT. Refers to the collective environment that allows services to be defined, developed and used by other services, and to be assembled into solutions by adding process, interaction mechanisms, user interface, and/or rules. In addition to service development and solution assembly, the SOA environment provides runtime and management functions such as service discovery, policy definition and enforcement, quality of service (performance, availability, reliability and load), transaction management, audit, and usage metering.

Why SOA?

Certainly, everyone is talking about SOA, but talk doesn’t justify adoption. In our experience, we find that SOA has both business and IT advantages.

Business advantages consist of the following:

• Consistent Experience. An SOA can provide a consistent experience for customers and partners across channels and lines of business.
• Business Agility. An SOA can add new functionality, expose functionality to new channels, and vary functionality based on context (customer, partner, entry point).
• Mix and Match. An SOA can compose business solutions from a reusable service collection, leveraging internal and external services.
• Optimize Interactions. An SOA can optimize business interactions for customers, partners, and internal constituents through the implementation of business scenarios (process, events, and services) versus traditional applications.

IT advantages include:

• Reduction of Costs. Reuse of services reduces IT development and maintenance time and costs.²
• Leverage Existing IT Investments. Your service providers are existing code (objects, components, legacy modules, and application package APIs) and information assets (databases, files, and documents).
• Transition Strategies. An SOA can provide application and portfolio transition strategies.

References

¹ See http://www.oasis-open.org/news/oasis_news_05_03_05.php.

² Note that the ROI from reuse typically occurs between the second and third use of the service. This note is based on industry metrics that consider the increased design and development time to “get the service right” to be reusable.

Brenda M. Michelson is the Sr. VP and Sr. Consultant for the Patricia Seybold Group.

Read more reports on Web Services and Service-Oriented Architecture by Brenda M. Michelson and others.