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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
In\u00a0software engineering<\/a>,\u00a0service-oriented architecture<\/b>\u00a0(SOA<\/b>) is an architectural style that supports service orientation.<\/sup>\u00a0By consequence, it is as well applied in the field of\u00a0software design<\/a>\u00a0where services are provided to the other components by\u00a0application components<\/a>, through a\u00a0communication protocol<\/a>\u00a0over 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.<\/sup><\/p>\n Service orientation is a way of thinking in terms of services and service-based development and the outcomes of services.<\/sup><\/p>\n A service has four properties according to one of many definitions of SOA:<\/sup><\/p>\n Different services can be used in conjunction as a\u00a0service mesh<\/a>\u00a0to provide the functionality of a large\u00a0software application<\/a>,<\/sup>\u00a0a principle SOA shares with\u00a0modular programming<\/a>. 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.<\/p>\n\n