Path:
Periodical volume

Full text: AIS-Transactions on enterprise systems Issue 2009,2

Imprint

Imprint
AIS Transactions on Enterprise Systems www.enterprise-systems.net
Editor in Chief Prof. Dr. Norbert Gronau, University of Potsdam, Germany Associate Editors Prof. Niels Bjorn-Andersen, Copenhagen Business School, Denmark Prof. Dr. Robert Davison, City University of Hong Kong, Hong Kong Prof. Dr. Peter Loos, Institute for Information Systems (IWi), Saarland University, Germany Prof. Dr. Selmin Nurcan, University Paris 1 – Pantheon-Sorbonne, France Prof. Marcus Rothenberger, University of Nevada, Las Vegas, USA Prof. Dr. Petra Schubert, University of Koblenz-Landau, Germany Prof. Dr. Mary Sumner, Southern Illinois University Edwardsville, USA Prof. Dr. Robert Winter, Institute of Information Management, University of St. Gallen, Switzerland Prof. Dr. Xiaofei Xu, Harbin Institute of Technology, China

Executive Board

Senior Editors Prof. Dr. hab. Witold Abramowicz, Poznan University of Economics, Poland Dr. Yves Caseau, Bouygues Telecom, France Prof. Dr. Chiara Francalanci, Polytechnic Institute of Milan, Italy Prof. Claude Godart, University Henri Poincaré, Nancy, France Dr. Wei Yuan Carol Hsu, City University of Hong Kong, Hong Kong Editorial Board Members Dr. Yousef Amer, University of South Australia, Australia Dr. Alejandro Artopoulos, University of San Andres, Argentinia Dr. Joseph M. Firestone, KMCI - Knowledge Management Consortium International, Alexandria, USA Dr. Tim Klaus, Texas A&M University-Corpus Christi, College of Business, USA Prof. Yoram Reich, Tel Aviv University, Israel Dr. Maha Shakir, Zayed University, Dubai, United Arab Emirates Prof. Dr. Peter K.J. Tobin, University of Pretoria, South Africa Christian von Bogdandy, Ulixes Consulting, USA Prof. Bernhard Wieder, University of Technology Sydney, Australia Prof. Dr. Nancy I-Chin Wu, Fu Jen Catholic University, Hsinchuang, Taiwan Editorial office Carsten Brockmann University of Potsdam August-Bebel-Straße 89, 14482 Potsdam, Germany Tel.: 0049 331/977-3455 Fax: 0049 331/977-3406 E-Mail: editorial-office@enterprise-systems.net Publisher GITO Publishing GmbH Detmolder Str. 62, 10715 Berlin, Germany Tel.: 0049 30/41938364, Fax: 0049 30/41938367 © 2008 GITO mbH - Verlag für Industrielle Informationstechnik und Organisation 2nd volume 2009 ISSN 1867-7134 The journal and all included content is copyright-protected by national and international laws. Reproduction is only legal with the written permission of the publisher.

1867-7134 © GITO mbH

1

Contents

Contents
Sonja Zaplata, Viktor Dreiling, Winfried Lamersdorf Realizing Mobile Web Services for Dynamic Applications I. M. Lazarte, O. Chiotti, P. D. Villarreal Transforming Collaborative Process Models into Interface Process Models by Applying an MDA Approach Nicolas Biri, Pascal Bauler and Fernand Feltz Smooth integration of Existing applications in an SOA Hans Weigand, Jeewanie Jayasinghe Arachchige Value Encounters: Modelling and Analyzing Co-creation of Value

3

13

24

32

2

AIS Transactions on Enterprise Systems 1 (2009) Vol. 2

Available online al.:www.enterprise-systems.net S. Zaplata et. at Realizing Mobile Web Services for Dynamic Applications

AIS Transactions on Enterprise Systems 1 (2009) 2, 3-12

Realizing Mobile Web Services for Dynamic Applications*
Dipl.-Inf. Sonja Zaplata, B.Sc.-Inf. Viktor Dreiling and Prof. Dr. Winfried Lamersdorf
Abstract
Use of web services also on mobile devices becomes increasingly relevant. However, realizing such mobile web services based on the standard protocol stack is often inappropriate for resourcerestricted mobile devices in dynamic networks. On the other hand, using specialized alternative protocols restricts compatibility with traditional service applications. Thus, existing approaches often do not allow to integrate heterogeneous service instances dynamically, as it is, e.g., required for executing mobile service-based business processes. In order to adequately support such more complex and dynamic applications, this paper presents a lean and flexible system architecture which supports both mobile web service consumers and providers by allowing to integrate multiple protocols depending on their capabilities and to dynamically access suitable service instances at runtime. As a proof of concept, the paper shows an exemplary combination of practically relevant protocols for resource-limited devices based on WSDL, ASN.1 and overlay transport and presents its integration in a prototype scenario for supporting decentralized mobile business processes. environments. Especially the emergence of respective mobile middleware systems leads to a rather ubiquitous availability of information and enables new personalized and context-based services for private consumers as well as for business applications. Considering the provision and consumption of such service functionality in stationary networks, web services have proved to be a successful integration technology. Based on the standardized Web Service Description Language (WSDL), the message encoding format SOAP and the Hypertext Transfer Protocol (HTTP) as specified by the W3C [4], a web service typically defines an interface between two or more software applications. As web services are self-describing and enable the development of loosely-coupled distributed applications, they are - in general also very well suited to integrate mobile service providers and consumers. Nowadays, standard web service technologies can be applied to several mobile devices almost without any problems, e.g. considering notebooks or the newest generation of mobile phones using relatively reliable wireless networks such as WLAN or UMTS. However, the conventional web service communication framework is mostly inappropriate for small mobile devices in decentralized networks, e.g. for wireless sensors or active RFID tags, which still have very restricted resources with respect to computing power, memory capacity and communication bandwidth (cp. [1]). Several drawbacks of standard web service protocols have already been investigated in previous research

1.

Introduction

Mobile web services currently form one of the most promising approaches to apply wellestablished service-oriented concepts to mobile

* The research leading to these results has received funding from the European Community’s Seventh Framework Programme FP7/2007-2013 under grant agreement 215483 (S-Cube).

1867-7134 © GITO mbH

3

S. Zaplata et. al.: Realizing Mobile Web Services for Dynamic Applications

works: As the most important point, the textual representation of XML-based descriptions as used in WSDL and SOAP leads to a low information density and thus to an inefficient use of communication bandwidth. As another example, the synchronicity of HTTP results in intolerance to network failures and excludes typical mobile network technologies such as Bluetooth or IrDa. Concerning the discovery of mobile services, centralized systems such as UDDI (Universal Description, Discovery and Integration) can hardly be applied in decentralized networks and prove to be inefficient in systems with changing network addresses (cp. [3, 14]). The emergence of manifold and more decentralized applications have therefore triggered the development of alternative web service protocols dealing with some of the before mentioned problems. Being specific to a concrete network or addressing particular drawbacks such as messaging overhead, these protocols focus on the requirements of resource-limited mobile systems and respectively use less complex communication protocols and description languages (e.g. [2, 17]). Such alternative protocols enable mobile devices to consume specially adapted web services running on stationary servers, e.g. in order to outsource business logic or tasks which are computationally intensive. Since mobile devices are also able to provide web services themselves, also novel applications such as sharing resources and functionality in mobile ad-hoc networks can be realized. For example, a built-in car navigation system could be used to transfer the current position to a local mobile phone using Bluetooth. Nevertheless, it could also be accessed from remote (e.g. by a desktop PC) to find a stolen car by using a standard HTTP connection. Other application areas involve the provision of context information about the user or its device, or act as a replacement of physical things, e.g. by simulating a wallet by an automatic payment service [3]. Besides such specialized monolithic applications, (mobile) web services can also be part of more complex and dynamic applications, such as, e.g. business processes running on mobile devices (e.g. [8, 13]). Due to the prevailing diversity of protocols in the area of mobile web services, most of such distributed applications use rather abstract descriptions of services, avoiding to specify concrete protocols, network addresses and other specific technological details. In contrary to stand-alone applications, the execution of mobile business processes therefore requires a dynamic discovery, selection and binding of available services and thus requires to support more than one specific protocol. At the same time the processes’ functionality is provided as an aggregated

service itself. This means that there is a need for a dynamic mobile web service architecture embracing functionality for service consumption as well as for service provision, considering heterogeneous devices, networks and protocols. Addressing such challenges, the following section analyzes existing work in the area of mobile web services and identifies research gaps with respect to dynamism, flexibility and interoperability of mobile service providers and consumers. To overcome the identified restrictions, section 3 introduces a lightweight architecture to both use and provide web services based on arbitrary protocols, as well as to publish, find and bind such services dynamically. Section 4 presents an example combination of protocols suitable for smaller and medium mobile devices. The prototypical implementation is evaluated in section 5, integrating the proposed architecture and its reference configuration into an existing mobile process execution system. The paper concludes with a brief summary and an outlook on future work.

2.

Existing and Related Work

Due to the large amount of work in the area of web services and mobile computing, this section abstracts from individual approaches, but classifies them with respect to the strategies used to provide and use web services in heterogeneous mobile environments. Thus in general, respective previous and ongoing research can be distinguished into three main areas: Application and adaptation of standard web service technology; integration of alternative protocols, description languages and registries; and use of additional mediator components. 2.1. Adaptation of Standard Web Service Technology As introduced above, in some cases standard web service technologies (i.e. WSDL, SOAP, HTTP and UDDI) can directly be applied to mobile systems (as e.g. shown by [15]) – assumed that these are relatively powerful, use reliable network connections and are able to provide adequate addressing mechanisms. Smaller and more restricted mobile systems however often omit dynamic components which need a large amount of resources or which cannot be realized due to decentralized infrastructures. Two examples are summarized in the following: • Considering the consumer side, web services can be bound statically as a fixed part of the

4

AIS Transactions on Enterprise Systems 1 (2009) Vol. 2

S. Zaplata et. al.: Realizing Mobile Web Services for Dynamic Applications

mobile application. This relieves mobile devices from service discovery and from generating and integrating web service proxies at runtime. However, this simple approach is very inflexible as services cannot be exchanged at runtime and thus it does not support applications which require to pick service instances dynamically. • Mobile service providers can optionally abstain from publishing their services in a registry and assume that potential service consumers are aware of the services’ existence and syntax. Obviously, this strategy is rather restrictive as service providers can hardly expand the number of users if the service cannot be discovered dynamically. 2.2. Alternative Protocols, Description Languages and Registries As standard web service protocols do not adequately meet the needs of resource-restricted mobile computing infrastructures, alternative technologies have evolved. These address – among others – the overhead of XML in service descriptions and messages, the synchronicity of communication and the centralization of registry information. Examples to exchange (in part or in total) the standard combination of HTTP, SOAP, WSDL and UDDI are sketched in the following: • Universal (e.g. ZIP) or XML-specific (e.g. XMILL) compression mechanisms can efficiently be used to minimize the size of XML messages (e.g. [17]). Nevertheless such algorithms are quite resource-intensive as they require a relatively large amount of computing power to encode and decode the messages. • To reduce complexity in another way, the use of XML can be avoided by alternative description languages, such as JSON (JavaScript Object Notation) or ASN.1 (Abstract Syntax Notation Number One) (cp. [12]). • A more appropriate asynchronous communication can be realized by using alternative protocols such as SMTP and POP/ IMAP, decoupling sender and receiver and thus allowing disconnected operation of web services (cp. [18]). • The overhead of HTTP can alternatively be eliminated by performing message exchange over TCP or UDP directly (cp. [18]). • Registries for decentralized infrastructures allow service providers to describe their services locally (e.g. WS-Inspection) or to save service information in a distributed way (e.g. Konark presented by [9]).

• The emergence of advanced addressing mechanisms such as MobileIP will probably facilitate the access of mobile (web service) resources. 2.3. Mobile Web Service Architectures and Use of Mediator Components While the use of traditional web service technologies does not consider specific characteristics of mobile computing systems, the restriction to specialized alternative approaches leads to an incompatibility with traditional web service applications. Therefore, current research considers the challenges arising from the diversification of above mentioned technologies and protocols. Primarily, approaches which are similar or related to this work focus on the use of additional mediator components. The most important examples are presented below: • In order to address the exclusion of local services and personal area networks, proxy components can be applied both to service consumers and providers. As an example, the approach presented by [2], presents an architecture which allows web service invocation over Bluetooth by wrapping SOAP messages to bind them to the Bluetooth transport protocol. More general approaches establish an overlay network to completely abstract from technological details of the underlying transport layer (e.g. [6]). • To consider limitations of mobile systems and allow proprietary protocols, a mediation framework can act as a broker between the mobile device and stationary web service providers or consumers (e.g. [5, 7]). In this case, the mediator is responsible for the transformation and the routing of web service messages. Furthermore, peer-topeer mediator approaches have also successfully been applied to mobile service providers and consumers [16]. However, if mediators are not accessible, this component represents a hazardous single point of failure in centralized as well as in decentralized infrastructures. • To integrate alternative transmission protocols dynamically, the preferred message representation can be subject of negotiation. As an example, the Handheld Flexible Representation (HHFR) [14] optionally determines which part of a SOAP message is omitted when invoking a service. The approach is characterized by a very flexible architecture and is able to adapt to the requirements of mobile devices dynamically. Considering the repeated invocation of the same service, the following data exchange can be reduced considerably. In case of single service

1867-7134 © GITO mbH

5

S. Zaplata et. al.: Realizing Mobile Web Services for Dynamic Applications

invocations, however, the negotiation itself causes a considerable overhead. 2.4. Requirements Summary As an interim result, it seems that there is no perfect combination of traditional and alternative technologies, but that the use of a specific approach is determined by the capabilities of the mobile system and its applications. Although web services have originally been intended to integrate heterogeneous resources, the diversification of protocols resulting from necessary adaptations leads to another integration problem. On the one hand, heterogeneous capabilities and characteristics of mobile devices with respect to network connection and protocol support have to be considered. On the other hand, interoperability with traditional applications and industry standards should be preserved. Finally, dynamic applications such as ad-hoc mobile business processes require the executing mobile device to adapt to available service instances and protocols at runtime – a system software characteristic which is hardly supported by current mobile web service architectures. These observations lead to the need of a flexible web service architecture which is able to adapt to the prevailing technology at runtime – provided the respective (mobile) device is able to support one or more (to some extent) established protocols. The next section therefore presents the basic idea of a flexible web service architecture for such dynamic mobile applications.

3.

A Flexible Mobile Service Architecture

As presented in the previous section, developers of mobile web service providers and mobile web service clients can select from a large range of protocols and technologies to adjust their application to the requirements and capabilities of the mobile device. To enable a customized design of mobile web service applications, to allow interoperability with more than one service consumer or provider and to access services dynamically, this section presents an adaptable web service architecture for mobile devices. Figure 1 shows a coarse overview of the decentralized mobile service-oriented architecture. It consists of one or more (possibly mobile) service providers and consumers which both integrate an individual local registry. In case of the service provider, the registry holds and manages the service descriptions of the service instances provided by the

mobile device itself. For the service consumer, the registry is responsible to search for required services by exchanging information with the registries of service providers in the local environment. Because the local registry only acts as a proxy to its environment, also centralized stationary registries (e.g. UDDI) or distributed decentralized registries (e.g. Konark by [9]) can participate if they are in communication range of the mobile service requester. The detailed architecture for mobile web service consumers and providers is characterized by a modular design. The resulting basic architecture for both roles is depicted in figure 2. Due to potential resource restrictions, basic functionality such as communication, message handling and service registration is shared by consumer and provider components. Functionality exclusive to service providers involves a lightweight service runtime environment which manages respective service instances. Exclusive to the client side, a proxy generator is responsible for generating and assigning local proxies to invoke a mobile web service. The proxy represents a local interface of the remote service, handles the work of mapping parameters to the elements of the description language and prepares the respective message contents to be send over the network. Depending on the capabilities of the mobile system and on the requirements of the application(s), this abstract architecture can be instantiated with one or more adapters realizing a concrete technology. Alternative technologies can be assigned to service description, to message encoding and to transport protocols. For example, to be compatible to industry standards, services can be described using a WSDL adapter for the local registry and for proxy generation, the message handling can use SOAP format and finally, the communication component can include an HTTP adapter to send the message. To be compatible to resource-restricted mobile devices, alternative configurations can be realized, e.g. as the combination of WSDL, ASN.1 and overlay network transport which is presented in section 4. The overall procedure of providing and consuming web services is realized as follows: First, the service provider publishes its services to the local registry (Step 1 in figure 1 and 2). As the deployment of adapters and services is performed at design-time, each published service can be associated with one or more descriptions determined by the configuration of supported protocols. Potential service consumers are now able to find these services by performing an abstract service

6

AIS Transactions on Enterprise Systems 1 (2009) Vol. 2

S. Zaplata et. al.: Realizing Mobile Web Services for Dynamic Applications

communication protocol it supports (step 3). The environment of the Local Registry Local Registry device is therefore determined by the 4. Return Service capabilities of the communication Description adapter, e.g. resources on the Internet can be accessed via HTTP, whereas local networks can only be accessed via alternative communication protocols. The resulting request 6. Invoke Service (Mobile) (Mobile) now involves at least the identifier Service Provider Service Consumer 7. Service Response of the service’s functionality (e.g. a simple Uniform Resource Identifier (URI), a Universally Figure 1: Overview of the mobile service architecture Unique Identifier (UUID) or a link to external semantic resources such request to their local registry (step 2). The abstract as an Resource Description Framework (RDF) service request contains the search parameters of the document) and optionally a list of supported or respective application, e.g. the required functionality preferred protocols (cp. figure 3.). The potential service provider receives the of the service and optionally non-functional criteria. The consumer’s registry first checks if the required incoming service request and – assumed it has at least service can be accessed locally, e.g. in case the service one suitable adapter – forwards it to the registry which is provided by the device itself. Otherwise it forwards picks an adequate format to return the description the request to other devices in its environment of the requested service instance (step 4). As the making use of the type(s) of encoding format and description is received by the consumer, it is forwarded
3. Request Service Description

Figure 2: Mobile service architecture component model
Components of Service Providers

Runtime Environment
- Execute services

6. Service Invocation

Consumer Architecture

Provider Architecture

5. Forward Service Description

2. Request Service

1. Publish Service

Service Instance
- Provide service interface - Provide service functionality

7. Service Sesponse

6. Service Invocation

7. Service Response

Shared Components Communication
3., 4., 6., 7. Physical Data Transfer - Receive messages - Send messages 3., 4., 6., 7. Message Exchange

Message Handling
- Generate messages - Parse messages

3. Service Consumer: Request Service Description

Registry
- Manage service descriptions - Send service queries - Return service descriptions

Service Provider: 1. Publish Service

Communication Adapter 1

Encoding Format Adapter 1 Encoding Format Adapter 2

4. Service Provider: Incoming Service Description Request

Service Consumer: 2. Request Service

Description Language Adapter 1 Description Language Adapter 2

Transport Layer

Communication Adapter 2

4. Service Provider: Send Service Description

Application Layer

Components of Service Consumers

5. Forward Service Description

6. Service Invocation

7. Service Response

Proxy Generator
- Generate proxies dynamically or select static proxy 5. Provide Proxy

Proxy
- Provide (local) service interface

Service Consumer: 6. Invoke Service 7. Service Response

Description Language Adapter 1 Description Language Adapter 2

Optional Proxy Repository

1867-7134 © GITO mbH

7

S. Zaplata et. al.: Realizing Mobile Web Services for Dynamic Applications

Description Language Adapter 1

Service query
Identifier of service's functionality, e.g. URI Supported or Supported or Supported or preferred protocols preferred protocols preferred protocols

1. Search for appropriate service

Directory

2b. Forward description

Service description
Language-specific service description, e.g. WSDL document

2a. Search cache 4. Return specific service description

Cache

3. Apply appropriate adapter to produce requested description

Figure 3. Service discovery: receiving a remote service request

to the proxy generator (step 5). Depending on the implementation, the proxy can either be picked from a proxy repository holding a number of static proxies or can be generated automatically according to the received service description. The service consumer is now able to invoke the service by calling the provided proxy object (step 6). The proxy uses the message format and communication protocol as specified in the service description to send the required input parameters, and if any, receives the service’s return values (step 7). If the service is going to be invoked again later, the proxy can optionally be added to the proxy repository. To address scalability, the presented architecture supports complex applications acting as service providers and service consumers at the same time as well as both roles individually. As the role-specific components are completely optional, unneeded provider/consumer functionality can be omitted to save resources. Furthermore, the type and number of adapter components can be tailored to the capacity and performance of the mobile device. However, if the number of adapters is rather small or the applied protocols are too exotic, the compatibility will be restricted to special application areas and therefore influence the number of suitable service consumers or providers.

restricted mobile devices. The configuration reduces the overhead of the message description by using a non-XML description language and provides mechanisms for compensation of connection resets by creating an overlay network between the mobile participants. However, this configuration only shows one example of several (arbitrary) combinations which can be composed depending on the mobile devices’ actual capabilities. Other combinations and their interplay can be found in section 5. 2.4. Service Description The example configuration presented here uses WSDL 2.0 to be compatible to established web service based systems and only differs in the use of an alternative message description language and an alternative transport protocol. WSDL allows the integration of both alternative message description languages and transport protocols without violating the WSDL standards of W3C (cp. [4]). Listing 1 shows an example of a WSDL binding that contains the URIs associated with the alternative technologies used in this example configuration.
  

4.

An Example Configuration for Mobile Web Services

Since actual web service standards WSDL, SOAP and HTTP do not meet the requirements of mobile systems particularly well, alternative technologies for the realization of mobile web services can be considered. This section presents a proposal on technologies that can be integrated into the presented architecture to realize web services on more resource-

Listing 1: WSDL Binding
4.2. Encoding Format The example configuration uses ASN.1 and DER encoding to describe the communication

8

AIS Transactions on Enterprise Systems 1 (2009) Vol. 2

Description Language Adapter 2

Local Registry

S. Zaplata et. al.: Realizing Mobile Web Services for Dynamic Applications

messages containing the payload and the protocol data. The approach is based on the specifications X.694 [11], X.690 [10] and X.892 [12] of ITUT and, in comparison to XML-SOAP, results in a reduced description overhead, which has also been shown in [12]. The basic idea of the message exchange is to use a predefined set of data types which are known to all participants (X.694 and X.892) followed by a binary encoding of the values according to their types (e.g. UTF8 encoding of strings) and a substitution of the data types by binary constants which are – due to the standardization – also known to other participants (X.690). Listing 2 shows an example of an XML schema describing the structure of a message, whereas listing 3 shows the respective ASN.1 instance. Listing 4 shows the resulting DER encoding of this instance representing the actual payload of a communication message. As to see, the encoded value only contains information about the structure of the original complex value, the values of the elements it consists of and their types, but it does not contain additional identifiers.
     

00110000 00000110 00000010 00000001 00000010 00000010 00000001 00000010

(binary constant associated with a sequence) length of the binary representation of that sequence, i.e. number of octets, 6 in this example) (binary constant associated with an integer, i.e. elem1) (length of the binary representation of that integer) (value 2) (binary constant associated with an integer, i.e. elem2) (length of the binary representation of that integer) *value 3)

Listing 4. DER encoding of the example message
4.3. Communication Protocol The communication interface can be realized by one of the individual alternative protocols presented in section 2, e.g. TCP/IP, Bluetooth or IrDA. To also show the applicability for more complex solutions, the communication adapter used in the example configuration abstracts from specific transport protocols, but relies on a peerto-peer overlay network with its own addressing scheme and an asynchronous message transport (as e.g. proposed in [6]). To detect other devices in the environment, participating devices use their communication adapter to send short broadcast messages in periodic intervals. Within these messages, they encode their UUID – a identifier that is universally unique for every device. When a device receives such a message, it saves the UUID and its source address. This information is updated or complemented in case the same UUID is received with a different source address. As a result, the participating devices have basic up-to-date information about other devices in the (local) environment and the current protocols and addresses that can be used to contact them. In order to communicate with a particular device, the sender selects an address associated with the UUID of the receiver. This (virtual) address is then translated into a concrete protocol specific address and the message is sent using the respective protocols and endpoint information. If the device is reachable by different protocols, more than one address can be associated with a UUID. The participants are therefore able to select the most appropriate protocol – or change the communication interface in case a connection is temporarily interrupted.

Listing 2. Message structure defined in XML Schema
integerSequence SEQUENCE ::= { elem1 2, elem2 3 }

Listing 3. Message structure defined in ASN.1
The complete message is encoded similarly to the presented example. The X.892 specification of ITU-T describes the structure of an ASN.1 SOAP message and defines the obligatory fields. Among other attributes, each instance representing the payload of the message has an ID attribute to denote the schema of the instance, particularly its URI (namespace) and its name. Since provider and client possess the WSDL document of the web service, both can understand the information that is encoded as an ID, assign the identifiers to the values and interpret the messages correctly.

1867-7134 © GITO mbH

9

S. Zaplata et. al.: Realizing Mobile Web Services for Dynamic Applications

5.

Prototype Implementation and Use Case Scenario

In order to demonstrate the feasibility of the approach, the flexible architecture and its example configuration have been prototypically implemented and integrated into the DEMAC (Distributed Environment for Mobility Aware Computing) project. DEMAC realizes the idea of mobile (business) processes migrating several stationary and mobile devices in order to share their resources and functionality (cp. [13]). A typical application scenario for such processes is e.g. the contextbased collection and processing of information in mobile environments, involving data from wireless sensors, mobile users or traditional web service resources. Since devices which are able to execute mobile processes can be considered to be relatively powerful (e.g. notebooks or PDAs), the presented architecture can be used to aggregate a set of protocols in order to integrate web services from several heterogeneous devices and networks. As required service functionality is specified in a technology-independent way, the process execution engine can use the presented architecture to search for adequate service instances and integrate them at runtime. The resulting use case scenario is depicted in figure 4. The described example configuration has been applied to a wireless sensor (device 1) which provides temperature data. The application of the example configuration using ASN.1 reduces the size of communication messages considerably (cp. also last row in figure 5) and achieves even better results if the number of long identifiers that occur in the message payload is getting larger. The ASN.1 type library is implemented as a small set of structures which can be combined to create a complete message. The instance of each structure calls the encoding procedure responsible for the associated ASN.1 type and saves its result into a collective output container. Thus the messages do not have to be parsed, but can be encoded directly by passing the respective values to the encoder. In consequence, the implementation is very fast and efficient and can be considered to be quite suitable even for latest technologies such as e.g. active RFID tags which have a very restricted communication bandwidth. The standard web service configuration is provided by a stationary server (device 2) transforming the temperature data into another representation (e.g. Celsius to Fahrenheit). Device 3 is responsible to execute the mobile process integrating both of these functionalities as a simple sequential service

composition. Using adapters for the presented reference configuration addressing small mobile devices (cp. section 4) and adapters for the standard set of web service technologies (i.e. WSDL, SOAP and HTTP), the executing mobile device is able to access the wireless sensor as well as the traditional stationary web service. It is further able to dynamically generate the respective proxies and thus involve the required functionality to fulfill the mobile processes’ activities at runtime. The integrated services are re-offered as a composed service functionality using either the example configuration, the standard web service technologies or even another mix of protocols, as exemplary represented by another web service consumer (device 4). However, if the set of supported protocols does not match any other configuration (as indicated by device 5) the required services cannot be accessed. Due to its mobility, the incompatible device is however still able to potentially find adequate services in another environment. The number and size of the messages exchanged to execute the presented scenario are depicted in figure 5. To allow a proper comparison of message sizes, all services used in the test share a similar message structure (i.e. a request-response message exchange pattern with one input and one output parameter) as well as a similar service description (in WSDL). The italic font indicates that the respective value is variable and results from the parameters used in the test scenario. The experimental evaluation of the prototype shows that the load of finding the proper configuration only affects devices which are able to cope with different protocols and adapters - and thus can be regarded to be more powerful. If more than one adapter for communication is available, the device can start service discovery with its preferred protocol and fall back to other protocols in case there is no positive response. For instance, in the worst case, device 3 would have to send the service discovery message over all of its three communication protocols. It is obvious that the more adapters are available on a mobile device, the higher is the probability of finding an adequate service. Less powerful devices will simply ignore the messages which cannot be interpreted and only respond to those which will lead to a correct service invocation. The configuration of adapters and thus protocols can be installed in a way which fits the device’s capabilities and performance best, leading to an reduced message description overhead as exemplary shown by the total message size of device 1 in the last row of figure 5: The message overhead is only 138 Bytes,

10

AIS Transactions on Enterprise Systems 1 (2009) Vol. 2

S. Zaplata et. al.: Realizing Mobile Web Services for Dynamic Applications

Device Number in scenario Device

1 Sun SPOT Wireless Sensor

2 Intel Pentium 4 Desktop PC 3,2 GHz 1 GB RAM Stationary service provider ASUS Eee PC 1000H Netbook 1,6 GHz 1 GB RAM

3

4 Nokia 6131 NFC Cell Phone 229 MHz 26 MB RAM Mobile service consumer

180 MHz Properties (Processor, RAM) 512 KB RAM Role Type Mobile service provider

Mobile service consumer and provider

Communication Protocol Header Size (Bytes) Messages for Service Discovery Message Exchange for Service Discovery Message Size (Bytes) Service Message Description Language

Overlay Network 86 (+20) Service Queries received Descriptions Service sent Queries (WSDL) received

HTTP 123 (+20)

HTTP 123 (+20)

TCP 20

Overlay Network 86 (+20)

HTTP 123 (+20)

TCP 20 Descriptions received (WSDL)

Descriptions Service sent Queries (WSDL) received

Descriptions Service sent Queries (WSDL) performed

Descriptions Service received Queries (WSDL) performed

1

1

1

1

1

1

max. 3

1

1

1

86

1547

86

1547

86

1547

max. 258

1547

86

1547

ASN.1 Response Request

SOAP Response Request

ASN.1 Response Request

SOAP Response Request

ASN.1 Response

Service Message Request Type Service Message Size (Bytes) Message Exchange for Service Execution Total Message Size for Service Execution (Bytes) 114 Received: 1

24 Sent: 1

914 Received: 1

758 Sent: 1

114 Sent: 1 Received: 1

24 Sent: 1 Received: 1

914 Sent: 1

758 Received: 1

114 Sent: 1

24 Received: 1

138

1672

1948

138

Figure 5: Overview of message exchange and size within the scenario request

which constitutes only 8.25 percent of the respective traditional technology (e.g. the message size of device 2: 1672 Bytes).

6.

Conclusion and Future Work

Due to the heterogeneity of current mobile systems, it seems that there is no generally applicable combination of web service technologies, but that the use of a specific approach is determined by the capabilities of the specific mobile device. For enabling also more complex and dynamic applications such as ad-hoc mobile business processes, this paper proposes a flexible mobile web service architecture which supports accessing the functionality of multiple heterogeneous devices. By use of a customized configuration of protocols and technologies, this architecture can be tailored according to the requirements of the respective (mobile) application and its users, allowing to preserve interoperability with industry standards while also respecting the restrictions of resource-limited devices. However, as also to see in figure 5, the exchange of WSDL descriptions takes a significant amount

of the overall data transfer. As recommended, a possible solution is to integrate alternative description languages, such as e.g. JSON which reduces the overhead of XML of about 20 percent. If this is still unsatisfying, the presented architecture could be enhanced to optionally provide compression mechanisms for service descriptions and service invocation messages. Furthermore, mobile service requesters capable of carrying multiple adapters may (in the worst case) produce unnecessary messages which could be inadequate for networks with a small bandwidth. This problem can be addressed by an increased network-awareness, enabling the mobile service requester to prioritize more lightweight protocols. Future work therefore involves the integration of context information to adapt not only to the capabilities of mobile devices but also to specific network characteristics.

Literature
[1] F. Adelstein, S. K. Gupta, G. Richard III, and L. Schwiebert. Fundamentals of Mobile and Pervasive Computing. McGraw-Hil, 2005.

1867-7134 © GITO mbH

11

S. Zaplata et. al.: Realizing Mobile Web Services for Dynamic Applications

[2]

[3]

[4] [5]

[6] [7] [8]

[9]

[10]

[11] [12] [13]

[14] [15] [16]

V. Auletta, C. Blundo, E. D. Cristofaro, and G. Raimato. A Lightweight Framework for Web Services Invocation over Bluetooth. In Proceedings of the IEEE Int. Conf. on Web Services (ICWS06), pages 331–338. IEEE Computer Society, 2006. S. Berger, S. McFaddin, C. Narayanaswami, and M. Raghunath. Web Services on Mobile Devices – Implementation and Experience. IEEE Workshop on Mobile Computing Systems and Applications, 0:100, 2003. D. Booth, H. Haas, F. McCabe, E. Newcomer, M. Champion, C. Ferris, and D. Orchard. Web Services Architecture. Technical report, W3C, 2004. C. Chong, H.-N. Chua, and C.-S. Lee. Towards flexible mobile payment via mediator-based service model. In Proceedings of the 8th Int. Conf. on Electronic Commerce (ICEC06), pages 295–301. ACM, 2006. D. Doval and D. O’Mahony. Overlay Networks: A Scalable Alternative for P2P. IEEE Internet Computing, 7(4):79–82, 2003. P. Farley and M. Capp. Mobile Web Services. BT Technology Journal, 23(3):202–213, 2005. G. Hackmann, M. Haitjema, C. D. Gill, and G.-C. Roman. Sliver: A BPEL Workflow Process Execution Engine for Mobile Devices. In Int. Conf. on ServiceOriented Computing (ICSOC 2006), volume 4294, pages 503–508. Springer, 2006. S. Helal, N. Desai, V. Verma, and C. Lee. Konark – A Service Discovery and Delivery Protocol for Adhoc Networks. volume 3, pages 2107–2113. IEEE Computer Society, 2003. ITU-T. ASN.1 Encoding Rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER). Technical report, International Telecommunication Union, 2002. ITU-T. ASN.1 Encoding Rules: Mapping W3C XML Schema Definitions into ASN.1. Technical report, International Telecommunication Union, 2004. ITU-T. Generic Applications of ASN.1: Fast Web Services. Technical report, International Telecommunication Union, 2004. C. P. Kunze, S. Zaplata, M. Turjalei, and W. Lamersdorf. Enabling Context-based Cooperation: A Generic Context Model and Management System. In Business Information Systems (BIS 2008). Springer, 2008. S. Oh. Web Service Architecture for Mobile Computing. PhD thesis, Indiana University, Indianapolis, USA, 2006. S. N. Srirama, M. Jarke, and W. Prinz. Mobile Web Service Provisioning. In Proceedings of the AICT and ICIW 2006, page 120. IEEE Computer Society, 2006. S. N. Srirama, M. Jarke, and W. Prinz. Mobile Web Services Mediation Framework. In Proceedings of the 2nd Workshop on Middleware for Service Oriented Computing (MW4SOC07), pages 6–11. ACM, 2007.

[17] M. Tian, T. Voigt, T. Naumowicz, H. Ritter, and J. Schiller. Performance Considerations for Mobile Web Services. Elsevier Computer Communications Journal, 27:1097–1105, 2004. [18] C. Werner, C. Buschmann, and T. Jacker. Enhanced Transport Bindings for Efficient SOAP Messaging. In Proceedings of the IEEE Int. Conf. on Web Services (ICWS05), pages 193–200. IEEE Computer Society, 2005.

Dipl.-Inf. Sonja Zaplata Distributed Systems and Information Systems Computer Science Department, University of Hamburg Vogt-Kölln-Str. 30, 22527 Hamburg, Germany E-Mail: zaplata@informatik.uni-hamburg.de Phone: +494042883-2327 Sonja Zaplata studied Business Administration and Informatics. Currently, she is a Ph.D. candidate and works as a research assistant in the Computer Science Department at the University of Hamburg. B.Sc.-Inf. Viktor Dreiling Distributed Systems and Information Systems Computer Science Department, University of Hamburg Vogt-Kölln-Str. 30, 22527 Hamburg, Germany E-Mail: 5dreilin@informatik.uni-hamburg.de Phone: +494042883-2339 Viktor Dreiling studied Informatics and is currently working on his Master‘s degree at the University of Hamburg. His research and development activities focus on distributed and database systems. Prof. Dr. Winfried Lamersdorf Distributed Systems and Information Systems Computer Science Department, University of Hamburg Vogt-Kölln-Str. 30, 22527 Hamburg, Germany E-Mail: lamersdorf@informatik.uni-hamburg.de Phone: +494042883-2421 After some years of research in IBM, Winfried Lamersdorf is Professor at Hamburg University and responsible for distributed systems. He is also co-chair of IFIP WG 6.11 and co-founder of the I3E conference series.

12

AIS Transactions on Enterprise Systems 1 (2009) Vol. 2

I. M. Lazarte et Available online atCollaborative Process Models into Interface Process Models al.: Transforming www.enterprise-systems.net

AIS Transactions on Enterprise Systems 1 (2009) 2, 13-23

Transforming Collaborative Process Models into Interface Process Models by Applying an MDA Approach
Ivanna M. Lazarte, Omar Chiotti and Pablo D. Villarreal
Abstract
Collaborative business models among enterprises require defining collaborative business processes. Enterprises implement B2B collaborations to execute these processes. In B2B collaborations the integration and interoperability of processes and systems of the enterprises are required to support the execution of collaborative processes. From a collaborative process model, which describes the global view of the enterprise interactions, each enterprise must define the interface process that represents the role it performs in the collaborative process in order to implement the process in a Business Process Management System. Hence, in this work we propose a method for the automatic generation of the interface process model of each enterprise from a collaborative process model. This method is based on a ModelDriven Architecture to transform collaborative process models into interface process models. By applying this method, interface processes are guaranteed to be interoperable and defined according to a collaborative process. with their business partners to improve their performance and competitiveness [10]. Collaborative models can be realized by implementing Businessto-Business collaborations that entail a processoriented integration among heterogeneous and autonomous enterprises. This integration must be achieved at a business level and at a technological level [13]. At the business level, enterprises focus on the design of collaborative processes to define and agree on the behavior of the inter-enterprise collaboration. A collaborative business process defines the global view of the interactions among enterprises to achieve common business goals [1], [13]. At the technological level, enterprises focus on the integration and interoperability of their B2B systems to execute collaborative processes. This implies the generation of B2B specifications, i.e. interfaces of the partners’ systems and business process specifications required by each enterprise to execute the role performed in a collaborative process and implement it in a business process management system (BPMS). The design and management of collaborative processes at both levels implies new challenges, mainly the fulfillment of several requirements [1], [13], [15]: • Autonomy: enterprises behave as autonomous entities, hiding their internal decisions, activities and processes. Information systems, that manage

1.

Introduction

Enterprises are applying collaborative business models for managing inter-enterprise collaboration

1867-7134 © GITO mbH

13

I. M. Lazarte et al.: Transforming Collaborative Process Models into Interface Process Models

B2B collaborations in each enterprise, have to be independent. • Decentralized management of collaborative processes jointly managed by the enterprises. • Peer-to-Peer interactions: the information systems of enterprises interact in a direct way without the mediation of a third party. • Negotiation: it is required in the management of collaborative processes. • Alignment between the business solution and the technological solution in order to guarantee that the technological solution provides a full support to the behavior agreed in the collaborative processes. To fulfill the above issues, we have proposed an MDA-based method for the design, verification, and implementation of collaborative processes [9], [14]. In this method, collaborative processes are modeled with the UML Profile for Collaborative Business Processes based on Interaction Protocols (UP-ColBPIP) language [9], [14] from which business process specifications can be generated in technology languages such as BPEL [12] and WSCDL [13]. This method was selected as one of the more comprehensive and completes among several UML-based design methods for collaborative processes [3]. B2B collaborations also require the definition of interface and integration processes that each enterprise has to implement to execute collaborative processes. An interface process defines the public behavior of the role an enterprise performs in a collaborative process. An integration process, which is derived from an interface process, adds the private logic of the enterprise required to support the role it performs in a collaborative process. The understanding of an interface process by business analysts, at a higher abstraction level, requires the use of process models defined with a high-level modeling language. Furthermore, interface processes must be aligned with the behavior defined in collaborative processes, and hence, they have to be correctly defined in order to guarantee their interoperability and support to the logic of collaborative processes. To this aim, in this work we propose an MDAbased method for the automatic generation of the interface process model of each enterprise, from a collaborative process model, by applying transformations of business process models. We propose the use of the UP-ColBPIP language (UML Profile for Collaborative Business Processes based on Interaction Protocols) [9],[14] for modeling collaborative processes and the use of the BPMN

standard language (Business Process Modeling Notation) [6] for modeling interface processes. This paper is organized as follows. Section 2 describes the development process of a B2B collaboration. Section 3 describes the MDA-based method to generate interface process models from a collaborative process model. Section 4 presents an application example of this method. Section 5 discusses related works, and Section 6 presents conclusions and future work.

2.

Development of a B2B Collaboration

A B2B collaboration requires the definition of a business solution as well as a technological solution, because of it involves the enterprise integration at the business and the technological level. Furthermore, two views inside the business and technological solutions have to be considered (Figure 1): the collaboration view, which refers to the global and public requirements agreed by business partners; and the partner’s view, which refers to the particular requirements that a partner has to meet to be able to collaborate with other partners. At the business level, the collaborative view is represented by the collaborative processes that define the inter-enterprise collaboration behavior. A collaborative business process defines the message exchange among partners from a global viewpoint [1], [14], [15]. Once partners agree on the collaboration view, they define their business requirements in their partner’s view. The role a partner performs in a collaborative process is depicted in an interface business process [15] (also called abstract process [5], [6] or behavioral interface [15]). An interface process defines the public and external visible behavior of a partner in terms of the activities that support the receiving and sending of messages with their partners, i.e. the activities that communicate with other external business processes o roles. This public behavior can be derived from collaborative processes (see section 3). Finally, from interface processes, partners define their integration business processes (also called private [6], executable [1], [5] or orchestration processes [15]). An integration process adds the internal business logic required to support the role a partner performs in a collaborative process. The internal business logic includes the activities for producing and processing the exchanged information as well as data transformations and invocations to internal systems. Although collaborative and interface processes define how partners will coordinate their actions, these

14

AIS Transactions on Enterprise Systems 1 (2009) Vol. 2

I. M. Lazarte et al.: Transforming Collaborative Process Models into Interface Process Models

Figure 1. Business Processes involved in the development of a B2B collaboration.

processes are not executable. At the technological level, partners have to generate the interfaces of their B2B systems and the executable specifications of integration processes by using a standard B2B process language. Then, these specifications can be interpreted by the partners’ BPMSs to execute collaborative processes (see Figure 1). To develop B2B collaborations, we have proposed a methodological guide [11] for the modeling and implementation of the above types of business processes as well as a systematic approach to transform conceptual models of collaborative processes into concrete models and specifications of business processes. Our approach involves the following stages: 1. Analysis and Design of Collaborative Processes from a business viewpoint to represent the B2B collaboration view, i.e.: definition of business requirements and common business goals of the B2B collaboration along with the design of collaborative processes. 2. Derivation of Interface Processes from collaborative processes in order to define the public view of each partner. 3. Design of Integration Processes by incorporating the private logic required to support the message exchange with the other partners in order to define the private view of each partner. 4. Generation of the Technological Solution from the business process models of the business solution, i.e. the artifacts required to execute collaborative processes: interfaces of the partners’ systems and process specifications based on a B2B standard. To cope with these issues, we propose the application of the principles of the model-driven development (MDD) and the model-driven architecture (MDA) [7]

to provide a methodological guide for the design and implementation of the business processes required in the development of B2B collaborations. In the MDA, the development process is accomplished through a pattern of transformations that consists of: defining platform-independent models (PIMs), selecting platform-specific models (PSMs) and executing transformations that generate PSMs from PIMs, and finally generating codes by executing transformations of PSMs into Code. A platform refers to the implementation technology. By applying an MDA approach, enterprises can build and transform business process models to generate the code of B2B specifications. The MDA principles have been exploited in the domain of collaborative processes [9]. An MDA-based approach was proposed to support the conceptual modeling of collaborative processes and the automatic generation of process specifications and partners’ system interfaces based on a B2B standard [12], [13], [14]. An MDA-based approach [8] was also proposed to generate formal specifications of collaborative processes and verify if they are well-formed. In this work we provide a method for the second stage of the development process of B2B collaborations, which is described below.

3.

An MDA-based Method for Generating Interface Process Models

In this section we propose a method for enabling partners to define an interface process interoperable with the interface processes of their partners and consistent with the global view agreed in a collaborative process. This method is based on a model-driven architecture to enable the automatic generation of partners’ interface process models from collaborative process models. In this method, we propose the use of the UP-ColBPIP language [9], [14] to represent collaborative process models and the BPMN language [6] to represent interface process models. The UP-ColBPIP language provides suitable abstractions to support the particular features of B2B collaborations and model technologyindependent collaborative processes. This language encourages the use of interaction protocols to represent the behavior of collaborative processes. An interaction protocol describes a high-level communication pattern through a choreography of business messages between partners playing different roles. The modeling of interaction protocols focuses on representing the public global control flow of

1867-7134 © GITO mbH

15

I. M. Lazarte et al.: Transforming Collaborative Process Models into Interface Process Models

Figure 2. MDA-based method to transform a collaborative process into interface processes.

interactions between partners, as well as on the responsibilities of the roles they fulfill, maintaining the partners’ internal logic hidden. This is the main difference with respect to activity-oriented business process languages such as UML2 Activity Diagrams or BPMN [6], which are more suitable to describe interface or private processes from a partner’s viewpoint. Although BPMN allows the definition of B2B processes by representing the message exchange among pools (partners), it does not provide semantics to define the control flow of the global message exchange. In addition, coordination and communication aspects of B2B interactions are represented in interaction protocols through the use of speech acts. In an interaction protocol, a business message has an associated speech act, which represents the intention the sender has with respect to the business document exchanged in the message. Thus, the partners’ decisions and commitments can be known from the speech acts. This enables the definition of complex negotiations and avoids the ambiguity in the meaning of the business messages of collaborative processes. BPMN is applied due to the fact that it is a suitable activity-oriented modeling language to represent technology-independent business processes from a partner’s viewpoint. BPMN incorporates the concept of interface process through what it calls abstract process, and thus, it allows the representation of the public behavior of the role a partner performs in a collaborative process. Also, BPMN provides suitable concepts to represent the private logic that has to be incorporated into interface processes to define integration processes. In this way, the proposed MDA-based method focuses on horizontal transformations among business process models defined with

these languages (see Figure 2). The method takes as input a UP-ColBPIP model, containing collaborative processes, represented as interaction protocols. For a selected interaction protocol, a transformation process generates as output BPMN Business Process Diagrams (BPD) corresponding to the partners’ interface processes, one BPD for each partner involved in the protocol. In section 4 an example of this transformation process is described. To carry out the transformation of a UPColBPIP interaction protocol into BPMN BPDs, we propose a set of predefined BPMN patterns for each conceptual element of an interaction protocol. Thus, the semantics of each protocol element is represented in terms of the elements and semantics provided by BPMN from one partner’s viewpoint. The model transformation process consists of analyzing each element of a protocol from a partner’s viewpoint and generating the corresponding elements in BPMN by applying transformation rules that use predefined BPMN patterns as the output pattern of the rules. In Section 3.1 we briefly describe the concepts of the UP-ColBPIP language that are relevant to this work. More details can be found in [9], [13], [14]. In Section 3.2 we describe the MDA-based model transformation process. 3.1. The UP-ColBPIP Modeling Language A UP-ColBPIP model is expressed by four views: the B2B Collaboration View, the Collaborative Process View, the Interaction Protocol View, and the Business Interface View. From the Interaction Protocol View, interface process models can be generated. UPColBPIP extends the semantics of UML2 Interactions to model interaction protocols in UML2 Sequence

16

AIS Transactions on Enterprise Systems 1 (2009) Vol. 2

I. M. Lazarte et al.: Transforming Collaborative Process Models into Interface Process Models

Diagrams. The conceptual elements used to define interaction protocols are: • Partners and the Role they fulfill are represented through lifelines. • Business Message defines an interaction between two roles. It contains a business document, and its semantics is defined by its associated speech act, which represents the sender’s intention with respect to the exchanged business document. It also indicates that the sender’s expectation is that the receptor acts according to the semantics of the speech act. • Control Flow Segment (CFS) represents complex message sequences. It contains a control flow operator and one or more interaction paths. An interaction path can contain any protocol elements: messages, termination events, protocol references and nested control flow segments. The semantics of a CFS depends on the operator that it used. The And operator represents the execution of parallel interaction paths. The Xor operator represents that only one path can be executed from a set of alternative paths. A databased Xor contains conditions on the paths to select the execution path. An event-based Xor is based on the occurrence of the sending and reception events of a message. The Or operator represents that two or more alternative paths can be executed in case their condition is evaluated to true. The If operator represents a path that is executed when its condition is true. If it is not so, nothing is executed. If it has an else path, it is executed when the condition is false. The Loop operator represents that a path can be executed while its condition is satisfied. A loop “Until” with the condition “(1,N)” means that its path must be executed at least once; a loop “While” with the condition “(0,N)” means that its path can be executed zero or N times. The Exception operator defines the path to be followed after an exception takes place, which is identified at design time. This CFS consists of one path that encloses the scope of the exceptions (for all protocol element involved in the path) and other exception handler paths, one for each exception to be caught and managed. An exception handler path has an exception condition to determine when the exception is raised. After an exception handler path is completed, the protocol continues with its normal execution. Two types of exception can be managed: time and logical. The Cancel operator defines the path to be followed after an exception takes place. The difference between Cancel and Exception operators is that the

Figure 3. Collaborative Demand Forecast protocol.

former finalizes the execution of the protocol when the path that handles the exception is completed. This CFS is used to finalize a protocol in a coherent and consistent way after an exception. • Protocol Reference represents a sub-protocol or nested protocol. When the sub-protocol is called, the protocol waits until the sub-protocol ends. • Termination event represents an explicit end of a protocol. Termination events are: success, which implies the successful termination; and failure, which implies that the protocol’s business logic ends in an unexpected way. • Time Constraint denotes a duration or deadline that can be associated with: messages, control flow segments or protocols. It represents the available time limit for the execution of such element. Figure 3 shows the sequence diagram of the Collaborative Demand Forecast protocol, which describes a collaborative process executed as part of a Vendor-Managed Inventory collaborative model. This protocol represents a simple negotiation process between a customer and a supplier to determine a demand forecast. The process begins with the customer, which requests a demand forecast. The generated request message conveyed the data to be considered in the forecasting (e.g.: products, time-frame). The supplier processes the request and may respond by accepting or rejecting it. If it is accepted, the supplier undertakes to realize the required forecast; otherwise, the process finishes with a failure. If the supplier

1867-7134 © GITO mbH

17

I. M. Lazarte et al.: Transforming Collaborative Process Models into Interface Process Models

accepts the request, the customer informs, in parallel, a sales forecast of its points of sales (POS) and its planned sales policies. With this information, the supplier generates a demand forecast and sends it to the customer. Then, the process ends. 3.2. Transformation of a UP-ColBPIP Interaction Protocol into BPMN Business Process Diagrams The transformation process of a UP-ColBPIP interaction protocol into BPMN BPDs of the partners’ interface processes consists of: 1. The lifeline of each role of the protocol is analyzed and a BPMN BPD is generated, which represents the interface process of the partner that performs such role in the protocol. 2. The BPD is built through the composition of the predefined BPMN patterns by applying the model transformation rules. 3. For each element of a protocol there is a rule that transforms such element into the corresponding BPMN element/s in a BPD. 4. The BPDs of the interface processes and their embedded sub-processes begin with a start event type none, except if the role of the interface process receives the first message (see rule msgrcv). 5. An end event type none models the implicit termination of a protocol. 6. Reusable and reference sub-processes are modeled in a collapsed form. 7. Embedded sub-processes are modeled in an expanded form. They finish with an end event type none for each end sequence flow except for an explicit termination (see rule end). Table 1 shows the transformation rules with their BPMN output patterns for each protocol element according to the partner’s role in the protocol: • Rule msgrcv (Table 1.a): for each business message received by the role being considered in the transformation, an intermediate event type message is added, except if the message is the first element of the protocol. In this case, the process begins with a start event type message. The intermediate or start event is labeled according to the speech act and business document defined for the message and has an associated data object, which represents the business document involved in the message. • Rule msgsnd (Table 1.a): for each business message sent by the role being considered, a send task is added, which is labeled according to the speech act and business document

• •

•

•

•

defined in the message and has an associated data object, which represents such business document. Rule ref (Table 1.b): for each reference protocol, a reusable sub-process is created to refer to a process defined in another BPD. The Table 1. Transformation rules of the main elements of an interaction protocolname of the sub-process is the same as the protocol it refers to. Rule end: for each termination event in a protocol, an end event type terminate labeled Success or Failure is added to the BPD. If this event is in an embedded sub-process, it is modeled by an end event type signal. Then, an intermediate event type signal is attached to the sub-process to catch the signal. The outgoing sequence flow of this event is connected to an end event type terminate. This ensures that the protocol execution ends when the sub-process returns the control to the main process. Rule timeconst: a time constraint is modeled according to the type of protocol element to which it is attached. (1) If it is a protocol or a CFS, it is mapped into an embedded subprocess with an attached intermediate event type timer. (2) If it is a message sent by the role or a reference protocol, an intermediate event type timer is attached to the send task or reusable sub-process, respectively. (3) If it is a message received by the role, two mappings are possible. If it is the first received message in a CFS with an Xor or If operator, another gate is added to the exclusive gateway representing the CFS. This gate is connected to an intermediate event type timer indicating the time constraint, unless there is another timer with the same value, in which case the existing one is used. Otherwise, an event-based exclusive gateway with two gates is defined, one for the message and another one with an intermediate event type timer to represent the time constraint. In all cases, if the protocol has a CFS with the Cancel operator (see Rule cancel), which handles time exceptions; the outgoing sequence flow of an intermediate event type timer is connected to the sub-process that handles the exception. If the protocol does not have a CFS with the Cancel operator, it is connected to an end event type error. Rule and (Table 1.c): a CFS with the And operator is mapped into a parallel gateway with a gate for each interaction path. If two or more paths do not have an explicit termination, a

18

AIS Transactions on Enterprise Systems 1 (2009) Vol. 2

I. M. Lazarte et al.: Transforming Collaborative Process Models into Interface Process Models

Input patterns (UP-ColBPIP)

Output patterns (BPMN) Role A Role B

a Business Message Pattern of Rule msgsnd

Pattern of Rule msgrcv

b Protocol Reference

Business Document SpeechAct BusinessDocument

c

CFS with the And operator

SpeechAct BusinessDocument

Business Document

d

CFS with the Xor operator

e

CFS with the Or operator

f

Table 1. Transformation rules of the main elements of an interaction protocol

CFS with the Exception operator

Pattern of Rule except for exceptions related to the protocol logic

1867-7134 © GITO mbH

19

I. M. Lazarte et al.: Transforming Collaborative Process Models into Interface Process Models

•

•

•

•

•

joining parallel gateway is added to synchronize them. Rule xor (Table 1.d): A CFS with the Xor operator (either data-based or event-based) is mapped into an event-based exclusive gateway if the role receives messages, or it is mapped into a data-based exclusive gateway if the role sends the messages in the interaction paths. One gate per interaction path is added. If two or more paths do not have an explicit termination event, a merging exclusive gateway is added. Rule or (Table 1.e): a CFS with the Or operator is mapped into an inclusive gateway with a gate for each interaction path. If two or more paths do not have an explicit termination event, a joining inclusive gateway is added to synchronize them. Rule if: a CFS with the If operator is mapped into an event-based exclusive gateway if the role receives messages or is mapped into a data-based exclusive gateway if the role sends messages. The gateway has two gates, one for the condition to be satisfied and another one for the else condition. The second gate is generated if the else condition is defined. If it is not, an intermediate event type message is added if the role receives messages, or a send task is added if the role sends messages to indicate that the execution of the protocol should proceed. If two interaction paths do not have an explicit termination event, the gates are joined by a merging exclusive gateway. Rule loop: for each CFS with the Loop operator, an embedded sub-process with a Loop Marker is created. The transformation depends on the Loop type. (1) For a “while loop” whose condition is [(0,N), Var1=True], the attribute LoopCondition of the embedded sub-process var1=True and the attribute TestTime with the value Before are settled. (2) For a “repeat until loop” whose condition is [(1, N), Var1=True], the attribute LoopCondition with the value not var1 and the attribute TestTime with the value After are settled. Rule except (Table 1.f): a CFS with the Exception operator is mapped into an embedded sub-process with an attached intermediate event type conditional, for exceptions related to the protocol logic, or type timer, for time constraint. The outgoing sequence flow of this event is connected to a sub-process that handles the exception. Both sub-processes are synchronized by a merging exclusive gateway to let the execution continue.

• Rule cancel: a CFS with the Cancel operator is mapped into an embedded sub-process. This sub-process is triggered by an intermediate event type timer, if the interaction path of the CFS handles a time constraint, or by an intermediate event type conditional for exceptions related to the protocol logic. The outgoing sequence flow of this sub-process is connected to an end event type terminate.

4.

Application of the MDA-based Method to an Example

The Collaborative Demand Forecast interaction protocol described in section 3 is used for exemplifying the model transformation process aforementioned. From this protocol, the supplier’s interface process (section 4.1) and the customer’s interface process (section 4.2) are generated. These processes are required in order to implement the collaborative process defined by the interaction protocol. 4.1. Generation of the Supplier’s Interface Process The BPMN BPD representing the generated supplier’s interface process is shown in Figure 4. In the transformation process all protocol elements are analyzed from a supplier’s viewpoint. The first protocol element is the request(ForecastRequest) business message, which is received by the supplier. This message is transformed using the rule msgrcv, which consists of creating a start event type message. This event is labeled Request ForecastRequest and is associated with the ForecastRequest data object, which represents the business document interchanged between enterprises. Then, the CFS with the Xor operator is transformed by applying the rule xor. This rule adds a data-based exclusive gateway with two gates, one for each interaction path. Then, each path is analyzed to determine the pattern to be used in the transformation. The first element of the first path is the agree(ForecastRequestResponse) business message, which is sent to the customer. The message is transformed by the rule msgsnd that generates a send task. This task is labeled Agree ForecastRequestResponse and is associated with the ForecastRequestResponse data object, which represents the exchanged business document. There are no further elements in this path so the other path is analyzed. The first element of the second path is the refuse(ForecastRequestResponse) business message. This message is transformed by the rule

20

AIS Transactions on Enterprise Systems 1 (2009) Vol. 2

I. M. Lazarte et al.: Transforming Collaborative Process Models into Interface Process Models

Figure 4. BPMN Business Process Diagram of the Supplier’s interface process

msgsnd that generates a send task. The next element is a termination event, which is transformed by the rule end. Because one path has an explicit termination, the two gates are not synchronized and the transformation continues along the path which does not have the explicit termination. The next protocol element is the CFS with the And operator that is transformed by the rule and. This rule adds a parallel gateway with two gates, one for each interaction path. The first path is analyzed and its single element is the inform(POSForecast) business message, which is received by the supplier. This message is transformed by applying the rule msgrcv. The second path has one element that is the inform(PlannedEvents)business message. This message is also transformed using the rule msgrcv. Both path are synchronized by another parallel gateway (see rule and) because neither of them has an explicit termination. After the CFS, the inform(DemandForecast) business message is sent by the supplier to inform

the generated demand forecast. This message is transformed by applying the rule msgsnd. Then, the protocol ends with an implicit termination, which is modeled with an end event type none. 4.2. Generation of the Customer’s Interface Process The generation of the BPD representing the customer’s interface process is carried out in a similar way to the generation of the BDP of the supplier’s interface process. The generated BPD of the customer’s interface process is shown in Figure 5.

5.

Related Works

There are several approaches that exploit the benefits of model-driven architectures for B2B processes [3]. A method for modeling crossorganizational processes based on the MDA was proposed [1], which supports the mapping of ARIS

Figure 5. BPMN Business Process Diagram of the Customer’s interface process

1867-7134 © GITO mbH

21

I. M. Lazarte et al.: Transforming Collaborative Process Models into Interface Process Models

models of cross-organizational value chains into BPDM models of abstract (interface) processes. These processes are defined in UML2 activity diagrams. However, the proposed architecture uses a centralized broker to implement and govern B2B interactions. It is different from our approach that encourages the decentralized management of collaborative processes. Another MDA-based method was proposed to generate BPEL abstract (interface) processes from UP-ColBPIP interaction protocols [12]. Although this method allows generating BPEL specifications, the addition of private logic to BPEL processes has to be done at a technological level. Instead, in this work we provide an approach to elevate the abstraction level of interface processes so that business analysts can use them to generate integration processes. Then, BPEL specifications can be generated from these models. Also, an approach was proposed to derive local choreographies (interface processes) from UMM global choreographies to register them in a global repository [4]. A UML Profile is proposed to represent local choreographies. It is not based on a model-driven approach. In addition, in this work we use the BPMN standard language so that enterprises can understand and define interface processes, instead of using a particular language. Another approach is for checking consistency of predefined interface processes [2]. It is a useful method for bottom-up approaches to determine if these processes are interoperable for building a B2B scenario. Instead, our method promotes a topdown approach. Enterprises agree on an interaction global view and the behavioral constraints of each participant are guaranteed by deriving interface processes from a global interaction model.

collaborative processes. The use of interaction protocols supports the main features of B2B collaborations: global view of the B2B interactions, enterprise autonomy, decentralized management, peer-to-peer interactions and negotiations. In addition, this method increases the abstraction level in the design of the partners’ view of a B2B collaboration. The BPMN standard language is used to define activity-oriented interface process models. This enables enterprises to understand and focus on the business requirements to fulfill the role they perform in collaborative processes. Also, it is pretended to integrate this method to the previously proposed MDA-based method for collaborative processes [9], [11], [14], in order to provide a complete methodology that supports the modeling, verification and specification of the business processes required in B2B collaborations. Finally, the proposed MDA-based transformation process shows that a direct mapping can be applied to derive BPMN BPDs of interface processes from an interaction protocol. No intervention is required by a modeler. For each element of the UP-ColBPIP language used to describe interaction protocols, a BPMN pattern is proposed to represent its behavior from the viewpoint of the role a partner performs in the protocol. Future work will define the transformation rules in ATL languages and implement these process model transformations in an Eclipse-based tool developed for the modeling and verification of collaborative processes [8], in order to provide an automated support for applying the proposed method. Another work is about the definition of integration processes from interface processes by adding private activity patterns to process or generate the information exchanged between the partners.

6.

Conclusions and Future Work

7.
[1]

Bibliographical References
Bauer, B., Roser, S., Müller, J. (2005). Adaptive Design of Cross-organizational Business Processes using a Model-driven Architecture. In Wirtschaftsinformatik 2005. Germany: Physica-Verlag. pp. 103-121. Decker, G., Weske, M. (2007). Behavioral Consistency for B2B Process Integration. Advanced Information Systems Engineering (CAiSE 2007), LNCS, Vol. 4495, pp. 81-95. Folmer, E., Bastiaans, J. (2008). Methods for Design of Semantic Message-Based B2B Interactions Standards. In Enterprise Interoperability III. London: Springer-Verlag. pp.183-194. Hofreiter, B. (2008). Registering UML Models for Global and Local Choreographies. 10th International

In this work we have proposed an MDA-based method for the automatic generation of the interface process model of each enterprise from a collaborative process model. This method enables enterprises to generate interoperable interface processes and in compliance with the global logic of B2B interactions agreed on collaborative processes. This is guaranteed since the partners’ interface process models are derived from a collaborative process model by applying a top-down MDA-based approach. The language UP-ColBPIP is used to define the B2B collaboration view among the partners. It encourages the modeling of interaction protocols to represent the behavior of technology-independent

[2]

[3]

[4]

22

AIS Transactions on Enterprise Systems 1 (2009) Vol. 2

I. M. Lazarte et al.: Transforming Collaborative Process Models into Interface Process Models

[5]

[6] [7] [8]

[9] [10]

[11]

[12]

[13]

[14]

[15]

Conference on Electronic Commerce, ACM, Vol. 342, Art. No. 37. OASIS, Web Services Business Process Execution Language. Available: http://www.oasis-open.org/ committees/download.php/23964/wsbpel-v2.0-primer. htm. Last accessed: May 2007. OMG. BPMN V1.1. Available: http://www.omg.org/ spec/BPMN/1.1/PDF. Last accessed: June 2009. OMG. MDA Guide V1.0.1. Available: http://www. omg.org/mda. Last accessed: June 2009. Roa, J., Castañeda, V., Villarreal, P., Chiotti, O. (2008). A Tool for Model-Driven Development of Collaborative Business Processes. XXXIV LatinAmerican Conference on Informatics (CLEI 2008). Santa Fe, Argentina. Villarreal, P. (2005). Method for the Modeling and Specification of Collaborative Business Processes, Ph.D. dissertation. Santa Fe, Argentina: Ceride Press. Villarreal, P., Caliusco, M., Zucchini, D., Arredondo, F., Zanel, C., Galli, M.R., Chiotti, O. (2003). Integrated Production Planning and Control in a Collaborative Partner-to-Partner Relationship. In Managing E-Business in the 21st Century. Australia: Heidelberg. pp. 91-110. Villarreal, P., Roa, J., Chiotti, O., Salomone, E. (2007). Aligning the Business Solution with the Technological Solution in the Development of B2B Collaborations. CollECTeR Iberoamérica 2007. Argentina. Villarreal, P., Salomone, E., Chiotti, O. (2006). MDA Approach for Collaborative Business Processes: Generating Technological Solutions based on Web Services Composition. 9th Ibero-American Workshop IDEAS. Argentina Villarreal, P., Salomone, E., Chiotti, O. (2006). Transforming Collaborative Business Process Models into Web Services Choreography Specifications. Data Engineering Issues in E-Commerce and Services: Second International Workshop (DEECS 2006), LNCS, Vol. 4055, pp. 50-65. Villarreal, P., Salomone, E., Chiotti, O. (2007). Modeling and Specifications of Collaborative Business Processes using a MDA Approach and a UML Profile. In Enterprise Modeling and Computing with UML. USA: Idea Group Inc. pp 13-45 Weske, M. (2007). Business Process Management. Concepts, Languages, Architectures. Heidelberg: Springer.

Phone: +54-342-4601579/2390 (Int: 258 - Int: 104) Ivanna Lazarte is a PhD student in Information System Engineering at UTN. She has been working in the CIDISI since 2008. Her current research interest includes business process management systems, software engineering, model-driven development, service-oriented architectures. Omar Chiotti INGAR, National Council of Scientific Research (CONICET - UTN), Santa Fe, Argentina, E-Mail chiotti@santafe-conicet.gov.ar Phone: +54-342-4534451/4535568 (Int: 3007) Omar Chiotti received a PhD from Universidad Nacional del Litoral (UNL) in 1989. He has been working for the Argentina’s CONICET as a researcher since 1991. He is a Professor of Information Systems Engineering at UTN since 1986. Currently, he is the director of CIDISI, Research Center in Information System Engineering. His current research interest includes e-collaboration, knowledge management and multi-agent systems. Pablo D. Villarreal Research Center in Information System Engineering (CIDISI), National Technological University (UTN), Santa Fe, Argentina, E-Mail: pvillarr@frsf.utn.edu.ar Phone: +54-342-4601579/2390 (Int: 258 - Int: 102) Pablo Villarreal holds a Bachelor degree and a PhD degree in Information System Engineering from the UTN. He is an Assistant Professor at the UTN and a Researcher at the CONICET. He works at the CIDISI since 2000. His current research interest includes B2B systems, esupply chain management, business process management, service oriented architectures, model-driven development and multi-agent systems.

Ivanna Lazarte Research Center in Information System Engineering (CIDISI), National Technological University (UTN), Santa Fe, Argentina, E-Mail: ilazarte@frsf.utn.edu.ar

1867-7134 © GITO mbH

23

N. Biri et al.: Smooth integration of Existing applications in an SOA Available online at www.enterprise-systems.net

AIS Transactions on Enterprise Systems 1 (2009) 2, 24-31

Smooth integration of Existing applications in an SOA
Nicolas Biri, Pascal Bauler and Fernand Feltz
Abstract
Service oriented architecture is an approach that proposes to build an IT environment where applications are aligned with business requirements and exposed as a set of self-contained services with well-defined interfaces. It is often seen as the main solution to achieve a reactive and flexible IT environment. Considering this definition, a migration of an existing IT environment with legacy applications to an SOA should require a re-alignment of existing services and the definition of more appropriate services. This alignment is conditioned by external constraints, such as business constraints, that could impact the migration roadmap. In this article, we describe an approach that facilitates the integration of the existing applications into an SOA. The central elements that compose the SOA solution are described, as well as the framework that facilitates the integration of existing applications into this architecture. The way to deal with the future re-alignment of the services with the help of the proposed architecture is also described. loose coupling of the existing services. They ensure the standardization of message, the resolution of services or the reaction to fault tolerance, for example. However, technological choices are not sufficient to achieve the goals of SOA. The alignment of services with business requirements is not related to the technological choices and badly designed services can be chained together. The definition of the services, their design and their modelling is a crucial part of the design of a SOA that are more related to methodologies and creation processes than to technical choices. This latter part must also deal with external constraints that are often underestimated in academic studies. The integration of existing applications, often described as enterprise application integration (EAI), is one of the most common ones in practical cases. Most of the time, the initial landscape contains at least one business application that cannot be changed during the migration, either to reduce cost or to save time. The first implementation of the SOA is consequently slightly different from the ideal one. The gap between this concrete implementation and the idealistic one should be filled by an evolution of the existing services. Consequently, the migration of the legacy applications can be seen as the first test of the agility of an SOA. In this context, this paper presents a SOA platform used on a real project. The platform put the focus on the integration of legacy applications. The main contribution of this paper is a description of the framework used to wrap legacy applications to expose themselves as services and the methodology used to facilitate the replacement of these applications by more adequate services. Section 2 summarizes the different view of

1.

Introduction

Service Oriented Architecture relies on the design and the implementation of loosely coupled services. Its main objectives are to achieve an agile environment that reduces costs of integration of new services and of evolution of existing ones, to align the services to the business requirements and to facilitate reusability of existing services. A large part of the work on SOA is dedicated to technology. In fact technologies and standards have a crucial role in the success of a SOA solution. Most of the technological choices aim at ensuring the

24

AIS Transactions on Enterprise Systems 1 (2009) Vol. 2

N. Biri et al.: Smooth integration of Existing applications in an SOA

enterprise application integration as far as the service-oriented architecture is concerned. It also gives an overview of the methodologies for a SOA migration that are related to the one we proposed in this article. Section 3 described the proposed methodology, SOA-MF. This methodology can be seen as a modification of the SOAF methodology proposed in [1] that integrates the external constraints that impact the evolution of existing services. The description focuses on the handling of the migration issues, explaining how the notion of migration milestone is introduced and integrated within the methodology. Section 4 describes the technological and architectural issues introduced by a migration and emphasized by the introduction of the migration milestones. It presents a general architecture we have set in place to cope with these issues and briefly explain how it can help to overcome the migration issue. In section 5 we briefly described a practical case study and explain with two examples how the methodology can be applied to a real world example and how the proposed architecture helps handling the migration. Finally, section 6 concludes the paper and gives and provides some directions for future works.

2.

Related works

Structure your text by using numbered headings and subheadings as demonstrated in this chapter. 2.1. Service development lifecycle There are many researches from academics and industries to provide a methodology for a migration to a SOA, an overview of the main discussed solution is given in [2]. We detailed here some of those works to expose the motivation of the approach proposed in this paper. A classical approach in the domain is the one proposed in [3], which provide a global methodology for the design of the set of services and their development. Here, as often, the priority is to maximize cohesion and minimize coupling between the services. The methodology proposes a “web services development life cycle hierarchy” containing operational systems such as enterprise applications and database at the bottom of this hierarchy. The idea is to build enterprise components among these applications to provide services. The methodology advices to take into account several scenarios: “the analysis phase is based on a thorough business

case analysis that considers various alternatives for implementing business processes, e.g., by wrapping enterprise systems or acquiring new services”. It also includes a “gap analysis” phase, to determine a strategy to move from an abstract definition of service to a concrete one, this phase can either leads to new development, refactoring of existing applications or modifications of expected services to minimize development effort. The same distinction between operational systems and enterprise components is made in SOMA, a methodology proposed by IBM [4]. Here, the limitation of enterprise components due to the underlying systems is neglected. SOAF, a methodology proposed in [1] try to provide a more detailed methodology to design services. The methodology include an “as-is” and a “to-be” business process modelling, which give an overview of the current situation and of the target situation. During the realization phase, an “invasive transformation phase” is mentioned to integrate the existing applications that cannot directly be integrated to the architecture. The methodology mentioned an “iterative process that involves refactoring, consolidation, componentization and redesigning activities to make the code more modular and ease the service realization”. The integration of this iterative process into the final roadmap is not detailed. Our goal is to clarify how this iterative process can be integrated to the migration plan and how it is impacted by external constraints. Due to these constraints, some stable intermediary phases must be implemented to benefit of the first advantages of the migration before its end. In this paper, we detail how we use the invasive transformation phase to build these stable phases and to orient the technical choices that will help the migration between two phases. To achieve this goal, the part dedicated to the integration of existing applications should be developed all along the service life cycle, from the service design to the evolution of the SOA solution. It can be seen as the transformation of the gap analysis phase proposed in [3] into a transversal activities, which impact all the other phases of the migration. Doing so, we expect to limit risk generated by the integration of existing application and to provide an architecture that will allow a smooth evolution of the existing systems. 2.2. Relationship between EAI and SOA The relationship between service-oriented architecture (SOA) and enterprise application

1867-7134 © GITO mbH

25

N. Biri et al.: Smooth integration of Existing applications in an SOA

integration (EAI) is not always clear, depending of the definition of what SOA and EAI actually are. In [5], EAI is seen as the goal of establishing communication between applications and SOA is an architectural solution to establish that communication. In [6], the definition of SOA is even more clearly defined as a solution used to enable communication between applications and to achieve an EAI. However, they complete their definition by a Semantic Service Oriented Architecture (SSOA) which integrates the notion of service definition to facilitate the reusability of services. It leads us to the most common differentiation between EAI and SOA, as stated in [7]: “Unlike EAI, SOA lets companies reuse the services they create - via the integration of multiple applications - in more than one business process without additional programming”. More clearly, an EAI can be seen as an imperfect achievement of a SOA, where the proposed services are derived from existing application instead of being aligned with business needs. Actually, these different definitions result from the dual aspects included in the notion of SOA. From a technical point of view, SOA is only a way to loosely-coupled applications. From a philosophical point of view and to achieve the goal of flexibility promised by SOA, the modelling of services and their design must be aligned with business. In real life migration, the
Figure 1: SOA-MF Overview

cursor is somewhere between these two aspects: during a SOA migration, some services will be redesigned and will leads to new development, and some others will result of an integration of existing applications. Thus, EAI can be seen as the adjustment variable in the achievement of an idealistic SOA. The main issue is to isolate integration tools and patterns that will facilitate the integration and its further evolution.

3.

SOA-MF Methodology

In this section, we propose the Service Oriented Architecture Milestone Framework (SOA-MF). This framework can be seen as a methodology to build a roadmap for a migration to a SOA. SOA-MF can be seen as a variant of the SOAF methodology proposed in [1]. 3.1. SOA-MF Overview SOAF is based on four main activities. SOAMF keeps the name and the phasing of these activities but modifies their content to introduce the notion of migration milestones. A migration milestone is an intermediary stable phase in the SOA migration. It is our proposed answer to the conflict between the long time view often introduced by a SOA migration, the cost constraints that limit the possible evolution of existing applications and the need of a quick return on investment of the SOA migration.

Information Elicitation

Service identification And Matching

Service Realization

Roadmap and planning

BPM “as-is”, “to-be” Process-to-app Mapping Migration strategy: Migration milestones

Determine: Covered, new, additional services by milestones Identified nested code

Determine transformation strategies Adjust services in milestones Direct consequence of the migration milestones

26

AIS Transactions on Enterprise Systems 1 (2009) Vol. 2

N. Biri et al.: Smooth integration of Existing applications in an SOA

In the following section, we present the 4 activities of the SOAF methodology and detailed the change introduced by the migration milestones. 3.2. Information elicitation Information elicitation consists in the realization of two business process models (BPM), one corresponding to the target architecture (“tobe”), and the other corresponding to the initial one (“as-is”). The design of the “to-be” model is the result of a top-down analysis (starting from the expectation), while the “as-is” is obtained thanks to a down-top analysis (starting from the actual landscape). At this stage, the “to-be” model is an idealistic model, not affected by external constraints. During the information elicitation, a key point is the evaluation of the “as-is” business model to highlight the key issues. The goal of the preliminary discussion is to figure out which of these keys are not intended to change at short term. This phase is followed by a process-toapplications mapping and assessment. This mapping gives an overview of the applications involved in the different parts of the process. The pain-points pointed out during the business process modelling should corresponds either to some business applications that should be difficult to integrates or to existing processes that are not automated yet. At this point, discussions should define a migration strategy. This strategy should include a general migration planning for the pain-points identified during the previous phase. The planning should only integrate a scheduling priority, to validate the order of refactoring of these painpoints. From this planning, several transitional business process-maps should be designed to reflect the different transition phases. These business model can be seen as the “realistic tobe” business models that will be considered as milestones during the migration. The processapplication mapping should be studied to see which applications are affected by each milestone and to assess the impact on the daily-business. 3.3. Service identification and matching The service identification and matching activity is an iterative process that lead to an optimal set of services and that determine which of them are covered by existing applications, which of them should be developed, and which of them are existing and useless.

In SOA-MF, contrary to the initial SOAF methodology, the classification of these services is relative to a considered milestone. For example, a service could be considered as useless at a given point of the migration while it could be useful before the refactoring of an existing part of the business process. Consider a legacy authentication system, which should be replaced by a centralized single sign-on service in the long term. While no other services requires authentication, the singlesign-on services might be useless. To achieve the identification and matching, we recommend to analyse the set of services according to the “to-be” business process and to identify the change in the intermediate milestones afterwards. During this activity, the goal is also to identify nested applications that share data or library usage. These applications must be handled carefully, especially if they are not migrated at the same time. In this last case, the migration must ensure that other nested applications are not impacted by the first migration. 3.4. Service realisation Service realisation activity aims at define transformation strategies according from the current architecture through the milestones architectures to the final architecture. Of course, the proposed migration milestones have a significant impact on this strategy. The goal is to provide as soon as possible interfaces that correspond to the final behaviour of the services. The main obstacle to achieve it is that the migration plan must cope with the unchanged applications. These constraints have an impact on the realisation of services. The granularity of the services can change due to an inappropriate API of an existing service. Some services may require extra information at an early stage to fit with the back-end application. More clearly, the possibility integration of the unchanged application must be studied to assess the impact on the proposed services. According to the result of this assessment, the services of the migration milestones can be slightly impacted. Consequently, the SOAF activities are less linear due to the introduction of the migration milestones. The service realization phase should have an impact on the service identification phase and might also modify slightly the business process models of the milestones. The creation of the migration milestones also adds complexity to the service realization activities. The

1867-7134 © GITO mbH

27

N. Biri et al.: Smooth integration of Existing applications in an SOA

services defines in the milestones should evolved to facilitate the migration to the next ones, the technological choices and the concrete architecture should also evolve to integrate this evolution. For example, an analysis of the milestones should lead to the integration of mediation services to avoid major change to the service consumers when the architecture will evolve. 3.5. Roadmap and planning In the initial SOAF methodology, the roadmap and planning activity is presented as follows: “The roadmap and planning phase involves detailed planning of projects to implement the transformation initiatives as well as identifying business and technical risks and defining mitigation strategies”. The introduction of migration milestones reduces significantly the complexity of this activity, applying the divideand-conquer” paradigm: the global roadmap and planning is the sum of the ones defined to achieve each milestone. Besides, most of the mitigation strategies have been integrated in the definition of the milestones. Consequently, the definition of the roadmap and planning should derived directly from the migration milestones, with a more precise timeline according to the observation made during the three first activities.

4.

Integration issues and architecture

Loose-coupling was often presented as (one of) the Holy Grail of an SOA. Most of the time, the assessment of the loose-coupling capability of the architecture occurs after is shipment, when some existing services or applications have to evolve. With the introduction of migration milestones, the importance of loose-coupling appears sooner in the migration process. The migration roadmap should require some changes of existing services from ones milestones to another. These changes can correspond to an evolution of the technology of an application, an evolution of the service contracts and/or the service policies, evolution of the business processes and/or evolution of the available data schema. In [8], taxonomy of seven levels of loose-coupling is proposed; the seven levels are the following: • Loose Coupling the Implementation • Loose Coupling the Service Contract • Loose Coupling the Service Policy • Loose Coupling the Process • Loose Coupling the Data Schema

• Loose Coupling the Infrastructure • Loose Coupling at the Semantic Layer Thus, during a migration, the five first levels of the 7 proposed can be involved. Implementation of a service can change with the underlying application. The evolution of the business process can have an impact on the existing services and change their contract. The service policy can change due to a change of the application specification. Due to the evolution of the service offers during the migration, business process can also change. Finally, refactoring of the applications can have an impact on the data schema. To cope with these changes and to manage them efficiently, we propose a generic architecture based on the one we have already described in [9]. The global architecture, presented in Figure 2, is based on ServiceMix, an open-source ESB implementing the Java Business Integration (JBI) specification [10]. Indeed, the JBI specification and the API define a platform for building enterprise-class ESBs using a pluggable, service-based design. The JBI runtime core mainly comprises the following components: • Component framework enabling the deployment of the different types of components within the JBI runtime. • Normalized Message Router enabling a standard mechanism of message interchange between the services. The messaging model is based on Web Services Description Language (WSDL). • Management framework based on Java Management Extensions (JMX) enabling the deployment, management and monitoring of components within the JBI runtime. The JBI environment hosts plug-in components such as transport binding, routing engines, rule engines and transformation services. JBI defines two types of components: Service Engine components (SE) responsible for implementing business logic and other services, Binding Components (BC) used to provide transport level bindings for the deployed services. The ESB acts as a vertebral spine of the architecture. It gathers the incoming requests, adapt it to the back-end services and transmit them to those services. In this process, the goal of the binding components is to provide a wider technological abstraction: in some scenarios, it could be useful to access to a service with another technology than web-services. The binding components are used to convert incoming

28

AIS Transactions on Enterprise Systems 1 (2009) Vol. 2

N. Biri et al.: Smooth integration of Existing applications in an SOA

request in a common message format (based on SOAP, according to the JBI specification) and to transform outgoing message from SOAP to a dedicated message format. The service engines are generally used to adapt the message to the backend services or two perform specific integration of enterprise applications. According to the ESB’s policies, the incoming requests will pass through a set of service engine that will adapt the message, thus, evolution of the back-end applications will result in a modification of the policies. The service policies are managed thanks to a business process engine that is a service engine itself. In the proposed solution, the role of the service engine, who acts as middleware services, can be compared to the web services management layer presented in [11]. The main difference is the goal of the services. In our case, the role is clearly to facilitate services’ evolution. With the above description of the architecture, the main goal is to isolate part of the service design that are candidate for a change from direct access using the ESB and one or several service engine components as a façade. Doing so, the evolution of the application in back-end will impact only the access to the corresponding service from the façade. If the service evolution results in a contract change, some service engines can be integrated to transform the incoming requests to corresponds to the final requests.
Figure 2: Global architecture overview

5.

Case study

The methodology and the architecture described in the sections 3 and 4 were evaluated on a real case scenario in the Luxembourg National Family Allowances Agency (Caisse Nationale des Prestations Familiales – CNPF). We present here the specificities of the study and the migration solution found to solve some migration issues. 5.1. Migration overview The IT Landscape has to manage 4 main domains of activities: • The citizen management: the CNPF has to maintain the information relatives to its users. • File management: the CNPF has to classify the incoming requests of the citizen. • Allowance request assessment: the CNPF has to evaluate the request of the citizen according to his/her situation. • Allowance computation: the CNPF has to compute the amount of allowance that should be paid to the citizen. For commuters, the CNPF also have to compute how much each country (the home country of the citizen and the Luxembourg) has to pay. We will not detail the results of the SOA-MF analysis here, but we will mention some of the constraints that were included to define the migration milestones: • The Citizen Resource Management (CRM) could not evolve before the achievement of

Services Consumers and Producers

JBI CONTAINER
Binding Component 1

Business process Manager (Service Engine)

...

Binding Component n

Normalized Message Router

Legacy application access (Service Engine)

Message Mediator 1 (Service Engine)

...

Message Mediator n (Service Engine)

1867-7134 © GITO mbH

29

N. Biri et al.: Smooth integration of Existing applications in an SOA

the first migration milestone. Access to the data through the original version of the CRM is limited to some pre-defined requests, no bulk read is available. • The document management systems (DMS) could not evolve before the start of the third migration milestone. • The CRM and the DMS use the same basic authentication system, based on a database query. The final goal is to replace this system with authentication system based on LDAP. • The automation of the allowance computing is easier to implement than the allowance request assessment. The computation will be included in milestone 1; the request assessment will be included in the final milestone. To synthesise, two intermediary milestones are proposed. The first one only includes the backend service bus, provides interfaces to existing applications to propose them as services and deploy the computation of allowances. The second milestone integrates the new CRM. The final milestone will integrate the LDAP system and the request assessment services. 5.2. Migration solution Given the migration issues mentioned in section 5.1, we explain how we have integrated migration solution in the target architecture to facilitate the migration between the milestones. Concerning the limited access to the CRM’s data, the solution was to build a facade to isolate the requests of the clients from the requests effectively sent to the API. A service engine is in charge of the translation of the requests. As soon as the new CRM and data schema were ready to go live, the service engine was modified accordingly. Doing so, the clients were not directly impacted by the evolution of the CRM application, and did not notice the changes in the data schema. The authentication issue was harder to handle. The initial authentication system is quite limited and does not include any permission information. The goal is to migrate to a LDAP authentication system and to use LDAP group to determine the security policies to access to the application. Once again, the chosen solution is to provides a façade for the authentication service and to provide an authorisation service that provides right attached to an identity for the access to a given service or application. The methodology used here is strongly related to the approach of a composition of services to achieve a security stack proposed in [12]. Then, replacement of the existing authentication system will only impact these two services.

Currently, the system is ready to go live with the second migration milestone. The replacement of the CRM application has no unwilling impact on the existing services and has been transparently achieved.

6.

Conclusion and further works

During a migration to a SOA, the business constraints are often underestimated. Cost of the migration, daily business operations can strongly impact the migration roadmap. Besides, migration is a long time process and most of the methodologies do not provide stable milestones to provide a progressive integration of SOA benefits. SOA-MF tries and copes with these two issues, to provide milestones that guide the migration and provide stable releases that can run in production. The introduction of milestones can introduce some technical challenges regarding the evolution of services or of integrated applications. However, these challenges are not inherent to milestones but to the business constraints. Further more, for most of the companies, the goal of a migration to SOA is often to obtain a more flexible IT landscape and to facilitate the adoption of new components [13]. The challenges faced during the migration between two milestones can be seen as an assessment of this flexibility. We have also briefly introduced a technological platform that support the loose-coupling of components and facilitate the evolution of services. However, the benefits of the presented architecture are based on empiric knowledge and on subjective feeling of real case studies. Our goal is to assess more formally the presented platform and to provide a set of components that corresponds to classical scenarios of service evolutions, or improvement of existing services.

Literature
[1] Erradi, A., Anand, S. and Kulkami, N., “SOAF: An architectural framework for service definition and realization.” 2006. 2006 IEEE International Conference on Services Computing, SCC 2006. pp. 151-158. Ramollari, E., Dranidis, D. and Simons, A.J.H., “A survey of service-oriented development methodologies.” 2007. 2nd Young Researchers’ Workshop on Service Oriented Computing. pp. 1-6. Papazoglou, M.P. and van den Heuvel, W.J., “ServiceOriented Design and Development Methodology.” Int. J. of Web Engineering and Technology (IJWET), 2006.

[2]

[3]

30

AIS Transactions on Enterprise Systems 1 (2009) Vol. 2

N. Biri et al.: Smooth integration of Existing applications in an SOA

[4]

[5]

[6]

[7] [8] [9] [10] [11]

[12]

[13]

Arsanjani, A., Service-oriented modeling and architecture (SOMA). [Online] 2004. http://www. ibm.com/developerworks/webservices/library/ws-soadesign1/. Gorton, I. and Liu, A., “Architectures and Technologies for Enterprise Application Integration.” 2004. 26th International Conference on Software Engineering (ICSE’04). pp. 726-727. Haller, A., Gomez, J.M. and C., Bussler., “Exposing Semantic Web Service principles in SOA to solve EAI scenarios.” 2005. Workshop on Web Service Semantics, in WWW2005. Ortiz, S., “Getting on Board the Enterprise Service Bus.” IEEE Industry Trends, 2007, pp. 15-17. Schmeizer, R., “The seven levels of loose coupling.” [Online] November 2007. http://www.zapthink.com/ report.html?id=ZAPFLASH-20071128. Bauler, P., et al., “Implementing a Service-Oriented Architecture for Small and Medium Organisations.” 2006. EMISA. pp. 105-118. Ten-Hove, R. and Walker, P., “Sun Microsystems, JSR 208: Java Business Integration (JBI).” [Online] 2005. http://www.jcp.org/en/jsr/detail.php?id=208. Verheecke, B., Vanderperren, W. and Jonckers, V., “Unraveling crosscutting concerns in Web Services Middleware.” s.l. : Software, IEEE, 2006, Issue 1, Vol. 23. Opincaru, C. and Gheorghe, G., “Service Oriented Security Architecture.” 2007. Enterprise Modelling and Information Systems Architectures (EMISA). pp. 6174. AmberPoint Report., State of SOA adoption report - Gauging the Use of SOA Systems in the Enterprise. January 2008.

Nicolas Biri Department Informatics, Systems and Collaboration, Centre de Recherche Public – Gabriel Lippmann, Belvaux, Luxembourg, E-Mail: biri@lippmann.lu Phone: +352 47 02 61 642 Dr. Nicolas Biri is project Leader at CRP – Gabriel Lippmann, specialized in service oriented architecture and its applications to small and medium enterprises and administrations. Pascal Bauler Department Informatics, Systems and Collaboration, Centre de Recherche Public – Gabriel Lippmann, Belvaux, Luxembourg, E-Mail: biri@lippmann.lu Phone: +352 47 02 61 661 Pascal Bauler is project Leader at CRP – Gabriel Lippmann, is deeply involved in the technical architecture set in place in administrations who are partners of the CRP-GL. Fernand Feltz Department Informatics, Systems and Collaboration, Centre de Recherche Public – Gabriel Lippmann, Belvaux, Luxembourg, E-Mail: biri@lippmann.lu Phone: +352 47 02 61 600 Fernand Feltz is the Scientific director of the Informatics, Systems and Collaboration Department of the CRP-GL.

1867-7134 © GITO mbH

31

H. Weigand et. al.: Value Encounters: Modelling and Analyzing Co-creation of Value Available online at www.enterprise-systems.net

AIS Transactions on Enterprise Systems 1 (2009) 2, 32-41

Value Encounters: Modelling and Analyzing Co-creation of Value
Hans Weigand and Jeewanie Jayasinghe Arachchige
Abstract
Recent marketing and management literature has introduced the concept of co-creation of value. Current value modeling approaches such as e3-value focus on the exchange of value rather than co-creation. In this paper, an extension to e3-value is proposed in the form of a “value encounter”. Value encounters are defined as interaction spaces where a group of actors meet and derive value by each one bringing in some of its own resources. They can be analyzed from multiple strategic perspectives, including knowledge management, social network management and operational management. Value encounter modeling can be instrumental in the context of service analysis and design. Keywords: Service-Dominant logic, value modeling, business ontology (active) resources. Instead of seeing value being created within companies that exchange the means for this value creation from one to another, it sees the value being created between companies (or companies and consumers). In its focus on cocreation of value, it builds forth on already existing management theory work of Norman [18] and Prahalad [21] and the marketing literature [12]. The notion of S-D logic still needs to be worked out further and gain more empirical validation [5], but in this article, we take it as a starting-point, and address the question how to support this logic using current value modeling and business ontology approaches [3]. Current value modeling approaches can deal well with services and have provided several conceptual tools to support service design [15, 30, 13]. However, they fall short at the moment in supporting an S-D analysis of value creation. In particular, when focusing on e3-value (see section 2), we note the following limitations: • To assess the sustainable value of network collaboration, the analysis must look beyond economic transactions. The dynamics of intangible benefits, in particular the effects on knowledge development and the social network, need to be taken into account as well. • Collaborations often involve more than two actors. Although an e3-value analysis helps to clarify the value that each actor draws from other parties in terms of value that they receive, the model does not identify the value that the stakeholders draw from the collaboration as such. The same holds for the resources that they bring in. The e3-value model breaks up the collaboration into binary value exchanges. This approach is fitting from a purely economic perspective, as contracts are most often made between two parties, but it

1.

Introduction

In recent years, Vargo and colleagues [27, 16, 1] have contributed to the development of service science [23] by introducing the concept of “service-dominant (S-D) logic”. As the name suggests, S-D logic focuses on service provision in contrast to goods production (G-D logic). S-D logic can be seen as an attempt to view services not as a particular kind of (intangible) good that should be produced and marketed in the same way as traditional goods. Service provisioning is doing something before and with another party. In this perspective, what the company provides is not an output, but an input for a continuing value-creation process. The shift from G-D to S-D logic is one from a value proposition consisting of operand (passive) resources to one consisting of operant

32

AIS Transactions on Enterprise Systems 1 (2009) Vol. 2

H. Weigand et. al.: Value Encounters: Modelling and Analyzing Co-creation of Value

can obstruct a holistic understanding of the collaboration and the value that is created in the collaboration. In order to overcome these limitations, this paper introduces an extension of the e3-value approach in which collaborations are treated as first-class citizens. To assess the viability and sustainability of the collaboration, we take a holistic approach. We introduce the notion of value encounters in which the collaboration becomes concrete. The validity of this construct is put to the test in two ways: first, by a fictive but realistic business scenario from the health care domain that we model (section 4) and analyze (section 5). Secondly, by developing a formal ontology of the value encounter (section 6). In section 7, we draw some conclusions and relate to other work in business economics. Figure 1. Basic e3-value constructs

2.

Theoretical Background of Value modeling

There exist a number of approaches, languages, and ontologies for business modeling in literature. In [3] the e3-value [9] and the REA ontologies [17] were compared (together with a third business ontology – the BMO [21]) in order to establish a common reference business ontology. One result of that comparison was a set of mappings between e3-value and REA indicating strong similarities between the concepts of the two. Both REA and e3-value were originally designed for capturing tangible exchanges of economic resources between actors. Allee [2] complements this view by proposing to include intangible exchanges as well. Examples of resources transferred through intangible exchanges are knowledge or status. The Resource-Event-Agent (REA) ontology was formulated originally in [17] and has been developed further, e.g. in [8] and [26]. REA was originally intended as a basis for accounting information systems and focused on representing increases and decreases of value in an organization. REA has been extended to form a foundation for enterprise information systems architectures [14], and it has also been applied to e-commerce frameworks [26]. The core concepts in the REA ontology are Resource, Event, and Agent. The intuition behind the ontology is that every business transaction can be described as an event where two actors exchange resources. To acquire a resource an agent has to give up some

other resource. For example, in a goods purchase a buying agent has to give up money in order to receive some goods. The amount of money available to the agent is decreased, while the amount of goods is increased. Conceptually, two events are taking place: one where the amount of money is decreased and another where the amount of goods is increased. This combination of events is called a duality and is an expression of economic reciprocity - an event increasing some resource is always accompanied by an event decreasing another resource. A corresponding change of availability of resources takes place at the seller’s side. Here the amount of money is increased while the amount of goods is decreased. There are two types of events: exchanges and conversions [14]. An exchange occurs when an agent receives economic resources from another agent and gives resources back to that agent. A conversion occurs when an agent consumes resources to produce other resources. Events often occur as consequences of existing obligations of an actor; in other words, events fulfil the commitments of actors. The e3-value value ontology [9] aims at identifying exchanges of resources between actors in a business case. It also supports profitability analyses of business cases. The ontology was designed to contain a minimal set of concepts and relations to make it easy to grasp for its intended users. e3-value includes a graphical notation for business models. Figure 1 shows the basic concepts in e3-value are actors, resources, value

I1867-7134 © GITO mbH

33

H. Weigand et. al.: Value Encounters: Modelling and Analyzing Co-creation of Value

ports, value interfaces, value activities and value transfers. An actor is an economically independent entity. An actor is often, but not necessarily, a legal entity, such as an enterprise or end-consumer or even a software agent. A set of actors can be grouped into a market segment. A resource (also called value object) is something that is of economic value for at least one actor, e.g., a car, Internet access, or a stream of music. A value port is used by an actor to provide or receive resources to or from other actors. A value port has a direction: in (e.g., receive goods) or out (e.g., make a payment), indicating whether a resource flows in to or out from the actor. A value interface consists of in and out ports that belong to the same actor. Value interfaces are used to model economic reciprocity and bundling. A value exchange represents one or more potential trades of resources between these value ports. A value activity is an operation that can be carried out in an economically profitable way for at least one actor. According to Allee’s approach to value network modeling [2], a distinction must be made between tangible and intangible exchanges of resources. Tangible exchanges are established and explicitly regulated in contracts. They correspond to exchanges of economic resources in the REA ontology and e3-value. Intangible exchanges are established informally and their terms are not present in contracts. As stated in [2], “Intangible knowledge and information exchanges flow around and support the core product and service value chain, but are not contractual. Intangibles include those “little extras” people do that help keep things running smoothly and build relationships. These include exchanges of strategic information, planning knowledge, process knowledge, technical know-how, collaborative design work, joint planning activities, and policy development.” There is no formal correspondence between an intangible exchange and any concept in REA or traditional e3-value. E3-services [15] is an extension of e3-value that is aimed at identifying bundles of services. E3-services introduces the concepts of needs, consequences and wants. The consequence of a service is anything that results from consuming valuable service properties. A need is a solutionindependent goal, whereas a want is defined as a service implementing a specific solution. A want matches a need when the consequences of the want satisfy the need. Consequences are viewed in a broad sense. Both functional properties and

quality properties are taken into account. For the purpose of this paper, e3-services is interesting for two reasons. First, because it adopts a broad perspective on the notion of service value as described in terms of consequences. Secondly, because it goes beyond the description of a value object being exchanged and provides instruments to describe a proposed service as well as a required service and how these two are matched. However, we note that the conceptualization of “needs” and “wants” betters matches with G-D logic than with S-D logic that prefers to talk about enabling rather than relieving a need.

3.

Motivating Example

For illustrative purposes and as a running example we use the fictive but realistic business scenario from the health care domain, including actors such as hospitals, patients, and medical equipment providers, as described in [4]. It is constructed to highlight some problems related to exchanges of resources that a business analyst or modeler may encounter. The verbal description as given below is intentionally underspecified and imprecise, as this is always the case in practice. Therefore, it should be analyzed, for instance, using the value object analysis introduced in [28]. The Hospital purchases medical equipment from the Medical equipment providers by placing Orders and paying Cash. Furthermore, the Hospital acquires Product knowledge through their interactions with the Medical equipment providers. The Sales agents assist the Medical equipment providers to acquire new customers, i.e. they market the products of the Medical equipment providers, negotiate with potential customers and deliver valid Customer orders to the providers. Through participating in this interaction, the Sales agents will get Product knowledge from the providers, while the latter will get Market knowledge from the Sales agents. The Patients receive Health care services from the Hospitals such as examinations and treatments. These services will improve the Health state of Patients but also their Knowledge about their health conditions as well as their Feeling of safety. The Hospitals will get paid by the Insurance Company of the Patient. They also get improved Medical knowledge by examining and treating complex cases. The Government collects tax from citizens in order to provide health care for

34

AIS Transactions on Enterprise Systems 1 (2009) Vol. 2

H. Weigand et. al.: Value Encounters: Modelling and Analyzing Co-creation of Value

all. The Hospitals interact with the Government providing Health care services and receiving Cash in return. Furthermore, the Government gives the Hospitals access to the market by providing Authorization. The Hospitals may participate in Professional communities with which they exchange Knowledge. A Professional community will also get the Attention of the Hospital. Through its participation the Hospital will earn Status.

4.

Value Encounter Modeling

When addressing a certain value network, the value encounter Figure 2. Value encounters medical equipment agent analysis postpones the question of the Agent, the primary goal is to build a relationship who is exchanging value to whom, but focuses on the value encounters first. A value with doctors and be kept informed about possible encounter is an interaction space between multiple needs of the hospital. For the doctor, the value is actors where each actor brings in certain resources; that he receives information about new products these resources are combined then in such a and possibly also some give-away from the Proviway that value is created to all of them. Value der. However, it does cost him some time investencounters can be connected by means of a causal ment. For the Provider, the value of the interaction relationship (“+”), when activity in one encounter is in the publicity that he gets. The second value encounter contains an economic reinforces the activity in another encounter. In this way, the dynamics of the system become apparent. transaction, the purchasing of a piece of equipment. In the example described in section 3, several Variants would be possible as well, for instance that independent groups of value encounters can be that the equipment is leased. Presumably, the Agent contributes to the value encounter by active support distinguished: • Among Hospital, Equipment Provider and Agent in the negotiation and administration. In return, having to do with the purchasing of medical he receives a certain fee. Note that a situation like this in which three parties are involved cannot be equipment. • Between Hospital and other Hospitals, having to rendered straight-away in traditional e3-value; the encounter would be split up in two transactions, do with knowledge sharing and legitimization. • Among Hospital, Patient and Insurance Company one between Provider and Hospital (the equipment) and one between Provider and Agent (negotiation having to do with health care provisioning. • Between Hospital and Government (not worked service). That these two value transactions are intrinsically intertwined cannot be expressed. out in this paper) The third value encounter is about the actual We start with the first group, depicted in Figure. 2. The value encounters are rendered graphically as usage of the equipment. Here the Provider brings dotted light (yellow) rectangles. We have distingu- in technical support and perhaps spare parts. The ished four encounters. Each of them creates certain Hospital gains operational enhancement (support value independently of the other, but they mutual- for its medical work). However, the usage of the ly reinforce each other, so they are put together in equipment also brings in practical experience from one group. The doctor visit is an encounter. This which the Provider can gain. The fourth encounter is between Provider is an interaction that does not involve an economic transaction and hence would not be included in a and Agent only, and involves an exchange of traditional e3-value model. Nevertheless, it is of knowledge, e.g. in the form of a course. The crucial importance for the business model of the Provider brings in his technical expertise, from Agent, and has also value for the other actors. For which the Agent gains product knowledge.

I1867-7134 © GITO mbH

35

H. Weigand et. al.: Value Encounters: Modelling and Analyzing Co-creation of Value

Figure. 3. Value encounters hospital community

The second group of value encounters (Figure. 3) concerns the participation of the hospital in the 5. Value Encounter Analysis professional community. The bottom line would be that hospitals interact in a peer-to-peer fashion. Once the value encounters have been modeled, However, on the basis of the description we assume the next step is to analyze them. Analysis always that there is an institutionalized community that focuses on one aspect at a time. Which aspects are facilitates these interactions. relevant differs from case to case. Complementing A distinction is made here between two the profitability analysis provided by traditional encounters: the first creates and maintains e3-value, we propose the following: enrollment. From this encounter, the hospital can • value activity analysis claim recognition. The resource that the community • knowledge management brings in is nothing more or less than its public • social network (social capital) management status. The second value encounter consists of the • operational management meetings organized by the community in order to Although profitability analysis is not worked out facilitate the sharing of experience. Evidently, there here, it should be noted that starting from value are typically more supporting actors involved, like encounters, profitability analysis and contract decatering, or could be involved, such as equipment sign need to be performed in combination. A value providers sponsoring the meeting in return for encounter model does not show how the money is some publicity. The goal of the value model is to distributed exactly, which is needed for the proexpress what is deemed relevant at some point in fitability analysis. This depends on the way the time, not to be complete. multi-party collaboration is broken up into bilaThe third value encounter group (Figure. 4) teral contracts. Fairness is an important variable is about the health care itself. The medical treatment is modeled here Figure. 4. Value encounters doctor-patient as a single value encounter. This is a simplification of course, as many different kinds of encounters – doctor visit, surgery, hospital care, etc. – could be distinguished. Basically, the Patient receives medical advice and healing. The Doctor brings in his medical expertise and his attention. On the other hand, he gains experience data from the encounter itself. The Insurance Company is paying the treatment and is therefore a stakeholder as well. In certain cases, the Insurance Company is the one that can arrange a medical

treatment for its customers, so we have included this service as well. The value encounter between Insurance Company and Patient is about the contract. The patient pays for a right on medical service in return. The company brings in a commitment (we will guarantee your medical care). There is a relationship identified between the value encounters: the more contracts the insurance company has acquired, the more medical treatments it has to arrange.

36

AIS Transactions on Enterprise Systems 1 (2009) Vol. 2

H. Weigand et. al.: Value Encounters: Modelling and Analyzing Co-creation of Value

in sustainable value networks that should play an important role in this breaking up. 1.1 Value Activity Analysis The initial value encounter model depicts value encounters as black boxes. In order to get a better understanding of how value is created, we can identify the value activities that happen within the value encounter. These value activities are connected to the value encounter inputs and outputs. In simple value transfers, the value Figure. 5. Value activity analysis activity is low profile and input is almost equal to output. In general, example, we see that the Hospital maintains its there is not always a 1-1 relationship between knowledge in various ways: from contacts with inputs and outputs. For example, consider the Agents, from dealing with Patients (complex value activity analysis of the Hospital-Patient cases) as well as from interaction with other encounter (Figure. 5). Hospitals in the community. We have distinguished an appointment activity and a payment activity, the latter being fed by the 1.1 Social Network Management. former. The experience that the Doctor gains from Over time, individual actors will change their the encounter has no direct corresponding input as value proposition. To enable evolution of the value it is gained from the interaction itself. In contrast, network drawing on the same partner base, the the arrangement that is brought about by the social network underlying the collaboration should Insurance Company has no direct corresponding be kept healthy [16, 25]. So the main question here output, as it is the interaction itself that profits is: how do actors maintain their social network? from the arrangement. Some sub questions are: • Is there a healthy mix of informal (face-to-face) 1.2 Knowledge Management. and formal contact? In the example, most From the KM perspective, the question is: how of the value encounters are based on face-todo actors maintain their knowledge resources [7, face meetings in which social relationships are 2]? The assumption is that for actors to survive in maintained in a natural way. However, more the long run, their knowledge – both explicit and attention could be given to the formal part, implicit in routines – is the core competency [6]. e.g. by the use of evaluation forms regarding Some sub questions are: the doctor-patient encounter (on some regular basis). • Is there a healthy mix of explicit and implicit knowledge transfers? In the case of the Hospital, • Is information about the social networks maintained in a systematic way? In the hospital we see in fact instances of both. case, this is particularly important for the • If certain data is available, is it possible to gain Agents who are very much dependent on good more value from it, e.g. by Business Intelligence relationships with the doctors. The hospital techniques? For example, the experience data itself could consider the opportunity to integrate that the doctor gets from patient consults. If the multiple social networks that its doctors some of these data are encoded digitally, the maintain individually. Although such integration hospital could integrate the information from is not something that can be imposed, it can be different sources and mine for certain patterns. stimulated by providing facilities such as a • Is the knowledge acquired also explored? professional social network platform. For example, if medical equipment is to be purchased, are all doctors with relevant • Is the social network actively explored? For example, the hospital can explore the social knowledge involved in the process? network it maintains within the community • Is the knowledge making up core competencies when job vacancies have to be filled. actively maintained and increased? In the

I1867-7134 © GITO mbH

37

H. Weigand et. al.: Value Encounters: Modelling and Analyzing Co-creation of Value

• Is the social network actively developed? Actual participation in a hospital community and its meetings is a point in case. 1.1 Operational Management. For a value encounter to be satisfactory in the long run, it must be run efficiently for all participants. Treacy and Wiersema [24] mention operational excellence as one of the three critical value disciplines. The question is: how to optimize the efficiency of the value encounter? Some sub questions: • How is the value encounter to be characterized? To answer this question, the analyst can make use of encounter patterns. Examples of patterns are “group meeting”, “single service counter”, “sequential service counter”, “1-1 meeting” and “sales”. In some cases, the pattern needs to be decided on carefully. For instance, is the doctor visit in the hospital organized as a single service counter (each doctor viewed independently) or a sequential one? The choice has consequences for the way the encounter is to be supported. • How is the value encounter supported? Continuing the example from above: in the former case, a simple agenda planning system per doctor is sufficient. In the latter case, if the patient will have to visit several service points, one should try to minimize waiting time and a global planning system is needed. For value encounters characterized as “group meeting”, a registration system is needed.

• How is the optimization of the encounter ensured? To optimize the efficiency of the value encounter, it needs to be monitored, and the responsibility of this task should be allocated. Different stakeholders in a value encounter will have different optimization goals, so there is a risk of Prisoner Dilemma phenomena. In some cases, there is a natural “leader” and the allocation is easy; e.g. when there is a binary collaboration between a provider and a customer segment. In complex cases, the monitoring can be allocated to a partner that is involved for this function. Or the parties can agree on collaborative monitoring.

6.

Value Encounter Ontology

In the above, we have introduced the value encounter concept in an informal way. In order to apply the technique in a consistent way, we need a more formal definition as well. The value encounter ontology (Figure. 6) is intended to be a generalization of the e3-value value ontology. Value activities within value encounters get input from value propositions and provide output to value derivations – both are value transfers in e3-value terminology. A value proposition says what the actor brings in (in terms of “resourcing” [16]). A value derivation says what the actor gets out of the value encounter. These connections are viewed as instantiations of a value object, e.g. “negotiation service”. The value encounter ontology is Figure. 6. Value encounter ontology (as a UML class diagram – the dotted lines a generalization of e3-value: a represent derived relationships) value encounter can involve more than two actors, whereas a value exchange in e3-value includes only two. The generalization also makes it possible to distinguish between value propositions and value derivations. A value derivation type corresponds to what [15] calls a need, that is, a requested service and a value proposition type to a provided service. A value encounter is an aggregation of value activities. By default (as in the examples in section 4), the value encounter contains one holistic value activity not explicitly rendered in the diagram. The question what exactly is brought in by an actor, that is, the

38

AIS Transactions on Enterprise Systems 1 (2009) Vol. 2

H. Weigand et. al.: Value Encounters: Modelling and Analyzing Co-creation of Value

question of resourcing, is not that simple, as there are many possible business model types and the modeling should not be restricted or biased to a particular kind only. In fact, we can distinguish a whole spectrum of business model types ranging from a typical G-D kind of exchange on the one hand to an advanced S-D kind of value cocreation at the other. In the first case, resourcing can be in the form of a good or product that is sold by the Provider, acquired by the Customer, and used internally in some value adding process. In such a case, the value encounter is almost reduced to an object exchange. We say “almost”, as even in this case, the encounter involves a service contact between the actors in which secondary values and benefits do play a role. In the case of face-to-face meetings, there is always a social aspect. Somewhere at the middle of the spectrum, resourcing takes the form of services (economically, these are resources as well, cf. [30, 20]). An example is the arrangement service in Fig. 3 or the after-sales service provided by the Equipment Provider. Such a service draws on internal resources but it is not the internal resource itself. The service can be used within the value encounter (a meeting being organized) or be consumed by some other actor (the patient taking benefit from the advice and improving his health). At the other (S-D) side of the spectrum, the actors provide access to their internal resources – e.g., their knowledge, and these resources are explored by collaborative value activities within the value encounter in order to create something of value. Value encounter models support the whole spectrum of business models, Whether there is indeed a shift from G-D logic to S-D logic nowadays remains an empirical question [5], as is the question of the benefits and costs of such a shift.

7.

Discussion

According to a recent paper by Jim Spohrer and colleagues [23], “formalizing the notion of value co-creation interactions and further developing the types of value propositions is a challenge for service science”. This paper takes up the challenge and has introduced and formalized the notion of value encounter as an extension to current value modeling approaches. It encourages a service-dominant logic view of value networks where value is not viewed as exchanged but as created when different actors come together each bringing in their resources in order to create something of value to all. However, it does not

exclude G-D based models or hybrid forms. A value encounter model can be subject to various kinds of analysis in order to support strategic management and business redesign [29]. These, in turn, can be a starting-point for IS design. In a codesign approach, IS design and value encounter modeling can be pursued in parallel [10]. The use of IT may enable innovative extensions of existing value encounters or generate completely new ones. The introduction of the notion of value encounters draws attention to something not considered yet in value modeling, as far as we know, that is, the relevance of the value exchange context. A value encounter is explicates the context. Sometimes value exchanges can only be realized in the right context, for example, a certain governmental regime. The contribution of this regime is like a catalyst in chemical reactions: it does not participate actively, but without it, the reaction would not take place. The relevance of context has been recognized in economics before, in particular in the theory of country-specific resources (CSRs) and clusters [5]. These theories go back to the work of the early trade theorists who focused their analyses on basic factor inputs such as land, labour and capital. Attention was also paid to the role of geographic location as a country-specific resource. More recent work has broadened the discussion of CSRs to include not only inherited resources but also those that are created by a country. In all these cases, the resource in question is a product of investments made over a long period of time in any given country [11]. Examples are the education system, technological and organizational capabilities, communications and marketing infrastructures, labour productivity and research facilities. Clusters share many characteristics of networks but are differentiated by co-location and active efficiencies. The notion of value encounter allows us to model a geographical unit or cluster not so much as a resource but as a space in which resources are put on the table in order to co-create value. This is relevant to business modeling and strategy analysis. In traditional value modeling, the actors are located in an abstract space. Why a certain value network does grow and prosper in one environment and not in another, remains unexplained. It makes sense to view strategy design as an attempt either to develop completely new value encounters (which typically needs a long line of investment) or to build on and extend already existing value encounters. In the course of time, these value encounters grow and

I1867-7134 © GITO mbH

39

H. Weigand et. al.: Value Encounters: Modelling and Analyzing Co-creation of Value

adapt and as such they represent a long history of economic as well as social investments. Such an approach is not only interesting in view of physical environments but also of virtual environments. For example, a social network site as Facebook facilitates value encounters on which companies can capitalize in order to build new business models [31]. The notion of value encounter is a starting-point for developing this way of thinking, but many questions are still open. For instance, how do we delineate and relate contexts? Can we use the reinforcement relationship introduced above for that purpose?

References
[1] Alter, S. (2008). Service system fundamentals: Work system, value chain, and life cycle. IBM Systems Journal , Vol 47(1), pp.71-86. [2] Allee, V. (2002). A Value Network Approach for Modeling and Measuring Intangibles. White paper presented at Transparent Enterprise, Madrid. [3] Andersson, B. et al. (2006). Towards a Reference Ontology for Business Models. In D.W. Embley, A. Olive and S. Ram editors, Proc. ER’06 . [4] Andersson, B, P. Johannesson, M. Bergholtz, (2009). Purpose Driven Value Model Design. Proc. CAiSE workshop BUSITAL’09, CEUR [5] Arnould, E.J. (2008). Service-dominant logic and resource theory. Journal of the Academy of Marketing Science, Volume 36, pp.21-24. [6] Barney, J. (1991). Firm resources and sustained competitive advantage. Journal of Management Volum 17(1), pp.99-120. [7] Blecker Th. and R. Neumann (2000). Interorganizational knowledge management— Some perspectives for knowledge oriented strategic management in virtual organizations. In: Y. Malhotra, Editor, Knowledge management and virtual organizations, Idea Group Publishing, Hershey, London, pp. 63–83. [8] Geerts, G., McCarthy, W. E. An Accounting (1999). Object Infrastructure For Knowledge-Based Enterprise Models. IEEE Int. Systems & Their Applications, pp. 89-94. [9] Gordijn J., Akkermans J.M., van Vliet J.C. (2000). Business modeling is not process modeling. In Conceptual modeling for e-business and the web. LNCS, Vol. 1921. Springer-Verlag . [10] Goldkuhl, G. (2006). Action and media in interorganizational interaction. ACM 49(5), pp.53-57. [11] Gray, H.P. (1982) Macroeconomic theories of foreign direct investment: An assessment, In. New Theories of the Multinational Enterprise. Ed. A.M. Rugman. London: Croom-Helm, pp.172-195. [12] Grönroos, Chr. (2008). Service Logic Revisited: Who Creates Value? And Who Co-Creates? European Management Review, 20 (4), 298-314

[13] Henkel, M., Johannesson, P., Perjons, E., and Zdravkovic, J. (2007) Value and Goal Driven Design of E-Services. In Proc. of the IEEE Int. Conference on E-Business Engineering (Icebe’07). IEEE Computer Society, Washington. [14] Hruby, P. (2006). Model-Driven Design of Software Applications with Business Patterns. Springer Verlag ISBN: 3540301542. [15] Kinderen, S. de and J. Gordijn. (2008) E3service: A model-based approach for generating needsdriven e-service bundles in a networked enterprise. In Proceedings of 16th European Conference on Information Systems. [16] Koka B.R. and J.E. Prescott (2002). Strategic alliances as social capital: a multidimensional view, Strategic Management Journal Vol. 23, pp. 795–816 [17] Lusch R.F., S. Vargo, G. Wessels (2008). Toward a conceptual foundation for service science: contributions from service-dominant logic. IBM Systems Journal. Vol.47(1), pp.5-14. [18] McCarthy W. E. (1982), The REA Accounting Model: A Generalized Framework for Accounting Systems in a Shared Data Environment. The Accounting Review. [19] Norman, R. and R. Ramirez (1993). From value chain to value constellation: Designing interactive strategy. Harvard Business Review, pp.65–77. [20] OASIS. Reference Model for Service Oriented Architecture 1.0.(2006) Available at http://www. oasisopen.org/committees/-download.php/19679/soarm-cs.pdf Last Accessed :23-07-2009 [21] Osterwalder A. (2004). The Business Model Ontology, Ph.D. thesis , HEC Lausanne. Available at http://www. hec.unil.ch/aosterwa/. Last Accessed 01-07-2007. [22] Prahalad C.K. and M.S. Krishnan (2008). In The New Age of Innovation: Driving Cocreated Value Through Global Networks. McGraw Hill. [23] Spohrer J., L. Anderson, N. Pass, T. Ager, (2008). Service-science and service-dominant logic. Otaga Forum 2. Available at http://marketing.otago.ac.nz/ events/OtagoForum/ Last Accessed: 23-07-2009 [24] Treacy M. and F. Wiersema (1995). In The Discipline of Market Leaders: Choose Your Customers, Narrow Your Focus, Dominate Your Market. Addison-Wesley . [25] Tsai W. and S. Ghosha, (1998). Social Capital and Value Creation: The Role of Intrafirm Networks. The Academy of Management Journal, Vol. 41(4), pp. 464-476. [26] UN/CEFACT Modelling Methodology (UMM) User Guide. (2003) Available at http://www.unece. org/cefact/umm/UMM_userguide_220606.pdf , Last Accessed 19-02-2008. [27] Vargo, S. L. and R. F. Lusch (2004): Evolving To a New Dominant Logic for Marketing. Journal of Marketing Vol.68,pp1-17. [28] Weigand H., Johannesson, P., Andersson, B., Bergholtz, M., Edirisuriya, A., Ilayperuma, T. (2006) On the Notion of Value Object. Proc. CAiSE’06, Springer, pp,321-335.

40

AIS Transactions on Enterprise Systems 1 (2009) Vol. 2

H. Weigand et. al.: Value Encounters: Modelling and Analyzing Co-creation of Value

[29] Weigand, H. et al (2007). Strategic Analysis Using Value Modeling-The c3-Value Approach. Proc. HICSS. pp 175 [30] Weigand H., Johannesson, P., Andersson, B., Bergholtz (2009). Value-based Service Modeling and Design: Toward a Unified View of Services. Proc. CAiSE’09, Springer, pp.410-424. [31] Weigand, H. Value Modeling for the Pragmatic Web – the Case of Social Advertising. Proc. I-Semantics, Graz, Austria, September 2009.

Hans Weigand Department of Information Systems and Management, University of Tilburg, P.O. Box 90153, 5000 LE Tilburg, The Netherlands. Email: H.Weigand@uvt.nl Phone: +31 13 466 2806 Hans Weigand is Associate Professor at the Dept of Information Management, Tilburg University. His research interests include communication modeling, value-based business modeling, and adaptive service-oriented architectures. Jeewanie Jayasinghe Arachchige Department of Information Systems and Management, University of Tilburg, P.O. Box 90153, 5000 LE Tilburg, The Netherlands. Email: J.JayasingheArachchig@uvt.nl Phone: +31 13 466 8201 Jeewanie Jayasinghe Arachchige is a PhD candidate at the Dept of Information Management, Tilburg University. Her research interests include value-based business modeling and value oriented service identification

I1867-7134 © GITO mbH

41
        
Top of page

Note to user

Dear user,

In response to current developments in the web technology used by the Goobi viewer, the software no longer supports your browser.

Please use one of the following browsers to display this page correctly.

Thank you.