A Methodology for Model-Driven Service Engineering Based on IDEF

Chapter II introduced universal service concepts (i.e. concepts that apply to any type of organization and service). In that chapter, we argued that services are so ubiquitous, that it is hard to think of any organization that does not offer services of some sort to internal (i.e., its own departments, divisions, employees) or external consumers (customers, partners). Yet, despite its ubiquity, a service is often hard to pinpoint and describe, even by its own providers.

Standards for Web Services

Chapter II presented the main concepts underlying business services. Ultimately, as this book proposes, business services need to be decomposed into networks of executable Web services. Web services are the primary software technology available today that closely matches the characteristics of business services. To understand the mapping from business to Web services, we need to understand the fundamental characteristics of the latter. This chapter therefore will introduce the main Web services concepts and standards. It does not intend to be a comprehensive description of all standards applicable to Web services, as many of them are still in a state of flux. It focuses instead on the more important and stable standards. All such standards are fully and precisely defined and maintained by the organizations that have defined and endorsed them, such as the World Wide Web Consortium (http://w3c. org), the OASIS organization (http://www.oasis-open.org) and others. We advise readers to visit periodically the Web sites describing the various standards to obtain the up to date versions.

Ontologies for Model-Driven Service Engineering

In Chapter II we discussed the fundamental properties and concepts of a service. Concepts like interface, contract, service provider and service consumer are universal (i.e., they apply to all types of services). However, in as much as they are intuitive and universal, service concepts such as the aforementioned lack widely agreed upon semantics. The term semantics is used by disciplines such as philosophy, mathematics, and computer science to refer to “the meaning of things.” Meaning is usually attributed to a concept via its association with other concepts. In everyday speech, defining, for example, a “car” to be a kind of a “vehicle” is an attempt to attribute meaning to “car” by associating it with another, more abstract concept called “vehicle.” If the recipient of this definition already understands the concept of a vehicle, then he/she can also understand the concept of car via its association with the more abstract/generic concept vehicle.

Service Deployment Execution and Management

This chapter is concerned with concepts, technologies, and standards for deploying, executing, and managing services. In previous chapters, we have argued that the design of the service must strive for a balance between offering to customers what they want and creating potential for developing additional revenue generating services. We have already established that, although not all possible types of services can be delivered to the consumers in an electronic form, information needed for the coordination and mobilization of the core service resources can be digitized and offered as a support service. In Chapter II, we explained that support services which attach to a core business service are information-based in the sense that they help the consumer locate, evaluate, and access the offered service. Effectively, such services add value to the main business service.

An Overview and Summary

This book has introduced a model-driven approach for identifying, designing, deploying, and managing business services in software. The concept of e-service is an extension of conventional business services, made possible thanks to the rapid explosion in popularity of the Internet and the World Wide Web (Rust & Kannan, 2003). The first generation of e-commerce was based largely on retailing commodity goods, such as books and CDs, and used mass media advertising to contact consumers. The premise of first generation e-commerce was that operational efficiencies (i.e., minimizing the need and therefore the expense to keep physical stores) would reduce the costs of selling. Unfortunately, selling commodities has low profit margins due to competition. An alternative is required, that allows companies to built sustainable competitive advantage, based on their capability to deliver more individualized and hence more profitable e-services.

Service Coordination

Chapter III introduced standards for Web service specification, such as WSDL and SOAP. With the use of such standards, Web service designers can model the functionality of a service in terms of inputs and outputs, thus allowing the consumers of the service to understand what to expect (and what not to expect) from the service, before actually using it. As we have said already, a Web service offers some well defined functionality to its consumers, which, however, due to the very essence of the Web service, has a rather focused and narrow scope. The reason is that, in general, we aim to develop Web services that are as much useful as possible for a wide range of consumers. Thus, the Web service becomes a reusable building.block for something more complex such as a business service. It is unlikely that a business level service can be provided by a single Web service. Instead, a complex business service has to be layered on top of several Web services that coordinate.with each other to deliver the business service. The capability for coordination however, is not unique to Web services. Business resources (people, activities, equipment, etc.) must be coordinated to deliver processes (Dayal, Hsu, & Ladin, 2001). Business processes themselves must be coordinated within a single company or even across several companies, in order to deliver higher level business results such as the fulfillment of a supply chain.

A Case Study of Business Service Realization

Having discussed a method for service realization in Chapter VII, the service methodology that was first outlined in the Introduction of this book is now complete. We have covered the following, so far: • Service concepts and fundamentals (Chapter II). • Service identification from business models and modeling, using the IDEF0/ IDEF1X notations (Chapter VII). • Service realization using the MDA transformation of business services to executable Web services (Chapter V). • Environments for service execution and management (Chapter IX). This chapter demonstrates how the above aforementioned concepts and methods can be applied to the analysis design and implementation of real business services. The business domain that we have chosen, accounts.payable/accounts.receivable (A/R-A/P), is pervasive, but by no means trivial. In this chapter, we approach this traditional accounting domain from a fresh, service-oriented perspective, by following the steps of the approach presented in the previous chapters, to show how services can be realized. We finally implement the modeled services using the CLMS service engineering platform that was first introduced in Chapter IX.

A Platform for Model-Driven Service Engineering

This chapter introduces a service.engineering.platform (CLMS) that caters for all the phases of the service engineering life cycle. Although complete coverage of the service life cycle is important, currently, few software environments and platforms manage it, with the majority of such environments dealing with just service execution (delivery). It is nevertheless important to have a single environment/platform that handles the whole service life cycle with seamless transition between phases (CBDI Forum, 2005). To deal with these requirements, the CLMS platform adopts a model-driven approach (see Chapter VI). More specifically, the platform seamlessly links business service specification models to realizable services and manages the delivery of the latter in an environment that monitors services execution. Moreover, this approach ensures that alternative service deployment techniques (e.g., proactive as well as reactive service delivery systems) and service execution environments can be accommodated. This is of particular importance today, with service engineering still evolving and with new service paradigms and competing technologies appearing all the time.

Model-Driven Service Engineering

This chapter argues that modeling is at the core of every service engineering method. Modeling not only allows us to understand business services but, what is equally important, to transform them into software-realized services. In general, models provide abstractions of a physical system that allow engineers to reason about that system while ignoring irrelevant details and focusing on relevant ones (Brown, 2004). All forms of engineering and science rely on models to understand complex, real-world systems. Models are used to predict system properties, reason about how changes in some parts of it will affect the rest of a system, and communicate key system characteristics to various stakeholders. The models may be developed as a mock-up or blueprint prior to implementing the physical system, or they may be derived from an existing system or a system in development, as an aid to understanding its behavior.

Service Concepts

Services are something we routinely experience in everyday life as consumers. Also, depending on our profession, we may deal with services as providers. School teachers, hairdressers, and airline pilots are three examples of professions that offer services to consumers. The typical domestic dwelling is connected to several services such as services for drainage, electricity, and water supply. Architects and house builders take into account the local availability of external services and arrange the house’s drainage, heating and plumbing accordingly. Gas heating, for example, requires the availability of a gas supply service. If such service is not available, the house’s heating system must be based on an alternative fuel such as oil. This will, in turn, impact other decisions about the design of the house, such as, for example, the provision of space for an oil storage tank.