To begin, a service can be defined as follows:
Definition 1.7 (Service, defined by MacKenzie et al. [78]). “A service is a mechanism to
enable access to one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description.” [78]
The service-oriented architecture is based on three parts: (1) a set of tiers providing a set of services, a.k.a., service providers, and (2) a set of tiers asking for a set of services, a.k.a., service consumers, and (3) a service registry. Services are formalized as contracts (a.k.a.,
interfaces) between service consumers and service providers. This architecture decouples
the consumer of a service from its provider by introducing a service registry in between, as shown in Figure 1.6.
In a service-oriented architecture, every service consumer registers its dependency on a set of services it needs to invoke, as illustrated in Figure 1.6a. When a service provider starts providing a service it implements, it registers the service in the service registry, as shown in Figure 1.6b. The service registry then looks for service consumers that depend on the provided service, and when such service consumers are found, they are notified of the availability of the service, and they are provided with bindings that enable invoking the service.
When a service provider stops providing a service S, it notifies the service registry, which
starts by looking for other service providers that implement the same service S. If such
Service Registry Service Consumer 1 Service Consumer 2 2 1 2 1
(a) 1 Service consumers register themselves in
the service registry. 2 Service consumers
then wait to be notified for newly available service providers. Service Registry Service Consumer 1 Service Consumer 2 Service Provider 1 3 3 2 2 1
(b) 1 Service provider register itsef in the service
registry. 2 Service consumers are notified
for the newly available service provider. 3
Service consumers invoke the service offered by the service provider.
Service Registry Service Consumer 1 Service Consumer 2 Service Provider 1 3 3 2 2 1
(c) 1 Service provider unregister itsef from the service registry. 2 Service consumers are notified for the unavailability of the service provider. 3 Service consumers detach themselves from the service provider.
Figure 1.6: Scenario of service discovery and service extinction in the Service-Oriented Architecture.
that they need to update their references to another service provider implementing S. If no
other service providers provide S, then the service registry notifies the consumers of Sthat
they need to reset their bindings to Sand wait for another service provider. This procedure
is briefly illustrated in Figure 1.6c.
5.1.1. The Service Registry
The service registry is basically an interactive service directory. Each service provider registers itself in the service registry to expose its provided services (see Figure 1.6b). Each service consumer asks the registry for services fulfilling certain functional and non-functional criteria. If the service registry finds a corresponding service, then it returns a service binding to allow the service consumer to communicate with the service provider and invoke the operations defined by the service.
When configured, the service registry notifies service consumers when new services are registered and available for use. Services can appear and disappear at any time in the service registry (see Figure 1.6c) unless otherwise specified via, for example, Quality of Service contracts.
5.1.2. The Whiteboard Design Pattern
Service providers often need to notify service consumer about events happening, in which case they behave as event sources. Event sources often implement the “Observer” [114, 48] design pattern in order to notify about events, by allowing listeners to register their event
handlers which will be called when the events occur. For this, an event source would typically
implement a private registry to store references to event handlers that will be called later. But, as the service-oriented platform already provides a service registry, that registry can be reused by event sources in order to simplify event notification. Kriens and Hargrave [72] call this reuse the “Whiteboard” pattern, in which event listeners do not need to track event sources and register themselves within the event sources. Instead, each event listener registers its event handling interface as a service in the service registry. When an event source needs to send an event notification, it invokes the event handling interfaces registered by all event listeners in the service registry.
5.1.3. The Publish-Subscribe Design Pattern
The service registry abstracts and simplifies service discovery. The whiteboard pattern also simplifies the implementation of event sources and event handlers by reusing the service registry. However, in order for an event source to invoke an event handler, the event handler must implement a specific interface provided, or agreed upon, by the event source. This coupling is what the publish-subscribe pattern aims to decouple, by defining a messaging protocol that is more flexible than coupled interfaces. This implies that an event source, called a publisher, does not need to be aware of the presence of even handlers, called subscribers, and does not impose when and how these subscribers receive event notifications.
In the publish-subscribe pattern, messages are characterized by topics, a.k.a., classes3. The publish-subscribe pattern requires a message-oriented middleware that receives event notifications from publishers and notifies subscribers. A subscriber registers itself with a set of topics. When a publisher wants to notify about an event, it sends a message associated with a specific topic into the message-oriented middleware, which, in turn, notifies subscribers for that particular topic about the event. Notifications can be delivered to subscribers in various ways, and they can be delivered immediately or deferred.
The publish-subscribe design pattern in illustrated in Figure 1.7, where, for instance, Pub1 sends events tagged with “Lighting” and “Energy” topics to the message-oriented middleware, which, in turn, routes lighting-tagged events to Sub1 and energy-tagged events to both Sub2 and Sub3.