TeAM YYePG Digitally signed by TeAM YYePG DN: cn=TeAM YYePG, c=US, o=TeAM YYePG, ou=TeAM YYePG, email=yyepg@msn.com Reason: I attest to the accuracy and integrity of this document Date: 2005.01.13 12:34:20 +08'00' Service-Oriented Software System Engineering: Challenges and Practices Zoran Stojanovic Delft University of Technology, The Netherlands Ajantha Dahanayake Delft University of Technology, The Netherlands Hershey • London • Melbourne • Singapore IDEA GROUP PUBLISHING Acquisitions Editor: Mehdi Khosrow-Pour Senior Managing Editor: Jan Travers Managing Editor: Amanda Appicello Development Editor: Michele Rossi Copy Editor: April Schmidt Typesetter: Jennifer Wetzel Cover Design: Lisa Tosheff Printed at: Integrated Book Technology Published in the United States of America by Idea Group Publishing (an imprint of Idea Group Inc.) 701 E. Chocolate Avenue, Suite 200 Hershey PA 17033 Tel: 717-533-8845 Fax: 717-533-8661 E-mail: cust@idea-group.com Web site: http://www.idea-group.com and in the United Kingdom by Idea Group Publishing (an imprint of Idea Group Inc.) 3 Henrietta Street Covent Garden London WC2E 8LU Tel: 44 20 7240 0856 Fax: 44 20 7379 3313 Web site: http://www.eurospan.co.uk Copyright © 2005 by Idea Group Inc. All rights reserved. No part of this book may be repro- duced in any form or by any means, electronic or mechanical, including photocopying, without written permission from the publisher. Library of Congress Cataloging-in-Publication Data Service-oriented software system engineering : challenges and practices / Zoran Stojanovic and Ajantha Dahanayake, editors. p. cm. Includes bibliographical references and index. ISBN 1-59140-426-6 (h/c) ISBN 1-59140-427-4 (s/c) ISBN 1-59140-428-2 (ebook) 1. Software engineering. I. Stojanovic, Zoran, 1969- II. Dahanayake, Ajantha, 1954- QA76.758.S458 2004 005.1 dc22 2004021990 British Cataloguing in Publication Data A Cataloguing in Publication record for this book is available from the British Library. All work contributed to this book is new, previously-unpublished material. The views expressed in this book are those of the authors, but not necessarily of the publisher. Service-Oriented Software System Engineering: Challenges and Practices Table of Contents Preface vi Section I: Core Service Concepts and Technologies Chapter I Technical Concepts of Service Orientation 1 Humberto Cervantes, Laboratoire LSR Imag, France Richard S. Hall, Laboratoire LSR Imag, France Chapter II Beyond Application-Oriented Software Engineering: Service-Oriented Software Engineering (SOSE) 27 Jiehan Zhou, VTT Technical Research Centre of Finland, Embedded Software, Finland Eila Niemelä, VTT Technical Research Centre of Finland, Embedded Software, Finland Chapter III Service Composition: Concepts, Techniques, Tools and Trends 48 Boualem Benatallah, University of New South Wales, Australia Remco M. Dijkman, University of Twente, The Netherlands Marlon Dumas, Queensland University of Technology, Australia Zakaria Maamar, Zayed University, United Arab Emirates Section II: Service-Oriented Architecture Design and Development Chapter IV UniFrame: A Unified Framework for Developing Service-Oriented, Component-Based Distributed Software Systems 68 Andrew M. Olson, Indiana University Purdue University, USA Rajeev R. Raje, Indiana University Purdue University, USA Barrett R. Bryant, University of Alabama at Birmingham, USA Carol C. Burt, University of Alabama at Birmingham, USA Mikhail Auguston, Naval Postgraduate School, USA Chapter V Service-Oriented Design Process Using UML 88 Steve Latchem, Select Business Solutions Inc., Gloucester, UK David Piper, Select Business Solutions Inc., Gloucester, UK Chapter VI Service-Oriented Computing and the Model-Driven Architecture 109 Giacomo Piccinelli, University College London, UK James Skene, University College London, UK Chapter VII Service-Oriented Enterprise Architecture 132 Maarten W.A. Steen, Telematica Institute, The Netherlands Patrick Strating, Telematica Institute, The Netherlands Marc M. Lankhorst, Telematica Institute, The Netherlands Hugo W.L. ter Doest, Telematica Institute, The Netherlands Maria-Eugenia Iacob, Telematica Institute, The Netherlands Chapter VIII A Method for Formulating and Architecting Component- and Service-Oriented Systems 155 Gerald Kotonya, Lancaster University, UK John Hutchinson, Lancaster University, UK Benoit Bloin, Lancaster University, UK Chapter IX Architecture, Specification, and Design of Service-Oriented Systems 182 Jaroslav Král, Charles University, Czech Republic Michal Ž emli ka, Charles University, Czech Republic Chapter X Service Patterns for Enterprise Information Systems 201 Constantinos Constantinides, Concordia University, Canada George Roussos, University of London, UK Section III: Mobile Services and Agents Chapter XI Concepts and Operations of Two Research Projects on Web Services and Mobile Web Services 225 Zakaria Maamar, Zayed University, United Arab Emirates Chapter XII Service-Oriented Computing Imperatives in Ad Hoc Wireless Settings 247 Rohan Sen, Washington University in St. Louis, USA Radu Handorean, Washington University in St. Louis, USA č Gruia-Catalin Roman, Washington University in St. Louis, USA Christopher D. Gill, Washington University in St. Louis, USA Chapter XIII Service-Oriented Agents and Meta-Model Driven Implementation 270 Yinsheng Li, Fudan University, China Hamada Ghenniwa, University of West Ontario, Canada Weiming Shen, Fudan University, China Section IV: Security in Service-Oriented Systems Chapter XIV Security in Service-Oriented Architecture: Issues, Standards and Implementations 292 Srinivas Padmanabhuni, Software Engineering and Technology Labs, Infosys Technologies Limited, India Hemant Adarkar, Ness Technologies, India Chapter XV A Service-Based Approach for RBAC and MAC Security 317 Charles E. Phillips, Jr., United States Military Academy, West Point, USA Steven A. Demurjian, University of Connecticut, USA Thuong N. Doan, University of Connecticut, USA Keith H. Bessette, University of Connecticut, USA Section V: Service-Orientation in Practice Chapter XVI Engineering a Service-Oriented Architecture in E-Government 340 Marijn Janssen, Delft University of Technology, The Netherlands Chapter XVII Web Services for Groupware 353 Schahram Dustdar, Vienna University of Technology, Austria Harald Gall, University of Zurich, Switzerland Roman Schmidt, Swiss Federal Institute of Technology, Lausanne, Switzerland Chapter XVIII Building an Online Security System with Web Services 371 Richard Yi Ren Wu, University of Alberta, Canada Mahesh Subramanium, Oregon State University, USA About the Editors 398 About the Authors 399 Index 410 Preface vi Components and Web Services Modern enterprises are caught in the flux of rapid and often unpredictable changes in business and information technology (IT). New business demands caused by an enterprise’s need to be competitive in the market require the immediate support of advanced IT solutions. At the same time, new IT opportunities and achievements are constantly emerging and must be rapidly adopted to support new and more effective ways of conducting business. Therefore, it is crucial to provide effective business/IT alignment in terms of producing high quality and flexible IT solutions within a short time-to-market that exactly match business functionality needs and change as business changes. During the last few years, there has been a growing consensus in the industry that the way to create these adaptive, business-driven IT solutions is to use discrete building blocks of software, which are based on industry-standard protocols and interoperate across platforms and programming languages. Component-based development (CBD) (Brown & Wallnau, 1998) and then Web ser- vices (Barry, 2003) have been proposed as ways to build complex but adaptive and agile enterprise information systems that provide effective inter- and intra-enterprise inte- gration. The CBD platforms and technologies, such as CORBA Components, Sun’s Enterprise Java Beans (EJB), and Microsoft’s COM+/.NET, are now de facto standards in complex Web-based systems development. Further, a growing interest in Web ser- vices has resulted in a number of industry initiatives to provide platform-independent communication of software resources across the Internet (W3C, 2004). Basic elements of the new Web services paradigm are the standards for interoperability — XML, SOAP, WSDL and UDDI (Newcomer, 2002). On top of this basic interoperability protocol stack, new languages and specifications for defining the composition of services to form real- world business processes have emerged, such as Business Process Execution Lan- guage for Web Services (BPEL4WS) (BPEL, 2003) and Web Service Choreography Interface (WSCI) (Arkin et al., 2002). Using this advanced technology, the Internet, once solely a repository of various kinds of information, is now evolving into a provider of a variety of business services and applications. Using Web services technology, organizations are now provided with a way to expose their core business processes on the Internet as a collection of services. vii Customers and business partners are potentially able to invoke and retrieve these services over the Internet and compose them as wished to achieve their business goals. This idea of a software application as a service was recognized in the past (as in Brown, 2000), but it can now be fully realized using the Web services technology for systems interoperability (Newcomer, 2002). Web services can be considered the tech- nological foundation for the service-oriented computing paradigm. The W3C’s Web Services Architecture Working Group in its Web Services Glossary (2004) defines a Web service as: a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine- processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards. Is Technology Enough? A common point for both CBD and Web services paradigms is that they are technology led, that is, they were originally introduced through the new technology standards, infrastructures, and tools. Although technology is essential in building complex IT solutions from components and services, it is not sufficient on its own to support the full extent of an enterprise’s business and IT requirements. Application functionality is routinely “packaged” into components today; however, the essential design and de- velopment methods and processes that enable application adaptability, widespread reuse, and commercialization still have little acceptance (Stojanovic, Dahanayake & Sol, 2004). As using component middleware technology does not ensure that one will achieve the promised benefits of the CBD approach, conversely, the CBD paradigm can be success- fully employed without using component middleware technology. A similar issue now arises in the case of Web services. The standards and protocols for Web services are well established and increasingly used. However, developing a coherent set of design and process principles for engineering service-oriented solutions throughout the de- velopment life cycle, which is crucial for achieving the full benefits of service orienta- tion, is still at an immature stage (Kaye, 2003). As there is more to CBD than packaging software into Java Beans or .NET components, there is more to service orientation than simply rendering interfaces of software entities as Web services. Another critical issue in today’s enterprise IT developments is that the available set of technologies for components, Web services and business process automation, orches- tration and integration is complex and constantly evolving. This can cause problems whenever new versions of technology standards and interoperability protocols appear. Moreover, developing systems directly using these technologies is tedious, complex, and error prone. viii Therefore, the real challenge lies not just in new technology but also in how best to make use of the available technology through systems engineering principles and prac- tices, from service identification and specification to service deployment. Applying well-defined design and engineering methods and techniques ensures that we do not end up with a random collection of unusable, although technologically feasible, ser- vices. Equally important is a conceptual service model that provides a precise defini- tion of the underlying concepts used in service-oriented computing including service, component, interface, collaboration, port, and so forth. Further, we need to develop systems to a higher level of abstraction that make a devel- opment process more productive, flexible, and understandable for business people who define requirements, use the solutions, and decide about future strategies. There is a strong need for service-oriented modeling, design and development methods, and techniques that will map high-level business requirements to software technology imple- mentation and bridge the gap between business and IT (Apperly et al., 2003; Atkinson et al., 2002; Herzum & Sims, 2000). To make components and Web services a prominent and mainstream paradigm in building enterprise-scale information systems, well-de- fined engineering principles and techniques are required to maximize the benefits of service orientation and plug-and-play mechanisms. The idea of software systems as the collaboration and coordination of components that provide services represents an interesting perspective with a number of new software engineering challenges. Service-oriented software engineering (SOSE) is concerned with theories, principles, methods, and tools for building enterprise-scale solutions as the collaboration of loosely-coupled application services that provide particular busi- ness functionality and are distributed within and across organizational boundaries. Important topics that need to be addressed within the SOSE paradigm include but are not limited to: • precise definitions of service-related concepts that are applicable throughout the development life cycle, specified at the level of analysis and design, and success- fully refined into implementation and deployment artifacts. • standard modeling and specification notations for representing service concepts in graphical, human-understandable, and/or machine-readable formats. • development methods and processes based on service-oriented and component- based ways of thinking, organized around the concepts of service and compo- nent. • the way of designing the service-oriented enterprise system architecture from various perspectives and viewpoints that reflect the needs of various stakehold- ers. • deployment of the service-oriented system architecture onto available technol- ogy infrastructure. Engineering service-oriented solutions need to address the concerns of both the ser- vice provider and the service consumer. From the service provider perspective, it is important to define what component of the system can be exposed as a service, offering a business value to the consumer, and at the same time is, as much as possible, decoupled ix from the rest of the system. From the service consumer perspective, it is important to determine what part of the system logical architecture can be realized by invoking a particular service over the Web and how that part can interface with the existing organization’s system services and components. Balancing the needs of service pro- vider and consumer is crucial to achieving the true benefits of service orientation for business agility and inter- and intra-enterprise integration. Principles of Service Orientation The central point of the SOSE paradigm is the concept of service, as well as the strategy to expose system capabilities to consumers as services through the Service-Oriented Architecture (SOA). In this respect, the Web services technology is just a way to efficiently realize the concepts of services and SOA. The service forms a contractual agreement between provider and consumer. Besides a common interface that defines operation signatures, a service can also have attributes of its own, such as service level agreement, policies, dependencies, and so forth. A service interface defines a contract and the parties’ obligations precisely and, thus, allows the consumer to use the functionality offered without being aware of the under- lying implementation. As defined by the W3C’s Web Services Glossary (2004), a ser- vice is “an abstract resource that represents a capability of performing tasks that form a coherent functionality from the point of view of providers entities and requesters entities. To be used, a service must be realized by a concrete provider agent.” There are actually a number of parallels between service orientation and classical CBD. Like components, services represent natural building blocks that allow us to organize the capabilities of a system in ways that are meaningful to the user of the system. Similar to components, a service combines information and behavior, hides the internal workings from the outside perspective, and presents a relatively simple interface to the environ- ment (Kaye, 2003). When using Web services technology, the component itself is not acquired in the traditional manner of taking a copy and executing it in the house but rather just the services provided by the component are consumed via the Web while the component executes its function at a single location, available to all who subscribe (Newcomer, 2002). In its essence, SOA is a way of designing a software system to provide services to either end-user applications or to other services through published and discoverable interfaces (Kaye, 2003). As defined by the W3C’s Web Services Glossary (2004), SOA is “a set of components which can be invoked and whose interfaces descriptions can be published and discovered.” A basis of SOA is the concept of service as a functional representation of a real-world business activity that is meaningful to the end user and encapsulated in a software solution. Using the analogy between the concept of service and business process, SOA provides for loosely coupled services to be orchestrated into business processes that support business goals. Initiatives similar to SOA were proposed in the past, such as CORBA or Microsoft’s DCOM. What is new about SOA is that it relies on universally accepted standards like XML and SOAP to provide broad interoperability among different vendors’ solutions, and it is based on the proven component-based design principles and techniques. [...]... formulate and design component- and service- oriented systems The software engineering method is capable of balancing aspects of requirements with business concerns and the architectural assumptions and capabilities embodied in software components and services Král and Žemlička (Chapter IX) discuss the crucial elements of the requirements specification of service- oriented software systems as well as the relation... abstraction between the business and the technology The dynamic relationships between the needs of the business and the available services, on the one hand, and the technology foundation that realizes and supports the services, on the other hand, must be well understood and designed Therefore, one of the main tasks of new service- oriented software engineering concepts and principles is to help achieve... between the requirements specification and the architecture of these systems The chapter shows that there are several variants of service- oriented software systems having different application domains, user properties, development processes, and software engineering properties Constantinides and Roussos (Chapter X) introduce service patterns for service- oriented enterprise systems The authors argue that the... 6 Cervantes and Hall Figure 2 Actors of the service- oriented interaction pattern Service Registry publish/remove +publish(:ServiceDescription,:ServiceProvider) +remove(:ServiceDescription,:ServiceProvider) discover +discover(:ServiceDescription) Service Provider +bind():ServiceObject Service Requester 0 * bind 0 * +release(:ServiceObject) The basic interaction pattern that characterizes service orientation... (Peltz, 2003) A service composition is written in terms of service interfaces and is considered abstract until execution time, when service providers are discovered and bound Service compositions must handle issues relating to service discovery and service dynamics With respect to service discovery, these issues include service availability, requester-side filtering (see next subsection), and lack of knowledge... describing services • Service discovery: the operations provided to service requesters to discover and bind with service providers as well as registry-side filtering mechanisms • Service object creation policies: the policies used by a service provider when creating service objects Service publication: the operations provided by the service registry so that service providers and requesters can publish and. .. revokeService, respectively When a service is published, only the name of the service and a reference to the service provider is submitted to the service registry • Service discovery: JavaBeans Context offers an operation, called hasService, to allow a service requester to test for the availability of a service and an operation, called getService, to bind a service requester with the service provider During binding,... in component orientation and to illustrate how they are realized The technical presentation is followed by a survey of several service- oriented platform technologies including CORBA Traders, JavaBeans Context, Jini, OSGi, and Web services Zhou and Niemelä (Chapter II) introduce service- oriented software engineering as an advanced software development The authors present SOSE software development methodology... JavaBeans Context’s service- oriented characteristics: • Service description: In JavaBeans Context (Figure 5), a service is described as a Java class or interface Since only one service provider per service can be registered, there is no support for properties that allow service providers to be differentiated • Service publication: The publish and revoke operations are named addService and revokeService, respectively... mobility of hosts, and logical mobility of code The authors examine the imperatives for a viable service- oriented computing framework in ad hoc wireless settings Li et al (Chapter XIII) propose service- oriented agents (SOAs) to unify Web services and software agents Web services features can be well realized through introducing sophisticated software modeling and interaction behaviors of software agents . publisher. Service- Oriented Software System Engineering: Challenges and Practices Table of Contents Preface vi Section I: Core Service Concepts and Technologies Chapter I Technical Concepts of Service. Cataloging-in-Publication Data Service- oriented software system engineering : challenges and practices / Zoran Stojanovic and Ajantha Dahanayake, editors. p. cm. Includes bibliographical references and index. . II Beyond Application -Oriented Software Engineering: Service- Oriented Software Engineering (SOSE) 27 Jiehan Zhou, VTT Technical Research Centre of Finland, Embedded Software, Finland Eila Niemelä,