A UML-Profile for Service-Oriented Architectures

Introduction

This document defines a UML-profile as an extension for modelling service-oriented architectures. It adapts the UML metamodel as defined in the specification document [OMG03] by stereotypes for service-oriented architectures.

Overview Service-Oriented Architectures

Service-oriented architectures involve three different kinds of actors: service providers, service requesters, and discovery agencies. The service provider exposes some software functionality as a service over a network to its clients. In order to allow requesters to access this service, the provider has to publish a service description.

Since service provider and service requester usually do not know each other in advance, the service descriptions are published via specialized discovery agencies. They categorize the service descriptions and deliver them in response to queries issued by service requesters. As soon as the service requester has retrieved a service description meeting its service requirements, it can use it to interact with the service.

Service-oriented architectures are typically highly dynamic and flexible: Components and services are only loosely coupled and communicate according to standardized protocols; interface specifications are exchanged at run-time and, thus, clients can replace services at run-time. This might be advantageous if a new service provides a better alternative to the former one concerning functionality or quality of service. Or, it might become necessary for self-healing purposes, e.g., if a service is not reachable any longer because of network problems.

Stereotype Definitions

Stereotypes define how existing metaclasses are extended and enable the use of platform specific elements and notations in the extended models. The following figure defines the stereotypes of the SOA profile including the metaclasses they extend.

Service-Oriented Architectures

In software engineering, service-oriented architecture (SOA) is an architectural style that supports service orientation. By consequence, it is as well applied in the field of software design where services are provided to the other components by application components, through a communication protocol over a network. A service is a discrete unit of functionality that can be accessed remotely and acted upon and updated independently, such as retrieving a credit card statement online. SOA is also intended to be independent of vendors, products and technologies.

Service orientation is a way of thinking in terms of services and service-based development and the outcomes of services.

A service has four properties according to one of many definitions of SOA:

1. It logically represents a repeatable business activity with a specified outcome.
2. It is self-contained.
3. It is a black box for its consumers, meaning the consumer does not have to be aware of the service’s inner workings.
4. It may be composed of other services.

Different services can be used in conjunction as a service mesh to provide the functionality of a large software application, a principle SOA shares with modular programming. Service-oriented architecture integrates distributed, separately maintained and deployed software components. It is enabled by technologies and standards that facilitate components’ communication and cooperation over a network, especially over an IP network.

SOA is related to the idea of an application programming interface (API), an interface or communication protocol between different parts of a computer program intended to simplify the implementation and maintenance of software. An API can be thought of as the service, and the SOA the architecture that allows the service to operate.