Enterprise Service Computing From Concept to Deployment_5 doc

132 van Sinderen, Almeida, Pires, & Quartel Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permis- sion of Idea Group Inc. is prohibited. Chapter VI Designing Enterprise Applications Using Model-Driven Service-Oriented Architectures Marten van Sinderen, University of Twente, The Netherlands João Paulo Andrade Almeida, Telematica Instituut, The Netherlands Luís Ferreira Pires, University of Twente, The Netherlands Dick Quartel, University of Twente, The Netherlands Abstract This chapter aims at characterizing the concepts that underlie a model-driven service-oriented approach to the design of enterprise applications. Enterprise ap- plications are subject to continuous change and adaptation since they are meant to support the dynamic arrangement of the business processes of an enterprise. Service-oriented computing (SOC) promises to deliver the methods and technolo- gies to facilitate the development and maintenance of enterprise applications. The model-driven architecture (MDA), fostered by the Object Management Group (OMG), is increasingly gaining support as an approach to manage system and software complexity in distributed-application design. Service-oriented computing and the MDA have some common goals; namely, they both strive to facilitate the Designing Enterprise Applications 133 Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited. development and maintenance of distributed enterprise applications, although they achieve these goals in different ways. This chapter discusses a combination of these approaches and discusses the benets of this combination. Introduction Enterprise applications are subject to continuous change and adaptation since they are meant to support the dynamic arrangement of the business processes of an en- terprise. For example, an enterprise may decide to outsource a business process for efciency reasons, or different processes may be integrated to provide a new product. Therefore, it is necessary to devise methods and technologies that can cope with this dynamic characteristic of enterprise applications in a cost-effective manner. Service-oriented computing (SOC) promises to deliver the methods and technologies to facilitate the development and maintenance of enterprise applications (Papazo- glou & Georgakopoulos, 2003). This should promote the introduction of richer and more advanced applications, thereby offering new business opportunities. Other foreseen benets are the shortening of application-development time by reusing available applications, and the creation of a service market, where enterprises make it their business to offer generic and reusable services that can be used as applica- tion building blocks. The service-oriented paradigm is in essence characterized by the explicit identication and description of the externally observable behavior, or service, of an application. Applications can then be linked based on the description of their externally observable behavior. According to this paradigm, developers in principle do not need to have any knowledge about the internal functioning and the technology-dependent implementation of the applications being linked. Often, the term service-oriented architecture (SOA) is used to refer to the architectural principles that underlie the communication of applications through their services (Erl, 2005). The model-driven architecture (MDA), fostered by the Object Management Group (OMG), is increasingly gaining support as an approach to manage system and software complexity in distributed-application design. MDA denes a set of basic concepts such as model, metamodel, and transformation, and proposes a classication of models that offer different abstractions (OMG, 2003). Model-driven engineering (MDE) builds on this foundation to introduce the notion of software-development process by organizing models in the modeling space (Kent, 2002). MDE focuses rst on the functionality and behavior of a distributed application, which results in platform-independent models (PIMs) of the application that abstract from the technologies and platforms used to implement the application. Subsequent steps lead to a mapping from PIMs to an implementation, possibly via one or more platform- 134 van Sinderen, Almeida, Pires, & Quartel Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permis- sion of Idea Group Inc. is prohibited. specic models (PSMs). The main advantages of software development based on MDA—software stability, software quality, and return on investment—stem from the possibility to derive different implementations (via different PSMs) from the same PIM, and to automate to some extent the model-transformation process. Service-oriented computing and model-driven engineering have some common goals; they both strive to facilitate the development and maintenance of distributed enterprise applications, although they achieve these goals in different ways. This chapter aims at characterizing the concepts that underlie a model-driven service- oriented approach to the design of enterprise applications and discusses the benets of such an approach. This chapter is further structured as follows. First we discuss the service concept, its relevance to systems design, and its application in service-oriented architectures. Then we introduce the concept of an interaction system in order to explain and distinguish between two important paradigms that play a role in service-oriented design. Next the chapter discusses the concepts of platform, platform-indepen- dence, and abstract platform, and how these t into the model-driven engineering approach. All this serves as a background to the next section; which outlines our model-driven service-oriented approach in terms of a set of related milestones. After this we illustrate the model-driven service-oriented approach with a simple case study, namely, an auction system. Finally the chapter summarizes our ndings and presents some concluding remarks. Service Concept The concept of service has long been recognized as a powerful means to achieve a separation of concerns and adequate abstraction in distributed-systems design, especially for data communication (Vissers & Logrippo, 1985). In recent years, the advent of service-oriented architectures has renewed the attention for this con- cept, which is particularly relevant to enterprise service computing (Papazoglou & Georgakopoulos, 2003). This section discusses the service concept and its application in systems design, with a focus on service-oriented architectures. Systems and Services The Webster’s Dictionary online (http://www.m-w.com) provides a denition of system particularly applicable to distributed systems: “a system is a regularly inter- acting or interdependent group of items forming a unied whole.” This denition Designing Enterprise Applications 135 Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited. indicates two different perspectives of a system: an integrated and a distributed perspective. The integrated perspective considers a system as a whole or black box. This perspective only denes what function a system performs for its environment. The distributed perspective denes how this function is performed by an internal structure in terms of system parts (or subsystems) and their relationships. The integrated perspective of a system coincides with the concept of service. A service is a design that denes the observable behavior of a system in terms of the interactions that may occur at the interfaces between the system and its environment and the relationships between these interactions. A service does not disclose details of an internal organization that may be given to implementations of the system (Vissers, Scollo, Sinderen, & Brinksma, 1991). By considering each part of a system as a system itself, the external and internal perspectives can be applied again to the system parts. This results in a process of repeated or recursive decomposition, yielding several levels of decomposition, also called levels of abstraction. Figure 1 illustrates schematically this process. In the recursive decomposition process, the service concept can represent the behavior of various kinds of entities, such as value chains, business enterprises, software applications, application components, middleware platforms, or communication networks. Service Concept in Service-Oriented Architectures A service in service-oriented architectures is a “self-describing, open component that supports rapid, low-cost composition of distributed applications” (Papazoglou & Figure 1. External and internal system perspectives: (a) system parts and (b) ser- vices Service S System S System part S1 Service S1 Service S 3 . 2 Service S 3 . 3 Service S 3 . 1 Service S 3 . 4 Sub - part S 3 . 1 Sub - part S 3 . 2 Sub -part S 3. 3 Sub - part S 3 . 4 ( de ) composition of S ( de ) composition of S 3 conformance relation System part S2 System part S3 Service S2 Service S3 (b) (a) 136 van Sinderen, Almeida, Pires, & Quartel Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permis- sion of Idea Group Inc. is prohibited. Georgakopoulos, 2003, p. 26). Services in service-oriented architectures are offered by service providers, who are responsible for the service implementations and supply the service descriptions. These descriptions are published in service registries either by the service providers or on their behalf, and are used by potential service users to search and select the services that they want to use. This implies that a service description should contain the service capabilities, but also the technical information necessary to actually access and use the service. Although many authors associate service-oriented architectures only with Web services, there is nowadays a consensus that Web services is just one possible alternative to implement a service-oriented architecture (Erl, 2005). The concept of service as introduced in service-oriented architectures ts in our more general denition given above. We have shown in Quartel, Dijkman, and Sin- deren (2004) that service-oriented architectures are currently being approached in a technology-driven way. Most developments focus on the technology that enables enterprises to describe, publish, and compose application services, and to enable communication between applications of different enterprises according to their service descriptions. This chapter shows how modeling languages, design methods, and techniques can be put together to support model-driven service-oriented design. The service concept can be used as a starting point for design according to different paradigms. The service concept also supports platform independence. Design Paradigms We introduce the concept of interaction system here in order to distinguish design paradigms in terms of how each paradigm addresses the design of interactions be- tween system parts. An interaction system refers to the specication of the way in which system parts interact with each other, that is, affect each other’s behavior in a dened way through the exchange of information. An interaction system involves a portion of the function of each system part and the connecting structure that is available for the system parts to exchange information, as depicted in Figure 2a. Figure 2. Interaction system from (a) distributed (system) and (b) external (service) perspectives (a) (b) service of interaction system connecting structure interaction system (a) (b) Designing Enterprise Applications 137 Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited. An interaction system is a system in itself, and therefore the external behavior of an interaction system can be dened as a service, as depicted in Figure 2b. The service of an interaction system can be taken as a starting point for the design of interactions between system parts. As such, it accomplishes an important separation of concerns, namely those related to the design of applications of the service and those related to the implementation of the service. Protocol-Centered Paradigm In the protocol-centered paradigm, service users interact through a set of interaction patterns offered by a service provider. The set of interaction patterns, or required service, is chosen to suit the interaction needs of the service users, and therefore corresponds to an arbitrary level of functionality that may or may not be easy to implement. A service provider can be decomposed into (or composed of) a layer of protocol entities and an underlying (lower level) service provider, where the pro- tocol entities interact through the lower level service provider in order to provide the required service. Figure 3 illustrates the model of a system according to the protocol-centered paradigm. The level of functionality offered by the lower level service provider may require further (de)composition, yielding a set of hierarchical protocol layers and a nal lower level service provider that corresponds to an available technical construct (e.g., a network product). Protocol entities communicate with each other by exchanging messages, often called protocol data units (PDUs), through a lower level service. PDUs dene the syntax and semantics for unambiguous understanding of the information exchanged between protocol entities. The behavior of a protocol entity denes the service primitives between this entity and the service users, the service primitives between the protocol entity and the lower level service, and the relationships between these primitives. The protocol entities cooperate in order to provide the requested service (Sharp, 1994). lower level service provider service provider service users lower level service provider protocol entities protocol entity service user service user service user protocol entity protocol entity protocol entity Figure 3. System according to the protocol-centered paradigm 138 van Sinderen, Almeida, Pires, & Quartel Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permis- sion of Idea Group Inc. is prohibited. Protocols can be dened at various layers, from the physical layer to the application layer. Lower level services typically provide physical interconnection and (reliable or unreliable) data transfer between protocol entities. Interaction patterns between the protocol entities vary from connectionless data transfer (e.g., “send and pray”) to complex control facilities (e.g., handshaking with three-party negotiation). This design paradigm has inspired some (communication) reference architectures, such as the open systems interconnection reference model (OSI RM) and the transmis- sion-control protocol/Internet protocol (TCP/IP) suite. Middleware-Centered Paradigm In the middleware-centered paradigm, objects or components interact through a limited set of interaction patterns offered by a middleware platform. The middleware platform is an available technology construct that facilitates application development by hiding the distribution aspects of communication. Any component can offer its service to other (previously unknown) remote components if its service denition is made available (published) in terms of interactions that have a predened map- ping onto the interaction patterns of the middleware. This is the case since service interfaces and protocol elements can be derived from the service denition, thereby geographically extending the service to other components and allowing remote ac- cess to the service. In order to distinguish between the possible transient roles of components using and offering a service, we use the terms consumer component and provider component, respectively. Figure 4 illustrates the model of a system according to the middleware-centered paradigm. A provider component may entail complex functionality, and therefore may require further decomposition and/or distribution over multiple computing nodes. Decom- position is achieved by conceiving the provider component as a composition of a consumer component and one or more extended service providers, where each extended service provider offers an extended service as discussed above. This pro- cess continues until the nal components can each be conveniently run on a single computing node and offer a useful unit of functionality. provider component consumer component middleware platform implied protocol entity extended service provider provider component middleware platform implied protocol entities implied protocol entity consumer component implied protocol entity implied protocol entity consumer components Figure 4. System according to the middleware-centered paradigm Designing Enterprise Applications 139 Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited. There are several different types of middleware platforms, each one offering differ- ent types of interaction patterns between objects or components. The middleware- centered paradigm can be further characterized according to the types of interaction patterns supported by the platform. Examples of these patterns are request-response, message passing, and message queues. Examples of available middleware plat- forms are common object request broker architecture/CORBA component model (CORBA/CCM) (OMG, 2002a, 2004), .NET (Microsoft Corporation, 2001), and Web services (World Wide Web Consortium [W3C], 2001, 2003). The middleware-centered paradigm promotes the reuse of a middleware infrastruc- ture. In addition, it enables the development of provider components in isolation of other consumer components, where the latter can use the services of the former through the supported interaction patterns of the middleware. This is different from the protocol-centered paradigm, where (protocol) entities are developed in com- bination to form a single protocol. An interesting observation with respect to the middleware-centered paradigm is that it somehow depends on the protocol-centered paradigm: Interactions between components are supported by the middleware, which transforms the interactions into (implicit) protocols, provides generic services that are used to make the interactions distribution transparent, and internally uses a network infrastructure to accomplish data transfer (Sinderen & Ferreira Pires, 1997). Methods for application development that are inspired by the middleware-centered paradigm often consist of partitioning the application into application parts and dening the interconnection aspects by dening interfaces between parts (e.g., by using object-oriented techniques and abstracting from distribution aspects). The available constructs to build interfaces are constrained by the interaction patterns supported by the targeted middleware platform. Examples of these constructs are operation invocation, event sources and sinks, and message queues. The protocol-centered and middleware-centered paradigms tackle the support of interactions between system parts in different ways, and consequently are suited to different types of applications. For enterprise service computing, the middleware- centered paradigm is more appropriate, although there are situations where protocol design plays an important role. The middleware-centered paradigm is assumed (to some extent) by both SOA/SOC and MDA/MDE. Model-Driven Architecture Approach The concept of platform independence has been introduced in the MDA approach in order to shield the design of applications from the choice of platform and to guarantee the reuse of designs across different platforms. 140 van Sinderen, Almeida, Pires, & Quartel Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permis- sion of Idea Group Inc. is prohibited. The term platform is used to refer to a system that entails all kinds of technologi- cal and engineering details to provide some functionality, which applications can use through dened interfaces and specied usage patterns (OMG, 2003). For the purpose of this chapter, we assume that a platform corresponds to some specic middleware technology. Platform independence is a quality of a model that relates to the extent to which the model is independent of the characteristics of a particular platform (OMG, 2003), including its specic interfaces and usage patterns. In this chapter, we assume that models are used to specify both the behavior and structure of a system, and that several platform-independent models may be used in conjunction to specify a design. A consequence of the use of platform-independent models is the ability to rene the design or implement it on a number of target middleware platforms. Ideally, one could strive for platform-independent models that are absolutely neu- tral with respect to all different classes of middleware technologies. However, we foresee that at a certain point in the development trajectory, different sets of plat- form-independent modeling concepts may be used, each of which is needed only with respect to specic classes of target middleware platforms. Figure 5 illustrates an MDE trajectory in which such a highly abstract and neutral PIM is depicted as the starting point of the trajectory. In Figure 5, the platform-independent models facilitate the transformation to two particular classes of middleware platforms, namely, the request-response (object based) and asynchronous-messaging (message oriented) platforms. Figure 5. An MDE trajectory platform selection . . . . . . platform-independent design platform-specific design request/response asynchronous messag ing IBM MQSeries JMS CORBA JavaRMI design design alternatives Remote Method Invocation RMI = Designing Enterprise Applications 141 Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited. In an MDE trajectory, a designer should clearly dene the abstraction levels at which PIMs and PSMs have to be dened. The choices of platforms should also be made explicit in each step in the design trajectory. Furthermore, the choice of design concepts for PIMs should be carefully considered, taking into account the common characteristics of the target platforms and the complexity of the transformations that are necessary in order to generate PSMs from PIMs. The concept of abstract platform, as proposed initially in Almeida, Sinderen, Ferreira Pires, and Quartel (2003), supports the explicit identication of the level of platform independence that is needed for a model. An abstract platform denes the platform characteris- tics that are relevant for applications at a given platform-independent level. These characteristics are a compromise between what an application developer ideally wants from a platform and what target platforms actually can provide. The PIM of an application depends on an abstract platform model in the same way as the PSM of an application depends on a concrete platform model (Almeida, Dijkman, Sinderen, & Ferreira Pires, 2004). Model-Driven Service-Oriented Design In order to exploit the service concept in an MDA-based design process, we dene the following milestones. 1. Service denition. The service denition sets the boundaries of the enterprise (sub)system to be designed. Services are specied at a level of abstraction at which the supporting infrastructure is not considered. In our case, the infra- structure is the middleware platform, and therefore service specications are middleware-platform independent by denition. The service concept denes a platform-independent level that is also paradigm independent in the sense that both the protocol-centered and middleware-centered paradigms may be used in subsequent design steps. In addition, the service concept allows very different types of middleware platforms to be used for the implementation of the application service, not just similar ones. Service denitions are positioned at the top of the design trajectory depicted in Figure 5. Service users associated with (using) the service, and necessarily relying on the service denition, may consequently be dened at the same level of platform independence. 2. Platform-independent service design. The platform-independent service design consists of the platform-independent service logic, which is structured in terms of application-part functions, and an abstract platform denition. The choice of abstract platform must consider the portability requirements since it denes the characteristics of the platform upon which application-part services [...]... be defined as a service In both paradigms, application parts can be considered as service components that cooperate to provide the required service (according to the service- definition milestone) The description of the milestones suggests a top-down design trajectory, starting from service definition to service design However, this does not exclude the use of bottom-up knowledge Bottom-up experience... Designing Enterprise Applications 143 a kind of business model However, since the notion of CIM and its relationship to PIM are not yet well understood, we refrain from discussing milestones that could be related to CIMs in this chapter The platform-independent service- design milestone corresponds to a PIM, whereas the platform-specific service design corresponds to a PSM The platform-independent service- design... abstraction at which the platform-independent service logic is specified depends on the abstract platform definition Figure 6 illustrates the design trajectory with the service- definition and platform-independent service- design milestones 3 Platform-specific service design The platform-independent service design is transformed into a platform-specific service design, which is structured in terms of... (directly) to the abstract platform definition We show in the next section that when the abstract platform is defined as a service, it is also possible to apply service design recursively The recursive application of service design leads to the introduction of some target platform-specific abstract platform logic to be composed with the target platform The abstract platform service is then refined into a... concept of the abstract platform to completely and explicitly define platform characteristics at the abstraction level that comply with the platform-independent design at hand We propose a model-driven service- oriented design approach that combines these findings The approach identifies the use of the service concept in different milestones of the model-driven engineering trajectory It supports a top-down... of Distributed Computing Systems (pp 8-13) Sun Microsystems (2002) Java(TM) message service specification final release 1.1 Retrieved August 15, 2005, from http://java.sun.com/products/jms/docs html Vissers, C A., & Logrippo, L (1985) The importance of the service concept in the design of data communications protocols In Proceedings of the IFIP WG6.1 Fifth International Conference on Protocol Specification,... Model for Building Enterprise Information Systems 157 composition of autonomous services This new blueprint is poised to reshape the information systems’ architecture, infrastructure, delivery technologies, programming languages, deployment, and management models The goal of this chapter is to help you understand why and how IT should evolve the enterprise architecture toward a service- oriented composite... technology By discussing two design paradigms—protocol centered and middleware centered—we have shown how the service concept can be used in two different ways as a technology-independent starting point for top-down development The service concept is not explicit in MDA We argue that it should be given a more prominent role there since it allows one to precisely define the notion of platform independence... experience is what allows designers to reuse middleware infrastructures, by defining an abstract platform that can be realized in terms of these concrete middleware platforms, and to find appropriate service designs that implement the required service Case Study: Auction System In order to illustrate the use of a service definition and its refinement in a design trajectory, we introduce our case study,... auction service, illustrating that the service specification is to a large extent implementation independent For each platform-independent design obtained, we consider realizations in two concrete platforms: CORBA (OMG, 2004) and the Java Message Service (JMS) point -to- point domain (Sun Microsystems, 2002) Figure 8 illustrates the design trajectories followed in our examples The recursive application of service . provider service users lower level service provider protocol entities protocol entity service user service user service user protocol entity protocol entity protocol entity . description of the milestones suggests a top-down design trajectory, starting from service denition to service design. However, this does not exclude the use of bottom-up knowledge. Bottom-up experience. investment—stem from the possibility to derive different implementations (via different PSMs) from the same PIM, and to automate to some extent the model-transformation process. Service- oriented computing