As previously argued, components and services (component-based software engi-neering and service-oriented computing) are being viewed as potential solutions in conquering the complexity of developing reliable computing systems, including dis-tributed systems. Component-based designs are centred around individual compo-nents exposing their interfaces (and associated meta-data) via which they interact. A componentAcan only request a service from componentBviaB’s interface, while Bresponds via its own interface.
In its broadest interpretation, a service-oriented architecure is an architectural style that has services as first class citizens. It refers to the design of a system, rather than its implementation [19]. The design consists of a set of components linked together via their interfaces. Sometimes, incompatibilities may exist between the components’ interfaces, and connectors are needed to connect these compo-nents [8,19]. The linking up process is done according to some specific rules. Some-times, a syntactic link-up is sufficient, while at other Some-times, semantic information is needed before the linking-up process is performed. This linking-up process is what is generally known ascomposition. A service-oriented architecture emphasises the development of a system in a modular fashion, i.e., a componentA implements a serviceSA, and can be composed with a componentBthat implements a serviceSB to provide an overall serviceSAB. In other words, in service-oriented computing, an application is built as a composition of components and services.
To enable the composition process, a component needs to export (or publish) a description of the services it provides. The services that it exports can be viewed as itsexport interface. Further, a component needs to also publish itsimport interface, i.e., the set of services that it requires from other components. Other information that a component needs to provide is any resource requirement or other constraints that can prevent it from providing its exported services. All of this information is needed for a correct matching between offered and provided services. For example, consider a component that provides the following two services. (i) multiplication, and (ii) division. The component’s export interface is: (i) multiply(a:int, b:int), and (ii) div(a:int, b:int). However, for the div service, the component has to mention that the parameter b needs to be non-zero (a constraint that needs to be satisfied whenever the service is used). If the constraints defined by the component are sat-isfied, then the component will provide the required service, i.e., if the service is used appropriately, then the component will provide correctness guarantees as to the service it is providing. This resembles thedesign-by-contractparadigm [13, 14], where the client request satisfies the preconditions specified for the service and, in turn, the component guarantees the correctness condition, i.e., the service’s output will satisfy a specified postcondition.
In general, these components (and services) need to be discovered, i.e., when a service is needed, the client requesting the service has to determine a potential service provider. In domain areas where automation is required, such as in service-oriented computing, these services are published at a service registry, residing at a service broker. Figure 6.1 shows the process of service discovery and binding in a distributed system. The registry is located on a dedicated server (service broker), which can be possibly replicated, to handle crashes. The client requests a service from the service broker, which in turn returns the identity of a known provider of the service [3]. The client then agrees on the semantics with the provider. The client then binds itself to the provider, and uses the service. In other areas, where automation is not important, these services still need to be published and discovered. However, there are no dedicated service registry available. On the other hand, these services are possibly kept in a centralised service library. However, the architecture is similar to that of Figure 6.1. In an adaptive distributed system that supports web-based applications, these services can be discovered at run-time, whilst in single process-based applications, these services can be discovered at design and/or compile-time.
Service registry
Customer/client Service provider
Fig. 6.1 Service interaction in a service-oriented distributed system
There are five basic steps required in a service-oriented architecture [3]. These are:
• publishing,
• discovery,
• composition,
• binding, and
• execution.
Publishing.
Service providers offer services and, in order for these to be used, their descrip-tions need to be provided. All services descripdescrip-tions are kept in a service registry, whereas the actual services reside on different servers. All services have to be self-descriptive. The service description needs to be complete, i.e., the description needs to include the service being provided itself, its semantics, the constraints, and the re-sources needed for successful execution. Very often, this description will be done in a given language, e.g., logic, so that it can be easily understood. For example, web services are described using WSDL documents [18]. However, for web services, WSDL cannot be adequately used to describe non-functional properties.
Discovery.
When a client needs a desired service to perform a given task, it will have to discover the required service. To do so, the client has to have a clear understanding of the service that is required in the form of a description as offered by service providers.
Once an offered service has been identified that matches the required service, we have a successful discovery.
Composition.
It may be the case when there is no successful discovery of a service. In this in-stance, smaller services may be composed together to provide a more complex ser-vice, which hopefully will match the service that is required. When doing so, both functional and non-functional properties need to be taken into consideration. If there is a mismatch, connectors may be used to link the two services. Two techniques are usually used, namely, service choreography [3] and service orchestration [3].
Both techniques yield the same result, however the approaches are different.
Binding.
Once an appropriate service has been discovered that offers the required functional-ity, the client binds itself to the service for execution. At this point, side aspects of the service can be set, such as security, authentication and so on. In service-oriented architectures such as web services, the binding takes place late in the process, al-lowing for dynamic adaptation when needed.
Execution.
Once the service is bound to the client, the service (single or composed) can be executed. The input parameters to the service are transmitted to the service provider which, upon receipt, executes the service. At the end of the execution, the result is returned to the client.
6.2.1 Dependability Issues in Service-Oriented Architectures
However, several problems can occur in a service-oriented architecture. For exam-ple, a given service may be requested with the wrong number of parameters during the execution phase. Another problem can be that the service is no longer available during the binding phase. Overall, this indicates that faults can occur at every step in the system. Before the development of a dependable system, it is of utmost im-portance to be able to predict the nature of the faults [17] that can affect the system.
Once the possible faults are identified, remedial actions can be identified that will correct any problem in the system. Further, depending of the type of application and the service requested (whether it is stateful or stateless), the type of dependability mechanisms used will be different.
Overall, dependability can be addressed in four main ways, namely:
• fault avoidance,
• fault removal,
• fault forecasting, and
• fault tolerance.
Fault avoidance approaches are those that minimise the chance of faults occurring in the system. Fault removal approaches, on the other hand, look at removing faults that occur in the system. Fault forecasting approaches try to predict the number and impact of any residual faults on the system. Lastly, fault tolerance approaches work on the basis that faults are inevitable, and work by detecting and correcting the faults. We will look at each approach in more detail in Section 4.
The chapter is structured as follows. In Section 2, we provide an overview of the main steps involved in the setting up of a service-oriented architecture. In Section 3, we develop the system model, as well as the fault model. The fault model is devel-oped by closely looking at the main steps in the service-oriented architecture, and looking at possible failure modes. In Section 4, we analyse the different ways of imparting dependability to a system, and then provide an overview of several pos-sible approaches in each category. In Section 5, we discuss dependability metrics, and dependability evaluation. We explain the various concepts in two case studies developed in Section 6, and summarise and conclude the chapter in Section 7.