Enterprise service computing from concept_6 doc

First we discuss the service concept, its relevance to systems design, and its application in service-oriented architectures.. This section discusses the service concept and its applicat

 van Snderen, Almeda, Pres, & Quartel

Copyright © 2007, Idea Group Inc Copying or distributing in print or electronic forms without written

Designing.Enterprise.

Applications.Using.Model-Driven Service-Oriented.Architectures

Marten van Snderen, Unversty of Twente, The NetherlandsJoão Paulo Andrade Almeda, Telematca Insttuut, The Netherlands

Luís Ferrera Pres, Unversty of Twente, The NetherlandsDck Quartel, Unversty 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

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 benefits 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 efficiency 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 glou & Georgakopoulos, 2003) This should promote the introduction of richer and more advanced applications, thereby offering new business opportunities Other foreseen benefits are the shortening of application-development time by reusing available applications, and the creation of a service market, where enterprises make

(Papazo-it their business to offer generic and reusable services that can be used as tion building blocks The service-oriented paradigm is in essence characterized by the explicit identification and description of the externally observable behavior, or service, of an application Applications can then be linked based on the description

applica-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 defines a set of basic concepts such as model, metamodel, and transformation, and proposes a classification

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 first 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- van Snderen, Almeda, Pres, & Quartel

Copyright © 2007, Idea Group Inc Copying or distributing in print or electronic forms without written

permis-specific 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 benefits

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 fit 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 findings 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 definition of system particularly applicable to distributed systems: “a system is a regularly inter-acting or interdependent group of items forming a unified whole.” This definition

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 defines what function a system performs for its environment The distributed perspective defines 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 defines 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) vices

ser-Service S System S

System part S2 System part S3

Service S2 Service S3

(b) (a)

 van Snderen, Almeda, Pres, & Quartel

Copyright © 2007, Idea Group Inc Copying or distributing in print or electronic forms without written

permis-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 fits in our more general definition 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 specification of the way in which system parts interact with each other, that is, affect each other’s behavior in

a defined 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

servce of

nteracton system connectng

structure

nteracton system

An interaction system is a system in itself, and therefore the external behavior of

an interaction system can be defined 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 final 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 define the syntax and semantics for unambiguous understanding of the information exchanged between protocol entities The behavior of a protocol entity defines 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 servce provder

servce provder servce users

lower level servce provder protocol enttes protocol entty

servce user servce user servce user

protocol entty protocol entty protocol entty

Figure 3 System according to the protocol-centered paradigm

 van Snderen, Almeda, Pres, & Quartel

Copyright © 2007, Idea Group Inc Copying or distributing in print or electronic forms without written

permis-Protocols can be defined 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 sion-control protocol/Internet protocol (TCP/IP) suite

transmis-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 definition

is made available (published) in terms of interactions that have a predefined ping onto the interaction patterns of the middleware This is the case since service interfaces and protocol elements can be derived from the service definition, 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

map-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 final components can each be conveniently run on a single computing node and offer a useful unit of functionality

provder component consumer

component

mddleware platform

mpled protocol entty

extended servce provder

provder component

mddleware platform

mpled protocol

enttes mpled protocol entty

consumer component

mpled protocol entty

mpled protocol entty

consumer

components

Figure 4 System according to the middleware-centered paradigm

There are several different types of middleware platforms, each one offering 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).

differ-The middleware-centered paradigm promotes the reuse of a middleware ture In addition, it enables the development of provider components in isolation

infrastruc-of other consumer components, where the latter can use the services infrastruc-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 defining the interconnection aspects by defining 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

0 van Snderen, Almeda, Pres, & Quartel

Copyright © 2007, Idea Group Inc Copying or distributing in print or electronic forms without written

permis-The term platform is used to refer to a system that entails all kinds of cal and engineering details to provide some functionality, which applications can use through defined interfaces and specified usage patterns (OMG, 2003) For the purpose of this chapter, we assume that a platform corresponds to some specific middleware technology

technologi-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 specific 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 refine the design or implement it on a number of target middleware platforms

Ideally, one could strive for platform-independent models that are absolutely 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 specific classes of target middleware platforms Figure 5 illustrates

neu-an MDE trajectory in which such a highly abstract neu-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 selecton

.

.

desgn desgn alternatves

Remote Method Invocaton RMI =

In an MDE trajectory, a designer should clearly define the abstraction levels at which PIMs and PSMs have to be defined 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 identification of the level of platform independence that is needed for a model An abstract platform defines 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 define the following milestones

1 Service definition The service definition sets the boundaries of the enterprise

(sub)system to be designed Services are specified 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 specifications are middleware-platform independent by definition The service concept defines

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 definitions 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 definition, may consequently be defined 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 definition The choice of abstract platform must consider the portability requirements since it defines the characteristics of the platform upon which application-part services

 van Snderen, Almeda, Pres, & Quartel

Copyright © 2007, Idea Group Inc Copying or distributing in print or electronic forms without written

permis-may rely The level of 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

is transformed into a platform-specific service design, which is structured in terms of platform-specific application-part functions and a concrete platform definition This transformation may be straightforward when the selected platform corresponds (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 composition of a target platform and the abstract platform logic

The service-definition milestone can be considered the starting point for PIM design,

or alternatively, the end result of business design in which business processes are articulated and their computer support (automation) is identified without revealing any details on how the automation is accomplished In the latter case, the service definition corresponds to the computer support MDA introduces the notion of the computation-independent model (CIM; OMG, 2003), which can be considered as

Figure 6 Service decomposition into underlying interaction system provided by abstract platform

abstract platform definition

independent service design a.p = application part

platform-a kind of business model However, since the notion of CIM platform-and its relplatform-ationship 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 milestone does not mention which paradigm—protocol centered or middleware centered—is used to achieve this result This is because, depending

on the type of application, either paradigm can be used If application parts have a complex interaction and are tightly coupled, they should be designed in combina-tion and the protocol-centered paradigm should be used (with the abstract platform

as the lower level service provider) In this case, application parts are normally not described as separate services, but their combined behavior in terms of protocol messages can be abstracted as a service However, if application parts offer general useful functions that can be invoked through simple interactions supported by existing middleware, they can be defined in isolation and the middleware-centered paradigm should be preferred In this case, each application-part function in a provider role can 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 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, namely, an auction system In this case study, service users (participants) participate in auctions in which products are sold to the highest bidder Any participant may auction off and bid for products In order to simplify the case study, we consider the number of participants to be fixed and predefined

Auction.Service

The auction service must be specified in such a way that interaction requirements between participants are satisfied without unnecessarily constraining implementation

 van Snderen, Almeda, Pres, & Quartel

Copyright © 2007, Idea Group Inc Copying or distributing in print or electronic forms without written

permis-freedom This freedom includes the structure of the auction service provider (the system that eventually supports the auction service) and other technology aspects such as middleware platforms, operating systems, and programming languages Therefore, services are described in abstract terms by interactions and their relation-ships An interaction in a service definition is a common unit of activity performed

by a service user and a service provider; it occurs at the local service interface that directly connects these two system parts (Vissers & Logrippo, 1985; Vissers et al., 1991)

The auction service relates the following interactions:

• offer and offer_ind, both with attributes product_id and opening_value The

product_id uniquely identifies a product being auctioned.

• bid and bid_ind, both with attributes product_id and bid_value.

• outcome_ind, with attributes product_id, final_value, and participant_id The

participant_id uniquely identifies a participant in the auction In the case of

this interaction, it identifies the winning bidder

These interactions occur at the interfaces between the auction service provider and the participants The occurrence of an interaction results in the establishment of values for its attributes In addition to the attributes listed above, for each interaction, the

participant_id is implied by the location where the interaction occurs.

A convenient technique for specifying a service is to define the service as a junction of different constraints on interactions (Vissers et al., 1991) In particular,

con-a useful structuring principle is thcon-at of identifying loccon-al con-and end-to-end (or remote) constraints

The local constraint (related to each participant) for this service is:

• bid, which can only occur after offer_ind and before outcome_ind (for a given

product_id).

The remote constraints (between participants) for this service are the following:

• The occurrence of offer is followed by an occurrence of offer_ind for each

participant in the auction

• The occurrence of bid is followed by an occurrence of bid_ind for each

par-ticipant in the auction

• outcome_ind occurs ∆t seconds after the last bid_ind occurs (for a given

8 illustrates the design trajectories followed in our examples

The recursive application of service decomposition is shown in the design tory on the rightmost side of Figure 8 The service of the request-response abstract platform is further decomposed for realization in the JMS platform In the following,

trajec-we discuss each of the alternative trajectories depicted in Figure 8

Figure 7 Auction service

partcpant’s functons

nteractons:

offer (ProductId pid, Value opening)

offer_ind (ProductId pid, Value opening)

bid (ProductId pid, Value bidvalue)

bid_ind (ProductId pid, Value bidvalue)

outcome_ind (ProductId pid, Value finalvalue, ParticipantId participant)

aucton servce partcpant ‘s

functon

 van Snderen, Almeda, Pres, & Quartel

Copyright © 2007, Idea Group Inc Copying or distributing in print or electronic forms without written

permis-Callback-Based.Solution.with Message-Exchange.Abstract.Platform

Abstract.Platform:.Message.Exchange

Initially, let us consider an abstract platform that supports message exchange We identify two interactions that are related by the abstract platform:

• send, with attributes destination and payload, and

An occurrence of receive follows an occurrence of send The interaction receive is executed at the location specified by the attribute destination of send The attribute

payload represents the information to be sent The value of the attribute payload

for an occurrence of receive is the value of the attribute payload for the related occurrence of send.

Figure 8 Examples of alternative trajectories

servce components (JMS-specfc desgn)

JMS

servce components (platform-ndependent)

abstract platform logc (JMS-specfc desgn) JMS

servce decomposton

servce components (platform-ndependent)

abstract platform request/response

servce components (platform-ndependent)

abstract platform message exchange

callback-based

servce decomposton source desgn

CORBA PIM-PSM