Services provide business functionalities, such as an application for a business travel, an application for a loan, etc. This differs considerably from technology-oriented functionalities, such as retrieving or updating a table in a database. Services in SOA must provide business value, hide implementation details, and be autonomous. Service consumers are software entities, which call the service and use its functionality.

Service consumers access the service through its interface. The interface of a service defines a set of public operation signatures. The interface is a contract between the service provider and a service consumer. The interface is separated from the implementation, is self-describing, and platform independent. Interface description provides a basis for the implementation of the service by the service provider and a basis for the implementation of the service consumers. Each interface defines a set of operations. In order to define business services, we need to focus on correct granulation of operations. SOA services are best modeled with coarse granulation.

Operations are defined as a set of messages. Messages specify the data to be exchanged and describe it in a platform‑ and language‑independent way using schemas. Services exchange only data, which differs considerably from object‑oriented and component approaches, where behavior (implementation code) can also be exchanged. Operations should be idempotent (an operation is idempotent if repeated invocations have the same effect as one invocation). WSDL is a service description language that meets SOA criteria.

Service consumers access the services through the service bus. This can be either a transport protocol, such as SOAP, or an ESB. Service consumers can use synchronous or asynchronous communication modes to invoke operations of services. In synchronous mode, a service operation returns a response to the service consumer after the processing is complete. The service consumer has to wait for the completion. Usually we use synchronous mode with operations complete processing in a short time. In asynchronous mode a service operation does not return a response to the consumer, although it may return an acknowledgement so that the consumer knows that the operation has been invoked successfully. If a response is needed, usually a callback from the service to the consumer is used. In such a scenario, correlation between messages is needed.

Through the self-describing interfaces, coarse granulation, exchange of data structures, and support for synchronous and asynchronous communication modes, loose coupling of services is achieved. Loosely coupled services are services that expose only the necessary dependencies and reduce all kinds of artificial dependencies. This is particularly important when services are subject to frequent changes. Minimal dependencies assure that there will be a minimal amount of changes required to other services when one service is modified. Such an approach improves robustness, makes systems more resilient to changes, and promotes reuse of services.

To simplify and automate searching for the appropriate service, services are maintained in service registries, which act as directory listings. Service providers publish services in registries; service consumers look up the services in the registries. Lookup can be done by name, service functionality, or business process properties. UDDI is an example of a service registry.

Services usually have associated quality‑of‑service attributes. Such attributes include security, reliable messaging, transaction, correlation, management, policy, and other requirements. The infrastructure must provide support for these attributes. Quality‑of‑service attributes are often important in large information systems. In web services, quality‑of‑service attributes are covered by WS-* specifications, such as WS-Security, WS-Addressing, WS-Coordination, etc. Quality of service is also provided by the ESB.

The final, and probably the most important, SOA concept is composition of services into business processes. Services are composed in a particular order and follow a set of rules to provide support for business processes. Composition of services allows us to provide support for business processes in a flexible and relatively easy way. It also enables us to modify business processes quickly and therefore provide support to changed requirements faster and with less effort. For composition, we will use a dedicated language, BPEL, and an engine on which business process definitions will be executed. Only when we reach the level of service composition can we realize all the benefits of SOA.

The figure bellow shows the architectural view of SOA and positions the above-mentioned concepts:

Let us now fill the technologies into the above picture to understand the connection between SOA concepts and technologies that provide means for their realization. Notice that the mere use of a specific technology does not guarantee that we build SOA‑compliant architecture. For example, with web services we can develop business services (for example, a loan application), but we can also develop technology‑focused services (updating the database, for example). So, it is essential that technologies are used according to the guidelines provided by SOA concepts:

For this picture, we can have two views. The bottom-up view of SOA sees different applications exposing their functionalities through business services. This enables access to functionalities (services) of different existing and newly developed applications in a standard way. Access to services is important because a typical enterprise has a large number of applications, which have to be integrated.

Developing business services, either through reuse of existing applications or by new development, is not sufficient. We also need to compose services into business processes—this is the second, the top-down or process-oriented approach to SOA. We would obviously prefer a relatively simple and straightforward way to compose and modify business processes. This is where the BPEL becomes important. In the next section we will discuss service composition and BPEL.