Architects develop models to show different aspects of the systems that are to be created or modified in accordance with their architectures. These models are constructed of building blocks, which are abstractions of the system components.

There are many different kinds of architecture and solution building block. You can abstract as a building block any part of a system that you want to think about. This section describes the building blocks that are commonly used for SOA. Some of them are also used for other styles of IT architecture.

They are described at a high level of abstraction, for example service and program. An architectural model would typically show less abstract building blocks, for example payment service or messaging program, that fall into categories defined by the building blocks described here.

Services

Service is of course the most important SOA concept.

• A service is a repeatable activity that has a specified outcome.

A service has a provider, can have one or more consumers, and produces effects that are of value to its consumers.

Providers and consumers see services from different points of view. To a consumer, a service is a black box. Two services are the same to a consumer if, given the same inputs, they produce the same effects. To a provider, a service is a means of exposing capabilities. Two services are different to a provider if they have different mechanisms for doing this, even though they produce the same effects. Architects talk to providers and to consumers, and must be able to see services from both points of view.

Consumers use services in their business processes. These business processes are mechanisms by which the consumers may themselves provide larger services. Such services, whether provided to consumers outside the enterprise or within it, are called business services.

From a provider's perspective, a service can be performed by people, by technology, or a combination of people using technology. Services that are performed by software programs are the key components of a service-oriented architecture. They are called software services. In any particular service-oriented architecture, there is often a set of software services that are identified for processes such as discovery and composition. They make up the architecture’s service portfolio, and they are called portfolio services.

Business Processes

• A business process of an enterprise is an activity that is related to the enterprise's business mission and that is conducted in a defined, repeatable way.

People often take part in business processes. It is sometimes tempting to think of a business process as “a process in which people take part”, but it is the relation to the business mission, rather than who or what takes part in it, that characterizes a business process.

Modeling business processes is an important element of enterprise architecture development. The Business Process Modeling Notation (BPMN) defined by The Object Management Group (OMG) is a formal notation for describing business processes that is becoming increasingly accepted.

When business processes are modeled, the people that take part in them are referred to as human actors.

Software programs can take part in business processes also. The software services of an SOA exist to support the enterprise's business processes. This relation can and should be symbiotic. Analysis of the business processes is the main way of identifying software services. On the other hand, the existence of the right software services enables new business processes to be developed, to meet new business opportunities.

Human Actors

An actor is someone or something that does something. Actors of various kinds can be abstracted as building blocks.

• A human actor is a person that does something in relation to an architected system.

Human actors appear when business processes are modeled, and also in models showing other aspects of the system, such as management and security.

A model generally shows an abstraction of a person, rather than a real person: “president”, rather than “George Washington”. The word “role” is sometimes used, rather than “actor”, because of this.

Other kinds of actor may be encountered in IT architecture. A technology actor is an actor that is a machine or other piece of technology. It could be hardware, software, or both. A program is one particular kind of technology actor; a data store is another. An organization actor is a system whose components can be people, technology items, and other things, and that is regarded as a single actor.

Events

Events to which business processes or services respond can be building blocks too.

• An event is something that happens.

An event is not necessarily associated with any particular business process or service.

Like human actors, events appear when business processes are modeled, and also in models showing other aspects of the system, such as management and security.

Service Descriptions, Contracts, and Policies

An important feature of services in SOA is that they have descriptions that state clearly what they do and how to interact with them.

A description is an information item that is represented in words, possibly accompanied by supporting material such as graphics.

• A service description is a description of a service.

A service description can be represented in informal text but, for many purposes, it is better to use a structured description language. The Web Services Description Language (WSDL) defined by The World-Wide Web Consortium (W3C) is widely used for this purpose.

A contract is an agreement between two or more actors - the parties to the contract. The term is most commonly used for a written agreement, or one that is enforceable at law, but it can be applied more widely.

• A service contract is a contract between the provider of a service and one or more of its consumers.

A service contract may be an implicit agreement that the service will conform to its description, or it may be a more formal agreement, which could be recorded in a signed internal enterprise document, or be a legal contract executed between enterprises.

A service contract covers functionality (what effects the service produces), and often also covers service quality. Service quality typically includes the service's performance and security characteristics.

A policy is a course of action that a person or organization intends to follow, or intends that another actor should follow.

• A service policy is a course of action that a service provider intends to follow in providing a service, or intends that the service consumers should follow.

For example, an enterprise might have a policy that certain services are provided only to internal consumers, or a web service provider might have an “acceptable use policy” that states what consumers of its service may and may not do.

Service description, contract and policy building blocks appear in models that show how services are consumed. In SOA, this is a very important aspect of system implementation and operation.

Service Compositions

A composition is a collection of things that are put together to form a single thing.

Services can be composed of other services. Business processes can be composed of services and other business processes.

• A service composition is a collection of services that are put together to form a single service.

Service composition is a provider's concept. It relates, not to what a service does, but to how it is performed.

Service compositions appear in models that show how business processes are supported by services. They may also appear where functionality that is not related to the business mission is implemented using a service-oriented approach, in a model of a service-oriented infrastructure, for example.

Programs

• A software program is a set of instructions for a computer to perform a specific task.

Software programs relevant to SOA include programs that contain instructions to perform services. When such a program is executing, we generally say that it (rather than the computer that carries out its instructions) performs the service.

A software service is different from the program that performs it, just as services performed by people are different from those people.

A program that performs a software service should also be distinguished from the service provider. The service provider is the person or organization that takes responsibility for the service, and enters into contracts with its consumers.

Other programs relevant to SOA include programs that provide infrastructure for the services, and application programs.

Program building blocks appear in models that show how services are performed, models that show how services are integrated with each other and with other system components, models that show how the architected system processes data, and in models showing other system aspects, such as performance, management, security, and governance.

Information Items, Data Items, and Data Stores

IT architecture is of course very much concerned with information, and building blocks related to information are used for SOA, as for other architectural styles.

The concept of information is a very general one.

• An information item is a thing that is known about some other thing.

An information item may be simple or may be complex, composed of simpler information items.

Information items appear in models of business processes.

Data can be defined as “a re-interpretable representation of information in a formalised manner suitable for communication, interpretation or processing” (see ISO/IEC 2382-1:1993 Information Technology - Vocabulary - Part 1: Fundamental Terms.)

• A data item is a representation of an information item.
• A data store is a technology actor that stores data items.

Data items and data stores are important architectural building blocks. Like programs, they appear in models that show how services are performed, models that show how services are integrated with each other and with other system components, models that show how the architected system processes data, and in models showing other system aspects, such as performance, management, security, and governance.