“My” SOA definitions–What I mean when I say “service-*”

I spend a lot of time in the service-oriented world. Sometimes as a practitioner, other times as an advisor, and other times still as an interested observer. Over the course of time, I’ve settled on a set of definitions for some commonly (but inconsistently) used terms. For the full deal, in a formal manner, see my PSGroup Service-Oriented World Cheat Sheet, which is being published in installments on Nextslm.org . (No guarantee how long the piece will run).

For those interested in a quick take, I’m posting the terms here, because it will make my subsequent postings (of which I hope there are many) more understandable.

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.

Service Types. 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.

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.

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 process-driven 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 event-driven action may include the invocation of a service (thus event-driven SOA) or the triggering of a business process or workflow.

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.