3.2.1 Overview
From an abstract point of view, it is the aim of the ARIS extension to support business experts in creating a business-oriented service description. Such a service description helps business experts to evaluate the capabilities provided by a service and to decide if a service should be used. A comprehensive service description does not solely detail the capabilities of a service, but also who implements the service, who is responsible for the service description, and how the service can be used. The main use cases are (partly based on [OEtH02]):
• Service discovery: A potential user defines his need and all existing and available services having the necessary capabilities are suggested.
• Service composition: Several services are combined to provide a more complex capability.
• Service substitution: If a currently used service becomes unavailable, the service is replaced with another service with similar capabilities.
• Service governance and management: Creating and maintaining a service architec- ture without redundancies and with clearly defined responsibilities.
Those use cases are further described in the following subsections. In reality, those use cases are interrelated. For example, service discovery requires up-to-date service descriptions, which is the task of service governance. Also, service substitution might depend on service discovery so that a replacement can be identified quickly.
3.2.2 Service Discovery
The service description defines which capabilities are provided by a service. Therefore, the service description is a central information object for potential service consumers trying to identify a service for their needs. By comparing the offered capabilities with the own needs, a service consumer decides whether the usage of the service is possible and beneficial.
This comparison of need and capability is similar to general market mechanisms relying on supply and demand. Services are suppliers of capabilities and service consumers are demanders of needs. The evaluation of a service is not limited to the capabilities, but it must also include the conditions under which the capabilities are provided. For example, the service usage creates costs, which must be covered by the service consumer. If the service consumer (e. g. a company department) does not pay them directly, it will pay them indirectly by creating enough business value to cover the costs of an IT department. Besides financial conditions, there might be other conditions like the temporal or spatial availability of the service.
It is also possible that the service itself defines conditions to be met by the service consumer. For example, a service might define that all communication must be encrypted. A service consumer issuing a non-encrypted request will be rejected in such a scenario.
The service description is an offer by the service provider. The offer is binding meaning that the service must provide the advertised capabilities if requested. The OASIS SOA Reference Model [MLM+06] characterises this as “willingness”.
Besides providing the necessary ARIS extension to describe a service so that it can be discovered, this thesis also contributes a service discovery application supporting a service consumer in discovering a matching service for a function in a business process. Here, service discovery is done during design-time while the business expert is creating a business process model. This application is described in chapter 4. The application semantic business process management uses a formalised service description so that the service description is machine processable. A prototype is provided demonstrating service discovery during process execution. This application is described in chapter7.
3.2.3 Service Composition
It is common to not only invoke a single service, but instead to use several services to consume a more complex capability. Such a service composition can be implemented
differently. For example, based on a business process an executable service orchestra- tion is created. This service orchestration itself is provided as a service. For a service consumer, it does not make a difference if a single service or a service composition is invoked. Another possibility for service composition is the combination of services in a software architecture. Such an approach is based on previous work done in the area of component-oriented software engineering like [Szy97,HS00].
Having standardised interfaces is a fundamental requirement of service composition. In addition, the interfaces must be documented in the service description. Only if services provide their functionality through standardised interfaces, which can be integrated easily, service composition can be done. However, having standardised interfaces does not mean services must be implemented with the same technology. The service composition is based on the service interface and the service description, but the technology behind is not visible.
This thesis extends the modelling language ARIS to cover all aspects necessary for service composition. In addition, an exemplarily application is developed demonstrating how to turn a business process modelled with the EPC notation into a service orchestration based on BPEL. The belonging application generates a service interface for the BPEL process as well, so that it can be consumed like any other service. This application is described in chapter5.
3.2.4 Service Substitution
The service substitution use case adds details to a service description so that a service with similar capabilities can replace a currently used one. A substitution is only possible if the substitute has no incompatible capabilities or conditions. For example, if a currently used service supports encrypted as well as non-encrypted invocation, a substitute can only constrain the communication to encrypted if the service consumer also supports an encrypted request.
Service substitution is important in failover scenarios. Here, a service becomes unavail- able, e. g. because of hardware failure. The service must be replaced immediately by a substitute to ensure the operation of the business process or company. Therefore, ser- vice substitution requires that services with similar or equal capabilities are described in a similar way so that a substitute can be found easily. Also, the ability to explicitly define a substitute might be needed in some cases.
3.2.5 Service Governance and Management
Services and their development must be planned, maintained, and continuously improved. The belonging activities are summarised as service governance or service management. Activities can be grouped in operational, tactical, and strategical tasks.
Operational activities focus on a short timeframe. They ensure the daily availability of deployed services. They also monitor and control the current execution of services. In case of breakdown, it is an operational task to provide a substitute if the failed service is criti- cal for the operation of the company. Tactical tasks are focused on a midterm timeframe.
static
dynamic static dynamic
External
Internal
Figure 3.3: Views and aspects of service description
Here, the deployment or replacement of services is planned and implemented. Strategical tasks have a significant longer timeframe. For example, they focus on the development of the overall service architecture like defining the necessary service categories to group services. They also establish the necessary means to enable service usage like train- ing potential service consumers in evaluating service descriptions. A service description must enable service governance and management for operational, tactical, and strategical tasks.
The following section introduces some basic considerations about a service description as a systematic. It details which views, aspects, and levels must be represented by a service description.