Establishing Service Management in SOA

Introduction

Moving to service-oriented architecture (SOA) introduces a completely new structure of enterprise IT (Krafzig et al., 2004). For each application in the enterprise reusable services must be defined encapsulating the implementation platforms and technologies used. Subsequently, these services can be orchestrated by process languages as BPEL (OASIS, 2007) or BPMN (OMG, 2011) to compose complex and application spanning business processes that realize the different business strategies (Figure 1).

Figure 1.

Portfolio of services in a service-oriented architecture

Introducing SOA causes a paradigm shift: In SOA, reusable services are the crucial components of IT infrastructure. A service portfolio that is under continual development serves as the integration platform for enterprise-wide business processes. Managing the service portfolio is an essential task during IT operations. From a general perspective, moving to SOA let an enterprise substitute application and technology management by service management.

As one major goal SOA fosters the reuse of already existing services. Particularly, service management has to support all aspects of service-reuse. Especially, it has to deal with the following issues:

• •

  Finding a service: Software developers and business process designers need decent support to decide whether the service portfolio contains an appropriate re-usable service. Otherwise, a new enterprise-wide usable service must be commissioned.

• •

  Selecting a service version: If a suitable service has been found, the appropriate version of the service must be selected. Services will usually change over time so that different versions will co-exist. Version control regarding dependencies and incompatibilities between different service versions is indispensable for managing huge service portfolios. Therefore, change management is a significant aspect of service management.

• •

  Providing service access: After the adequate version of a service has been chosen, the software developer must be provided with all information necessary to invoke the service, e.g., service signature, transport protocols and service endpoints.

• •

  To accomplish these objectives, service management has to overcome different challenges.

• •

  Service semantics: The prerequisite of service-reuse is a complete understanding of the services provided. Firstly, semantics of each service must be precisely defined so that every service requester can understand all the effects and impacts of a service invocation. Furthermore, all non-functional aspects of a service such as quality of service (QoS) and service level agreements (SLAs) must be specified by formal contracts preventing differing interpretations. For instance, the security properties or performance characteristics of a service must be known in advance.

• •

  Heterogeneous technologies: Big enterprises, especially in the financial sector are based on a heterogeneous IT infrastructure, including legacy systems, e.g., CICS transaction monitors or packaged systems like SAP. In a service-oriented architecture the services of the portfolio are implemented in different technologies running on different platforms. In real-world scenarios, a service-oriented architecture cannot only rely on Web services but must integrate legacy services based on proprietary protocols and technologies.

• •

  Tool support: Big enterprises might have to administer several hundreds of services with a few thousands of operations. Due to the huge number of services, an appropriate tool support is indispensable. A service registry-repository must provide all necessary artifacts to find, understand and manage the services.