Web Services Technology

Web Services Technology

Design, Implementation and Evaluation

Ting Li

Web Services Technology

Design, Implementation and Evaluation

Master of Science Thesis

Ting Li

June 2002

Supervisor: Dr. Erik Rongen (IBM)

Arjan de Mes (IBM)

Prof. Peter Sloot (UvA)

Architecture Technology & Innovation, IBM The Netherlands

Section Computational Science, Universiteit van Amsterdam, The Netherlands

i

Table of Contents TABLE OF CONTENTS ...............................................................................................................I TABLE OF FIGURES.................................................................................................................IV ABSTRACT................................................................................................................................... V ACKNOWLEDGEMENTS ........................................................................................................VI CHAPTER 1 INTRODUCTION.................................................................................................. 1

1.1 Motivation ...................................................................................................................... 1 1.2 Problem Statement ......................................................................................................... 3 1.3 Objectives....................................................................................................................... 4 1.4 Organization ................................................................................................................... 5

CHAPTER 2 WEB SERVICES AND RELATED WORKS ..................................................... 6

2.1 What Are Web Services? ............................................................................................... 6 2.2 Web Services Model ...................................................................................................... 7

2.2.1 Communication Evolution ......................................................................................... 7 2.2.2 Web Services Component Roles and Operations....................................................... 8

2.3 Web Services Standards ............................................................................................... 10 2.3.1 HTTP and XML - eXtensible Markup Language .................................................... 10 2.3.2 SOAP -- Simple Object Access Protocol ................................................................. 10 2.3.3 UDDI – Universal Discovery Description and Integration...................................... 11 2.3.4 WSDL – Web Services Description Language........................................................ 13 2.3.5 Conceptual Architecture Stack................................................................................. 15

2.4 Web Services Technical Added Values ....................................................................... 16 2.4.1 Web Services Advantage ......................................................................................... 16 2.4.2 Business-to-Business Scenarios ............................................................................... 17 2.4.3 Distributed Computing Scenario.............................................................................. 17

2.5 Background and Related Work .................................................................................... 18 2.5.1 Peer-to-Peer Computing........................................................................................... 18 2.5.2 Object-Middleware .................................................................................................. 19 2.5.3 JINI Technology ...................................................................................................... 21 2.5.4 Grid Computing ....................................................................................................... 21

CHAPTER 3 WEB SERVICES APPLICATION DEVELOPMENT AND PROTOTYPE. 22

3.1 Introduction to Prototype.............................................................................................. 22 3.1.1 Motivation of A Scenario......................................................................................... 22 3.1.2 The Prototype: Travis Theme Trips ......................................................................... 23 3.1.3 A User Scenario ....................................................................................................... 24

3.2 Design Activities .......................................................................................................... 25 3.2.1 Conceptual Design ................................................................................................... 25 3.2.2 Architecture Design ................................................................................................. 26 3.2.3 Tool Assessment ...................................................................................................... 30 3.2.4 Software and Hardware Development Setup ........................................................... 31

3.3 Implementation............................................................................................................. 32 3.3.1 System Implementation Overview........................................................................... 32

3.3.2 Development ............................................................................................................ 32 3.3.3 Static Binding vs. Dynamic Binding........................................................................ 34 3.3.4 Process Step-by-Step................................................................................................ 36

3.4 Discussion .................................................................................................................... 38 3.4.1 Encoding Styles and Mapping ................................................................................. 38 3.4.2 About UDDI Registry .............................................................................................. 39 3.4.3 Limitations ............................................................................................................... 40

CHAPTER 4 SECURITY ........................................................................................................... 41

4.1 Motivation .................................................................................................................... 41 4.1.1 Seven Aspects of Security........................................................................................ 42 4.1.2 Web Services Complexity........................................................................................ 42

4.2 Functional Requirements.............................................................................................. 43 4.2.1 Between Provider and Requester ............................................................................. 43 4.2.2 UDDI Interaction ..................................................................................................... 43 4.2.3 Administrative Secure Groups ................................................................................. 43

4.3 Related Efforts and Implementation............................................................................. 45 4.4 Web Services Security Model ...................................................................................... 46

4.4.1 Web Services Security Token Model....................................................................... 46 4.4.2 Static Binding........................................................................................................... 47 4.4.3 Dynamic Binding ..................................................................................................... 51

4.5 Gap Analysis ................................................................................................................ 53 4.6 Summary and Comments ............................................................................................. 54

CHAPTER 5 PERFORMANCE TESTING.............................................................................. 55

5.1 Motivation .................................................................................................................... 55 5.2 Method ......................................................................................................................... 55 5.3 Pre-Analysis of Performance Components .................................................................. 56

5.3.1 Client performance................................................................................................... 57 5.3.2 Network performance .............................................................................................. 57 5.3.3 Server performance .................................................................................................. 58 5.3.4 Communication overhead ........................................................................................ 58 5.3.5 Software and Hardware Testbed .............................................................................. 58 5.3.6 Performance Test Tool............................................................................................. 59

5.4 Testing Result and Discussion ..................................................................................... 60 5.4.1 “Equilibrium” Test................................................................................................... 60 5.4.2 Static Binding Test................................................................................................... 61 5.4.3 Dynamic Binding Test ............................................................................................. 64

5.5 Discussion .................................................................................................................... 68 5.5.1 XML-based Scheme vs. Binary-based..................................................................... 68 5.5.2 Performance Tuning................................................................................................. 69 5.5.3 Highlight Issues........................................................................................................ 69 5.5.4 Improvement ............................................................................................................ 70

CHAPTER 6 WEB SERVICES AND GRID COMPUTING .................................................. 72

6.1. Grid Computing Overview........................................................................................... 72 6.2. Grid Services ................................................................................................................ 73 6.3. What Can Web Services Bring to Grid Computing?.................................................... 74 6.4. Contribution and Limitation to Scientific Computing.................................................. 76 6.5. Future Research............................................................................................................ 77

CHAPTER 7 CONCLUSIONS AND FUTURE DIRECTIONS ............................................. 78 7.1 Summary ...................................................................................................................... 78 7.2 Conclusions .................................................................................................................. 79 7.3 Future Directions.......................................................................................................... 80

7.3.1 Accounting............................................................................................................... 80 7.3.2 Composed Web Services ......................................................................................... 80 7.3.3 Other Security Aspects............................................................................................. 81 7.3.4 Performance Enhancement ...................................................................................... 81 7.3.5 Computing as a Utility ............................................................................................. 81

APPENDIX A ABBREVIATIONS USED IN THE THESIS................................................... 82 REFERENCE............................................................................................................................... 83

iv

Table of Figures Figure 1: Communication Evolution ............................................................................................... 7 Figure 2: Web Services Model ........................................................................................................ 8 Figure 3: The UDDI Registry Structure......................................................................................... 12 Figure 4: WSDL Documents Types............................................................................................... 13 Figure 5: An Overview of the mapping from WSDL to UDDI..................................................... 14 Figure 6: Conceptual Architecture Stack....................................................................................... 15 Figure 7: Theme Selection Panel ................................................................................................... 23 Figure 8: Travis Prototype Design Flow Diagram......................................................................... 24 Figure 9: Travis Prototype Design Flow Diagram......................................................................... 26 Figure 10: Travis Prototype Architecture Overview ..................................................................... 28 Figure 11: Model-View-Controller Design Pattern ....................................................................... 29 Figure 12: Web Services Development and Runtime Information Flow....................................... 33 Figure 13: Flight Reservation Panel .............................................................................................. 35 Figure 14: Stage 1 – Statically Bound Web Services Invocation .................................................. 36 Figure 15: Stage 2 – Dynamic Lookup of Web Services in The UDDI Registry.......................... 37 Figure 16: Mapping for a Web Service ......................................................................................... 38 Figure 17: Web Services Security Token Services Model ............................................................ 47 Figure 18: Web Services Security and Existing Transport Security Mechanism.......................... 48 Figure 19: Authentication by Trust Party ...................................................................................... 48 Figure 20: Firewall Processing SOAP Message ............................................................................ 49 Figure 21: Business Policy Enforcement....................................................................................... 50 Figure 22: UDDI Operator Node Trust and Policy........................................................................ 51 Figure 23: Dynamic Web Services Security Token Services Model............................................. 52 Figure 24: Performance Test Component on Dynamic Web Services .......................................... 57 Figure 25: Scalability for Static Binding ....................................................................................... 61 Figure 26: Static Binding Performance Breakdown ...................................................................... 62 Figure 27: Partial Breakdown for Static Binding (SOAP, Network, XML, others) ...................... 63 Figure 28: Scalability for Dynamic Binding.................................................................................. 64 Figure 29: Comparison Static Binding vs. Dynamic Binding ....................................................... 65 Figure 30: Dynamic Binding Performance Breakdown................................................................. 66 Figure 31: Partial Breakdown for Dynamic Binding (SOAP, UDDI, Network, XML, Others).... 67

v

Abstract Web Services are an XML based set of standards and technologies to integrate software application systems using Internet technology. Key element is the capability to publish, find and bind Web Services through public or private registries. Web Services are the latest development in distributed computing on the Internet and are a new, pervasive kind of middleware designed to integrate software systems of a very wide variety. The work presented in this paper describes Web Services standards, technologies and related works. It proposes an approach to dynamic integration for applications built using Web Services technology. It realizes this approach with a design, implementation and evaluation of a demonstrated prototype, which integrates multiple, geographically distributed services using both static binding and dynamic binding. The thesis addresses some aspects of security issues and proposes a security token model. It demonstrates some performance issues by measuring scalability, finding bottleneck of Web Services communication, and minimizing the impact on application execution based on the prototype. It discusses Web Services contribution to Grid computing and scientific computing.

Acknowledgements This thesis describes the result of a Master of Science assignment at IBM. This assignment has been carried out from September 2001 to May 2002 at Architecture Technology & Innovation group in IBM, location in Uithoorn, the Netherlands, by completing the master degree in Computer Science in the Section of Computational Science (SCS) group in Universiteit van Amsterdam (UvA). Parts of the work presented in this thesis (e.g. prototype) have been demonstrated in both IBM internal [68] and external [66] presentations. Parts have been described in a seminar paper [67] and in IBM’s White Paper [4]. I am grateful to people who have contributed towards shaping this thesis. At the outset, I would like to express my appreciation to dr. Erik Rongen (IBM) for his advice during my master research endeavor for the past eight months. As my supervisor, he has constantly enforced me to be in focus towards achieving the goal. His observation and comments helped me to establish the overall direction of the research and move forward with investigation in depth. He has been the greatest helping hand and a source of knowledge with real world programming skills specifically in Java! I would like to thank my supervisors drs. Arjan de Mes (IBM) who helped me to start my master research in IBM with a smile. He generously shared his time and knowledge in my work. He plays a major role in making me understand the concept and coaching me on thesis writing. I greatly appreciate my supervisor Prof. Peter Sloot (UvA) for his critical comments and suggestion during the initial phases of thesis work, and for his generous time in proof reading. I would like to thank my colleagues at IBM for the pleasant working environment, for helping me solve various problems and for sharing their knowledge that influenced the work and resulted in a satisfactory result. I acknowledge people at the university and many friends that have made this two-year stay in Amsterdam so gezellig. Last, but not least, I would like to dedicate this thesis to my family in China, for their love, patience, and understanding. Ting Li Amsterdam, June 2002.

Chapter 1 Introduction

Chapter 1 Introduction This chapter presents the motivation, the objectives, and the structure of this thesis. It identifies the relevance of Web Services and draws attention to the support of Web Services in system integration context. This chapter is further structured as follows: Section 1.1 gives motivation for this research; Section 1.2 examines the research problems; Section 1.3 states the objectives of this thesis and Section 1.4 outlines the structure of this thesis by presenting an overview of the chapters.

1.1 Motivation Distributed computing systems have been in widespread use for many years in research, engineering, industrial and commercial environments. The challenge of distributed computing is to take computing resources that are scattered all over the place to integrate, manage and take advantage of them as if they were one huge, virtual computer. In the traditional distributed computing environment, moving data between different applications and systems often involves defining a rigid format that is agreed under the discussion; depending on private networks that connect multiple parties; requiring to fit the new software design to the old development framework; hardly building inter-organizational collaboration; and resulting in duplicate work in different places. This tight coupling requires much agreement and shared context among different applications from different organizations in order to be communicable and reliable. Furthermore, the use of distributed computing systems requires high availability, adaptability, and maintainability, and, in order to remain useful, they have to cope with advances in technology, modifications of their operating environment and ever-changing human needs [25]. Current distributed computing technologies do not address the concerns and requirements just listed. For example, current Internet technologies address communication and information exchange among computers but do not provide integrated approaches. Enterprise distributed computer technologies such as CORBA and DCOM enable resource sharing, but most of case implementing only within a single organization [1]. The Open Group’s Distributed Computing Environment (DCE) supports secure resource sharing across sites, but people can easily find it inflexible. Emerging “Distributed Computing” companies seek to harness idle computers on an international scale, but support only highly centralized access to those resource [15, 23, 45, 47]. This comparison will be further discussed in Chapter 2 related work section. In summary, current technology either does not accommodate the range of resource types or does not provide the flexibility and control on sharing relationships needed to establish interoperability [30]. Some issues are more important than others are highlighted in the following:

• Increasing focus on interconnection. • Complexity of current platforms, capability, implementation and QoS. • Such problems have been for some time a central concern of the developers of distributed

systems for science, engineering and business activities.


In order to solve the problem, an appropriate solution must be proposed: create an adaptive, dynamic architecture model, which will enable interoperable collaboration, despite geographic and organizational boundaries; provide uniform access to computational resources, services and/or applications such as analytical tools, functional services and raw data; facilitate the within and across organizational application/system integration; expand the services available to all requesters. It is here that Web Services technologies enter the picture. Web Services have emerged as an important new field, distinguished from conventional distributed computing by its focus on a loosely-coupled, self-describing, modular applications that can be published, located and invoked based on a set of Web-enabled standards. Over the last two years, research and development efforts within the Web Services community have produced protocols, services and tools that address precisely the challenges that arise when seeking to build interoperable integration [14, 25]. And considerable progress has been made on the construction of such an infrastructure (e.g., [7, 59, 60, 61, 57]). Because of their focus on dynamic, cross-organizational integration, Web Services technology complement rather than compete with existing distributed computing technologies. The overall aim of the Web Services is to enable interoperability, enhance integrated problem solving in adaptive, dynamic and multi-institutional organizations. It focuses on allowing services, which can be composed of resources, systems, programs, applications, raw data, etc., to be published, found, and invoked by other applications at run-time, as well as design-time, language and operating systems independent [25]. During the process, all services can be encapsulated and provided to one another without knowing the underlying implementation. This facilitates the development of distributed applications by providing distribution transparencies to application developers, and shielding the developer from the heterogeneity of operating systems and communication systems. More detail will be examined in Chapter 1.


1.2 Problem Statement The interoperable collaboration and integration aspects of Web Services listed in Section 1.1 provide the main feature of this new distributed computing model. There are many challenges that have to be met, many of which are related to the open, hostile environment in which they must survive. Key among these challenges, both in scientific and business domain, is the design and development of these services that addresses architecture, discovery, reliability, security, scalability, performance, manageability, and accountability for interactive consistent access. Here are some of the issues that will be examined in the rest of the thesis:

• Architecture. Existing integration approaches lack of flexibility because they follow a tight coupling approach. What is the appropriate architecture of Web Services technology? Regarding the discovery issues, how does a Web Service advertise itself for discovery by other services? How does Web Services technology compare to other distributed programming approaches? What are the typical usage scenarios for Web Services? These questions will be answered based on the literature study and related work.

• Maturity. How mature is Web Services technology? How to design, develop and implement Web Services in a defined scenario context? How do these Web Services related standards work and communicate? A prototype will be designed and developed in order to discover the feasibility.

• Security. What are the different Web Services security aspects? Can current security standards and implementations be used in Web Services model? How does a Web Service authenticate the using party and the other way around? How to keep the services integrity? Some preliminary discussions are addressing these questions.

• Performance. When a system is comprised of many Web Services whose location and qualities are potentially dynamic, testing and debugging takes on a whole new dimension. How to achieve predictable response times? Is there any obvious overhead in Web Services? Where is the bottleneck of the entire communication? How about the scalability with respect to multiple user scenarios?

• Applicability. Grid computing addresses a lot of attention at this moment in the scientific world. Due to its critical interoperability requirements, grid architectures are moving toward standard protocols and a service-based architecture. How Web Services can contribute to Grid computing? Or in more general, how Web Services can be used in scientific computing? Any limitations?

Questions listed above do not cover the entire picture of Web Services, issues as Quality of Services (QoS), administration, accounting/payment, resource management are also very critical, but are out of the scope of this thesis. It should be possible to create a society of Web Services where components collaborate with each other to achieve their own individual goals, with the properties of fault tolerant, massively parallel, distributed, well organized, self-repairing, designed in a layered fashion and designed out of simple components.


1.3 Objectives The Web Services problem stated in Section 1.2 may involve all levels (from hardware to the application) and all phases of software development (requirement to implementation). This thesis addresses the architecture of Web Services that run on top of the underlying protocols and infrastructure. More specifically, this thesis focuses on Internet based organizational services interoperability, collaboration and integration with open standards. Its main objectives are:

(1) To propose an approach to dynamic integration for applications/systems built using Web Services technology;

(2) To realize this approach with the design, implementation and evaluation of a prototype architecture, which integrate multiple, geographically distributed services using both static-binding and dynamic-binding;

(3) Security and performance issues are addressed that may arise during deployment and minimize the impact on application execution. The requirements imposed on the development process should be minimized;

(4) Relating Web Services to Grid computing and furthermore to scientific computing, to discuss their applicable areas, contributions and limitations.

These four objectives are used to answer the stated problems in sequence respectively. In this thesis, rather than focusing on the scientific and technical applications emphasized in [29], the discussion is mainly developed on business applications. This choice is made with believe that the same principles and mechanisms apply in both environments. Web Services should be applicable to a broad class of applications and should support a broad range of scientific research. The investigation of relation between scientific initiative Grid computing and business initiative Web Services has been defined and developed broadly [29]. The related issues will be addressed at the end of the thesis. The purpose of this thesis is to argue that the Web Services concept is indeed motivated by a real and specific problem and that there is an emerging, well-defined Web Services technology base that addresses significant aspects of this problem. This thesis does not focus on the design activities that are undertaken to obtain a running application or on its constituting parts. Neither does it intend to provide tools to support the description, testing and validation of prototype. It rather aims at the activities to be undertaken in order to apply a set of well-defined standards to a running application that proves the maturity of these standards, which enable the interoperability, collaboration and integration.


1.4 Organization The sequence of the chapters in this thesis reflects the order in which these issues have been dealt with throughout the research process. This thesis is structured as follows: Chapter 2 is the result of a literature study in the area of Web Services, and introduces some important terminology, definitions and concepts used to discuss about Web Services. Furthermore, it presents some of the current approaches to Web Services and compares these approaches. It also provides some background and discusses related work to Web Services, which discusses recent efforts in developing technologies that enable interoperability, together with the disadvantage and the future challenges. Chapter 3 presents architecture and implementation of the “Travis” prototype, which uses Web Services concept for integrating of multiple geographical distributed services using both static binding and dynamic binding. This prototype is used as a proof-of-concepts and as a platform to run performance experiments. Chapter 4 specifies preliminary problems and requirements of Web Services technology, discusses the current available security standards, which can be integrated and merged into Web Services security model. Furthermore, the gap between the existing security techniques and requirement to secure Web Services is discussed. Chapter 5 describes the performance measurements of the prototype and the existing elements. Different testing is given between static-binding and dynamic binding. The communication is broken down in order to show the bottleneck. The chapter defines the testing approach and presents the results. Chapter 6 addresses the benefits that Web Services can bring to the Grid computing and introduces Grid services concept. Furthermore, in particular, Web Services’ contribution to scientific computing and its limitation are discussed. Finally, Chapter 7 presents conclusions and provides directions for the future work.

Chapter 2 Web Services and Related Works

Chapter 2 Web Services and Related Works This chapter presents an overview of Web Services technologies with major emphasis on models and standards. It discusses some of the important technological advances that have led to the emergence of Web Services. It presents the current efforts and related technologies. Briefly followed by a survey of peer-to-peer computing and enterprise computing that address the similar problems and issues.

2.1 What Are Web Services? Web Services are an XML based set of standards to integrate software application systems using Internet technology. Key element is the capability to publish, find and bind Web Services through public or private registries. Both business services and the actual electronic integration of software services are described and made operationally available in a highly standardized method. Web Services are stated as the latest development in distributed computing on the Internet and are key in the product strategies of most if not all major software vendors today. Web Services are a new, pervasive kind of middleware designed to integrate software systems of a very wide variety [4]. Web Services are independent of specific programming languages or operating systems. Most important, Web Services rely on pre-existing transport technologies (such as HTTP) and standard data formatting techniques (such as XML) for their implementation. Thus this new emerging technology inherits both standards’ advantages and presents a new coupling model that supports loosely coupled collaborations. One of the main ideas behind Web Services is that applications of the future will be assembled from a collection of network-enabled services. As long as equivalent services are able to advertise themselves to the network in a standard and neutral way, an application could theoretically choose among alternative competing services based on its criteria.


2.2 Web Services Model

2.2.1 Communication Evolution The way of how participant computers communicate with each other takes place the following four-stage evolution as illustrated in figure 1.

Registry

Peer to Peer

Point to Point

PrivateExchange

One to Many

PublicExchange

Many to Many

Figure 1: Communication Evolution

• Point-to-point communication: namely, one-to-one communication, each single computer

talks to another predefined computer; • One-to-many: via a private exchange server, each computer can talk to many other

computers; this is usually taken place in one organization; • Many-to-many: via a public exchange server, a group of computers can talk to other

groups of computers. In the business domain, this is so-called Marketplace model via a broker.

• Peer-to-peer: such as Web Services model where communication is conducted by advertising themselves to the network, so that individual scattered computing nodes communicate with each under the help of private/public registry.


2.2.2 Web Services Component Roles and Operations There are three components in the Web Services architecture: service provider, service broker and service requester. These parties perform three fundamental operations: publish, find and bind (see Figure 2) [10]. These concepts are explained as following: (The standards being used in the operations will be explained in details in next section.)

ServiceRegistry

ServiceRequester

ServiceProvider

PublishWSDL + UDDI

FindWSDL + UDDI

BindSOAP

Figure 2: Web Services Model

Roles in Web Services architecture:

• Service provider. From a business perspective, this is the owner of the service. From an architecture perspective, this is the platform that hosts access to the service.

• Service requester. From a business perspective, this is the business entity that requires certain functions to be satisfied. From an architecture perspective, this is the application that is invoking or initiating an interaction with a service. A program or other Web Services can play this role.

• Service registry. This is a service description repository where service providers publish their service descriptions and service requester find services and obtain binding information.

Operations in Web Services architecture:

• Publish. In order to be accessible, a service description needs to be published so that the service requester can find it. The published information can vary from business entity, business description and service description.

• Find. The service requester retrieves a service description from the service registry in order to find the required business type. The find operation can be involved in two different phases for service requester: at design time to retrieve the service’s interface


description for program development, and at runtime to retrieve the service’s binding and location description for invocation.

• Bind. The service needs to be invoked. In the bind operation the service requester invokes or initiates an interaction with the service at runtime using the binding details in the service description.

In service-oriented architectures, service descriptions and metadata play a central role in maintaining a loose coupling between service requesters and service providers. The service description, published by the service provider, allows service requesters to bind to the service provider. The service requester obtains service descriptions through a variety of techniques, from the simple “e-mail me the service description” approach to techniques such as Microsoft’s DISCO [10] and sophisticated service registries like UDDI.


2.3 Web Services Standards

2.3.1 HTTP and XML - eXtensible Markup Language Research and industry has widely accepted HTTP, which is being used everywhere, on almost all platforms. This ubiquity makes HTTP a good choice for an interoperable transport mechanism. XML is becoming as ubiquitous as HTTP. It stands for eXtensible Markup Language, which provides a common language for exchange information. It is designed to provide more flexible and adaptable information identification. XML is actually a “meta-language” -- a language for describing languages -- that lets users design their own customized markup languages for different types of documents. Because XML is just text, any application can understand it as long as the application understands the character encoding in use. This makes XML a good choice for describing method invocations in a platform and language-neutral fashion. Combining HTTP and XML into a single solution gives a whole new level of interoperability. For example, lathered with SOAP that is discussed in next section, clients written in Microsoft Visual Basic can easily invoke CORBA services running on UNIX boxes, JavaScript clients can easily invoke code running on the mainframe, and Macintosh clients can start invoking Perl objects running on Linux. The list goes on. While some interoperability is achieved today through cross-platform bridges for specific technologies, once SOAP becomes standard, these linkage technologies will no longer be necessary.

2.3.2 SOAP -- Simple Object Access Protocol Simple Object Access Protocol (SOAP), also referred as Services Oriented Architecture Protocol (SOAP) is a network-neutral, lightweight protocol for exchanging of information in a decentralized, distributed environment [3]. SOAP is considered as one of the most important standards being used in Web Services for its flexible invoking of methods on servers, services, components and objects in a platform independent manner. SOAP combines the existing practice of using XML and HTTP as a method invocation mechanism. SOAP is a protocol that acts as glue between heterogeneous software components. If developer can agree on HTTP and XML, SOAP offers a mechanism for bridging competing technologies in a standard way. The main goal of SOAP is to facilitate interoperability, so that it is widely viewed as the backbone to a new generation of cross-platform cross-language distributed computing architecture of Web Services. SOAP is not just an alternative to HTTP and XML. It can potentially be used in combination with a variety of other packaging and protocol schemes besides HTTP: MIME packages to support attachments, SMTP for scalable asynchronous messaging without the need for special middleware and many others (e.g., MQSeries, MSMQ, JMS) [51]. SOAP consists of three parts: first, an envelope that defines a framework for describing what is in a message and how to process it; second, a set of encoding rules for expressing instances of application-defined data types; and third a convention for representing remote procedure calls and responses. SOAP supports two communication styles: one is Remote Procedure Call (RPC) -- synchronous invocation of operation returning a result, conceptually similar to other RPCs. This style is exploited by many Web Service tools and featured in many tutorials (e.g., [10]). Another


is message-oriented style. This style provides a lower layer of abstraction, and requires more programming work. Two concepts -- encoding and mapping -- in SOAP implementation need to be distinguished before moving to the next standard. In distributed computing environments, encoding defines how data values defined in application can be translated to and from protocol format. These translation steps are referred as serialization and deseralization, or, synonymously, marshalling and unmarshalling. For example, the protocol format for Web Services is XML, and service provider and requester are developed in Java. Thus, SOAP encoding tells the SOAP runtime environment how to translate from data structures constructed in Java into SOAP XML and vice versa. A mapping defines a ternary association between a qualified XML element name, a Java class name, and one of the encoding as introduced above. A mapping specifies how, under the given encoding, an incoming XML element with a fully qualified name is to be converted to a Java class and vice versa. Considerable progress is made in SOAP development. SOAP specification has been submitted to the World Wide Web Consortium (W3C) to propose the formation of a working group in the area of XML-based protocols [53]. SOAP 1.1, 1.2 together with SOAP4J (SOAP for Java API) is available from Apache [7]. The third generation of Apache SOAP (essentially Apache SOAP 3.0) Axis [62] is designed as open source. The intention is to create a more modular, more flexible, and higher-performing SOAP implementation, with speed, flexibility, component-oriented deployment and transport framework as its new features.

2.3.3 UDDI – Universal Discovery Description and Integration UDDI stands for Universal Discovery Description and Integration, which provides a mechanism to find available Web Services. UDDI creates a global, platform-independent, open framework to enable services provider and requester to discover each other, defines how they interact over the Web and share information in a global registry [58]. UDDI is a technical discovery layer, it defines: the structure for a registry of service providers and services; an API that can be used to access registries with this structure; and an organization and project defining this registry structure and its API. UDDI offers both a web-based user interface and a programmatic interface. The information provided in a UDDI registration consists of three components:

• White page, including address, contact, and known identifiers. • Yellow page, including industrial categorizations based on standard taxonomies. • Green page, for the technical information about services that are exposed by the business.

There are four primary data types in a UDDI registry: businessEntity, businessService, bindingTemplate, and tModel. Figure 3 shows the relationship between all of these data types.


• Bu

infide

• BuserSeser

• BiinfTh

• tMcatdothade

The use ofPortal UDTest bed Uthree publiHP and Macross all nto all. Theavailability UDDI is cfeatures wimplementorganizatiofor Web Se

Figure 3: The UDDI Registry Structure

sinessEntity are the “white and yellow pages” of the registry. It provides business ormation about a service provider such as business name, contacts, description, ntifiers and categories. sinessService are the “green pages” of the registry, which provides non technical vice information. This information includes the address to make contact with a Web rvice, as well as support for option information that can be used to describe both hosted vices and services that require additional values prior to invoking a service. ndingTemplate are the “green pages” of the registry, which contains service access ormation. It points to a service implementation description (e.g. via a URL) in WSDL. is entity sometimes also called access locator. odel is a technical fingerprint, holding metadata about type specifications as well as egorization information. Its attributes are key, name, optional description, URL. It es not contain detailed specifications about business services. It points to other sources t contain the service specifications. A tModel may point to a WSDL service interface

scription.

UDDI has been described in six ways, UDDI operator node, E-marketplace UDDI, DI, Partnership catalog UDDI, Internal enterprise application integration UDDI and DDI [51]. Currently, the most important form of UDDI is the public UDDI. There are c UDDI registries available at this moment, these registry nodes are operated by IBM, icrosoft, in which registration is free [58]. The operators replicate the registrations odes on a regular basis thus resulting in a complete set of registered records available

operators all support a common set of SOAP APIs that will ensure the integrity and of the information provided.

urrently supported by more than 310 companies, but not a standards body yet. Future ill address the ability to locate products and services, define Web Services

ation conventions and provide the ability to manage hierarchical business ns, communities and trade groups. The driving goal is to provide a public specification rvices interoperability.


2.3.4 WSDL – Web Services Description Language The Web Services Description Language (WSDL) is an XML-based interface definition language that provides a way to catalog and describe Web Services [59]. It is used to automate the details involved in applications communication. WSDL defines Web Services interface, Web Services access protocol (e.g. SOAP over HTTP) and Web Services contact endpoint (namely, Web Services URL). Compliant server applications support these interfaces, and client users can learn from the document how a service should be accessed. WSDL documents are divided into two types: service interfaces and service implementations (see Figure 4) [59], which are used in publishing and finding WSDL service descriptions in a UDDI Registry:

A service interfaportType, and biwill be used to imis used to describservice interfaceelements is not in The WSDL servservice implemeinterface. At leainterface documeservice interfacecontains two atargetNamespaceto reference the binding attributeinterface docume

Figure 4: WSDL Documents Types

ce is described by a WSDL document that contains the types, import, message, nding elements. A service interface contains the WSDL service definition that plement one or more services. It is an abstract definition of a Web Service, and e a specific type of service. A service interface document can reference another

document using an import element. Detailed explanation of all the document troduced here but can be found in [51].

ice implementation document will contain the import and service elements. A ntation document contains a description of a service that implements a service st one of the import elements will contain a reference to the WSDL service nt. A service implementation document can contain references to more than one document. The import element in a WSDL service implementation document ttributes. The namespace attribute value is a URL that matches the in the service interface document. The location attribute is a URL that is used WSDL document that contains the complete service interface definition. The on the port element contains a reference to a specific binding in the service nt.


The service interface document is developed and published by the service interface provider. The service implementation document is created and published by the service provider. The roles of the service interface provider and service provider are logically separate, but they can be the same business entity. Publishing and finding WSDL descriptions is explained and the mapping from WSDL to UDDI is examined (in Figure 5). A complete WSDL service description is a combination of a service interface and a service implementation document.

Since theregistry adefined udocumen When pubefore a The deveWSDL4Jexplaine

Figure 5: An Overview of the mapping from WSDL to UDDI

service interface represents a reusable definition of a service, it is published in a UDDI s a tModel. The service implementation describes instances of a service. Each instance is sing a WSDL service element. Each service element in a service implementation t is used to publish a UDDI businessService.

blishing a WSDL service description, a service interface must be published as a tModel service implementation is published as a businessService.

lopment of WSDL is fast growing, the specification (WSDL 1.1 Specification [59] and [61]), supported tooling (WSTK Toolkit [63], WSAD [10], WSDE [64], (will be

d in detail in Chapter 3), etc.) and articles and tutorials are all widely available.


2.3.5 Conceptual Architecture Stack Based on these emerging technologies, industry leaders are proposing more standards and specifications in the related area. Such as IBM proposed Web Services Flow Language (WSFL), which enables the same type of seamless integration across processes and transaction life cycles that make use of many Web Services [60]. Although existing standards and ongoing work are rapidly progressing, there are not yet any finished standards, as stated, SOAP and WSDL specifications have been proposed to the W3C. Other issues are currently investigated, such as Web Services management, QoS (Quality of Service), security and performance, where security addresses a big concern at this moment [25]. In order to have an insight of network-accessible Web Services, Web Services conceptual “Stack” can be seen as a good example to illustrate these standards as different layers (Figure 6) [25].

Figure 6: Conceptual Architecture Stack

Without going into much detail of the component of the stack, the intention here is to show that different de facto standards for comprising the Web Services architecture (XML, SOAP, WSDL, UDDI) complement each other nicely without depending unnecessarily on each other, but complete Web Services concept as a whole.


2.4 Web Services Technical Added Values

2.4.1 Web Services Advantage Web Services compliment the next generation of distributed systems. The reasons are briefly discussed below:

• Loosely coupled, self-describing interface abstraction. Derived from Service Oriented Architecture [25], for distributed heterogeneous system based on technology that is widely available on almost any conventional computer platform. In this respect Web Services are expected to succeed where tightly coupled and other distributed computing technologies have stopped. Web Services are in this sense a logical evolution of, and more pervasive than Component Based Software Architectures, where they do not require a specific component implementation technology, but basically just a standard self-describing (XML) interface on top of “any” implementation.

• Interoperability. Any Web Service can interact with any other Web Service. Thanks to

SOAP, the standard protocol supported by all of the major vendors (and most of the minor ones too). And because Web Services can be written in any language (even COBOL according to Microsoft [4]) and any platform, developers do not need to change their development environments in order to produce or consume Web Services.

• Ubiquity. Web Services could communicate using HTTP and XML, which are widely

acceptable. Therefore, any device, which supports these technologies, can both host and access Web Services. Coming years, they will present in phones, cars and even soda machines. Soda supplies getting low? No problem, the wireless-networked soda machine can contact the local supplier's Web Service and order more of your favorite beverage.

• Low barrier to Entry. The concept behind Web Services is easy to understand. And there

are a lot of free toolkits from vendors like IBM, Microsoft and Apache open source allow developers to quickly create and deploy Web Services. In addition, some of these toolkits allow pre-existing COM components and Java Beans to be easily exposed as Web Services.

• Industry Support. All of the major vendors are supporting SOAP and the surrounding

Web Services technology. For example, the Microsoft .NET platform supports Web Services, thereby making it very easy for components written in Visual Basic to be deployed as Web Services, and consumed by Web Services written using IBM VisualAge, and vice-versa.

• Comparable advantage. Comparing to other discussed standards that depend on open

widely adopted standards is just part of the solution; Web Services use HTTP to be firewall friendly and employs XML as an encoding schema. It offers a free versus fee value proposition with regard to HTTP/SOAP server environments versus ORB frameworks; uses the pervasive Internet concept of URLs to address object identification. As seen from the previous study, Web Services vendors are actually working actively to prove that SOAP implementations do interoperate. And SOAP format is self-describing contrast with CORBA and DCOM protocols, which are binary and tough to trace.


2.4.2 Business-to-Business Scenarios The following domains are expected to be among the early adopters of the Services Oriented Architecture (SOA) [10]:

• Enterprise application integration (EAI): Web Services give the architects of EAI solutions an additional design alternative. The message oriented SOAP communication style can be very useful to loosely couple IT systems.

• Portal and marketplaces: due to the hub architecture of such solutions, there is a strong need for non-browser clients to interact with Web sites.

• Business-to-Business (B2B): any B2B solution that needs systems to interact with each other is suitable for using the Services Oriented Architecture.

• A non-HTML client that needs to communicate with an application server can use SOAP rather than RMI/IIOP or other binary protocols to do so.

• COM to Java bridge: Web Services is language neutral: there are bridges both for Microsoft COM technology as well as for Java 2 Enterprise Edition (J2EE). Hence, mediator Web Services connecting these two worlds can be defined.

• Wireless devices: The functionality of wireless and mobile devices can be expected to be enhanced significantly from integration by Web Services, either directly at the service level itself, or, more probably, at the level of application or infrastructure services.

From the language option aspect, how do Web Services and J2EE relate to each other? Web Services provide a description of and access to server side functionality; J2EE is one implementation alternative for the Web Services requester and provider. Java is a good choice due to the availability of a wild range of APIs such as for XML, SOAP, UDDI, and WSDL. The power of the open source community working with Java benefits this approach.

2.4.3 Distributed Computing Scenario While Web Services are growing to the same domain as Peer-to-Peer computing and Grid computing are addressing, detailed discussion about these two concept and its relation with Web Services will be discussed in the later of the thesis. In order to demonstrate how Web Services can be used in the distributed computing, a possible scenario is described: On the SkatesTown factory floor, a new manufacturing robot is plugged into the computing infrastructure. After a short initialization period, it finds a controller, requests and receives a set of tasks, and starts working on them in coordination with all the other robots. On the same factory floor, as data from dealers, customers and suppliers comes in, it is processed and interpreted as requiring a change in specification of the bearings used on the model. The controller finds a design and simulation Web Service, submits new requirements, and receives updated specification. As soon as these come in, the robot tasks are updated, and new bearings are ordered. This is done by finding supplier Web Services, and combining them with shipping and insurance Web Services, making sure that the ordered materials arrive at the shipping dock in time for the manufacturing run.


2.5 Background and Related Work Recent efforts in peer-to-peer (P2P) computing and enterprise computing address problems and issues, which are equally valid in a Web Services environment. While Web Services technologies are currently distinct from other major technology trends, such as Internet, distributed object middleware, Grid computing, and peer-to-peer computing, Web Services technologies can benefit significantly from growing into the problem space addressed by these other trends, and certainly the other way applies as well.

2.5.1 Peer-to-Peer Computing Collaboration interoperating with each other on the Web Services are essentially peers interacting in a P2P network as discussed in the earlier communication evolution final stage. Peer-to-peer computing includes two kinds of sharing, first, as implemented in Internet communication and file/data sharing tools like Napster [45], Gnutella [23], and Freenet [31]; and second, as Internet computing as implemented by CPU sharing systems such as SETI@home (Search for Extraterrestrial Intelligence) [52], Parabon [47], and Entropia [15], are examples of more general sharing modalities and computational structures beyond traditional client-server systems. These types of distributed computing implementation can be interpreted as: harness the unused capacity of Internet-connected computers and make them available for working on computational intensive problems, which would otherwise require a super computer or workstation/server cluster to solve. The application area of these initiatives contains life science and financial services, which add the value, as maximizing ROI (Return On Investment) and utilizing the corporate PCs, accelerating research to super computer speed, dramatically shortening the time-to-discovery and accelerate critical analyses. These features characterize virtual organizations where information and resource sharing can take place among any subset of participants. These technologies and systems present a radical paradigm shift from client-server systems. These systems have so far focused entirely on vertically integrated solutions, rather than seeking to define common protocols that would allow for a shared infrastructure and interoperability, which Web Services are trying to achieve. Also the forms of sharing targeted by various applications are quite limited; for example, file sharing with no access control, computational sharing with a centralized server or multi-user text based collaboration. JXTA Technology [39] contains several open, generalized peer-to-peer protocols that allow any connected device on the network from cell phone to PDA from PC to server to communicate and collaborate in a peer-to-peer manner. The objective of the project is to build interoperable, platform independent and ubiquitous peer-to-peer computing. It differs from just mentioned peer-to-peer implementations and similar to the Web Services technology in its aiming at highest abstraction of a set of protocols use XML-encoded messages and can be implemented on top of TCP/IP, HTTP, Bluetooth and many other protocols. The similarity also exists in its being away from APIs and being programming independent. JXTA technology is still evolving and will soon be open-sourced and co-developed by many contributors [39]. Many of the protocols and the objectives defined by JXTA, are equally valid and significant in Web Services environments. These categories pretty much summarize the current development and use of peer-to-peer technology and examine the difference and similarity to Web Services.


At its core, P2P computing is a kind of service-oriented architecture in that it enables distributed computing through the loose coupling of systems, with emphasis on resource (instead of service) description and dynamic discovery. The major differences are not technical, but in terms of maturity. Although Web Services standards are maturing and their interoperability is being tested in open environments, P2P standards have been very slow to emerge, hindering their acceptance as a valid option for e-business. Eventually, however, both Web Services and P2P standards will clearly converge, especially when it comes to service description, dynamic discovery and security.

2.5.2 Object-Middleware The justification of this new Web Services distributed computing model is cross-platform and cross-programming language interoperability. These features are pretty much in the heart of Object Middleware concept, which is gaining wide acceptance as a generic software infrastructure for distributed computing systems. A large number of applications are designed and implemented as a set of collaborating objects using object middleware, such as CORBA [1, 43], Java/RMI [35] and DCOM [40]. Object middleware offers interaction support to application objects, which may be deployed in different computer nodes with a transparent manner to developers. It provides a uniform interaction pattern, independent of the underlying node and network technologies. As the term services characterized in Web Services context, from an abstract point of view, an object is an identifiable, encapsulated entity that provides services to other objects through its interface. The interface of an object shields the other objects from the internal characteristics of this object, like its internal data representation, algorithms or executable code. Web Services are often compared to classical remote procedure calls (RPCs) and distributed computing frameworks such as CORBA, DCOM, and J2EE. However, Web Services extend the concept of being another distributed computing or RPC mechanism. Web Services provide universal access; CORBA, DCOM and J2EE are implementation alternatives. As following, the shortcomings of previous solutions are analyzed and future requirements for successful solutions are proposed:

• Java/RMI: distributed method resolution mechanism in a Java-to-Java environment; integration is done at the binary level and not at a descriptive level over a multi-platform carrier mechanism. It can be used as an endpoint integration mechanism beyond Web Services. Or could be used as a carrier of messages in implementation. It has no bearing on the Web Services application developer and no lookup function available.

• DCOM/COM+: a distributed software component model and in some respects similar to

CORBA but of course Microsoft’s strategic middleware architecture for Windows. This is also a tight server/server or client/server integration architecture, without effective integration behavior or any descriptive abstraction support.

• CORBA/IIOP: shortened as Common Object Request Broker Architecture (CORBA)

relies on a protocol called the Internet Inter-ORB Protocol (IIOP), is the Object Management Group’s (OMG) specification for achieving interoperability between distributed computing nodes. The objective is to define an architecture that would allow heterogeneous environments to communicate at the object level regardless of who


designed the two endpoints for the distributive application. A CORBA object is represented to the outside world by an interface with a set of methods. The interaction between a client process and an object server are implemented as object-oriented RPC-style communications. Although CORBA has been implemented on various platforms, the reality is that any solution built on these protocols will be dependent on a single vendor’s implementation. Thus, if one were to develop a CORBA application, all participating nodes in the distributed application would have to be running the same ORB product. Now there are cases where CORBA ORBs from different vendors do interoperate. However, that interoperability does not extend into high-level services such as security and transaction management.

Table 1 gives an overview of some important differences between Web Services and the other technologies. (J2EE uses CORBA IIOP as transport protocol, so there is no J2EE column in the table.)

Technology CORBA DCOM Web Services Naming of

communication endpoints

Interoperable object reference (IOR)

OBJREF URL/URN

Underlying remoting protocol

Internet Inter-ORB Protocol (IIOP)

Object Remote Procedure Call (ORPC)

SOAP

Interfaces Multiple Multiple Multiple – WSDL

Payload type Binary Binary Text message Payload parameter

value format Common Data

Representation (CDR) Network Data

Representation (DR) XML

Server Address Resolution

Naming service (Directory) IP routing, URN

Message dispatch ID based ID based Namespace and parameter types

Client/Server coupling

Tight Tight Loose

Table 1: Differences between distributed computing technologies

The architectures of Java/RMI, DCOM and CORBA provide mechanisms for transparent invocation and accessing of remote distributed objects. Though the mechanisms that they employ to achieve remoting may be different, the approach each of them takes is more or less similar. Web Services programming model is not viewed as a reappearance or revitalization of CORBA or the others. Instead, it is seen as a new open solution that addresses the same distributed computing issue that CORBA addressed with the further objective of improving on some of CORBA’s shortcomings. Of course, CORBA also has many of the features Web Services support and many other more. The technology of Web Services offers a new programming model for building distributed applications using open Internet standards. This new distributed computing solution exploits the openness of specific Internet technologies to address many of the interoperability issues of CORBA.


2.5.3 JINI Technology The same as Web Services under the distributed computing umbrella, Jini network technology [65] is an innovative and usable technology for building reliable, fault-tolerant distributed applications. It provides a simple infrastructure for delivering services in a network and for creating spontaneous interaction between programs that use these services regardless of their hardware/software implementation. Jini is a Java Application Programming Interface (API) that implements protocols and mechanisms for service registrations and service lookups centered around the so-called Jini lookup service [37]. Any kind of network made up of services (applications, databases, servers, devices, information systems, mobile appliances, storage, printers, etc.) and clients (requesters of services) of those services can be easily assembled, disassembled, and maintained on the network using Jini Technology. How Jini technology works? By using objects that move around the network, the Jini architecture makes each service, as well as the entire network of services, adaptable to changes in the network. The Jini architecture specifies a way for clients and services to find each other on the network and to work together to get a task accomplished. Service providers supply clients with portable Java technology-based objects that give the client access to the service. This network interaction can use any type of networking technology such as RMI, CORBA, or SOAP, because the client only sees the Java technology-based object provided by the service and, subsequently, all network communication is confined to that Java object and the service from whence it came. When a service joins a network of Jini technology-enabled services and/or devices, it advertises itself by publishing a Java technology-based object that implements the service API. This object's implementation can work in any way the service chooses. The client finds services by looking for an object that supports the API. When it gets the service's published object, it will download any code it needs in order to talk to the service, thereby learning how to talk to the particular service implementation via the API. The programmer who implements the service chooses how to translate an API request into bits on the wire using RMI, CORBA, XML, or a private protocol. Jini infrastructure is a system architecture (hardware, software, and network) that supports the notion that a computing environment is a network-connected set of computing, storage, display, entertainment, communication, and IO devices. In a Jini system, devices can be added or subtracted, and doing so may alter some of the capabilities of the system, but it will not alter its identity or basic usability. Much similarity to Web Services model can be found in Jini architecture in terms of how Jini Technology works [37]. When a service joins a network of certain technology-enabled services and/or devices, it advertises itself by publishing its services that implements the service API. The client finds services by looking for them via lookup service. When it gets the service's published information, it will learn how to talk to the particular service implementation via the API.

2.5.4 Grid Computing This section is expanded as an individual part and discussed in Chapter 6.

Chapter 3 Web Services Application Development and Prototype

Chapter 3 Web Services Application Development and Prototype In order to validate the Web Services concept, prove the integration effectiveness of this distributed computing model, get hands-on experience with Web Services design and implementation, and evaluate IBM tools within Web Services context, a Web Services application prototype is developed and deployed. This chapter presents the design and implementation of “Travis”, a Web Services application prototype that characterizes the concept and contains some important features of Web Services. The scenario implemented in this prototype is a typical illustration of Web Services application integration. During design and development phases some interesting findings on the technology have been made. This prototype is also used as the infrastructure of performance evaluation, which will be discussed in chapter 5.

3.1 Introduction to Prototype

3.1.1 Motivation of A Scenario Before going into the technical implementation, the motivation of creating a scenario is introduced as following. The Travis traveling agent company is regularly finding itself in a situation where a customer requires a detailed planned trip with specific interest, flight schedule, lodging service, transport planning, additional book/equipment suggestion in one agent portal that would return satisfactory result. When such situations occur, Travis currently uses appropriate application from Central Flight (a national flight travel agency) and finds out if one of their regional flight companies has the preferable flight according to customers interest. After this flight schedule is confirmed, Travis has to start with lodging, transport, and extra services all over again by using separate application from each services companies respectively. This is a slow and time-consuming process, and Travis is experiencing spiraling costs while its agents’ daily operation expands. As a solution, it has been decided to use Web Services technology to provide an interface into all these flight, lodging, transport heterogeneous inquiry systems that provided by Central Flight, Central Lodging, Central Transport organizations. On one hand, this will help these organizations’ services to be easily discovered and invoked by traveling agent like Travis; on the other hand, this will facilitate Travis to integrate the entire traveling solution into one portal that can be used by its customers. Rather than replacing centralized various services, this solution will help to aggregate diverse decentralize services. Travis decides to get involved in the Web Services initiative, it is getting some WSDL files describing the new Web Services that offered by services provider organizations through UDDI registry based on its preference. Using the interface and implementation information provided in these WSDL files, Travis modifies its current traveling service system to include some additional services for its customer which enables searching the flight, lodging, transport systems if any detailed journey planning is required based on the themes Travis can suggest.


3.1.2 The Prototype: Travis Theme Trips Example: “I want to go on a cultural tour”, or “I want to see a coral reef”. Travis will present the possible themes that are available, and further selection will narrow down to one specific theme trip the customer is going to make. Based upon this selection, all kinds of additional services are offered, as mentioned in the previous section, flight reservation, hotel booking and car renting, but also theme specific offerings, such as the possibility to rent scuba gear if a scuba diving related experience is selected (e.g. “I want to see a coral reef”). Finally, when the customer has made the selection of all offerings/services, the entire package is created and all individual items are booked and paid. A screenshot of a Theme trip selection is taken as shown in Figure 7:

Figure 7: Theme Selection Panel

A clarification of terms used in the following description is introduced here: User is the person who uses web browser to access the Travis application from a technical perspective; customer is the person who contacts with Travis company and benefits from its offered services from a business perspective. For the simplicity, there is no distinction between these two terms while they are used in this thesis.


3.1.3 A User Scenario 1. The user arrives at the Travis web site using his web browser. He requests a list of possible

theme trips. The Travis web server passes this query to its own Web Services and returns the list of available themes to the web server (Travis company also offer theme selection based Web Services to other travel agencies). The web server makes a presentable page using the data received from the Travis Web Services and returns it to the user.

2. The user is interested in a specific theme: a Jungle Tour for instance. He selects this theme, and the selection is passed to the web server. The web server then queries the Web Service that had offered this theme for a list of possible destinations.

3. The user selects a specific destination: Aventura Amazonas in Ecuador. Step 1 is repeated but returning a list of details of the theme. Details include: a date range during which this theme applies, a rental car is recommended, additional transport is recommended, hotel is recommended. From the details, the web server creates an appropriate input form for the user to select the appropriate travel details.

4. The user fills in the details according to his own wishes, within the appropriate ranges provided. This information is returned to the web server. The web server then finds relevant information from UDDI registry and gets correspondent results, which can help to query airlines, hotels, and car rental Web Services to come up with a valid itinerary and trip price.

5. The user confirms the itinerary and price. The web server makes the bookings. The following figure 8 shows only the static binding and does not include the UDDI registry for the illustration reason. However, the implemented Travis application is more sophisticated and detailed explained in the later phases.

Browser (User) ThemeTrip Website

ThemeTripWeb Service

AirlineWeb Service

HotelWeb Service

CarWeb Service

homepagequery themes

select themequery destinations

select destinationquery details

select details query flight

query hotel

query all required resources for the trip

confirm details book flight

book hotel

book all required resources for the trip

All W eb Services should use dynamic binding.UDDI calls are not modelled here.

query car

book car

Figure 8: Travis Prototype Design Flow Diagram


3.2 Design Activities As introduced with the Web Services model in Chapter 2, Travis application prototype development is presented as three parts, services provider, services requester and services registry UDDI. These three roles are designed in a way that is able to reflect the feature of Web Services architecture, and implemented independently, which address different techniques requirement.

3.2.1 Conceptual Design The scenario has been described from a user’s point of view in the previous section. In order to give a clear picture of how the design activities started, the conceptual design is conducted before architecture design, which is divided into four steps and explained in more detail as following:

1. Local ThemeTrip inquiry: Develop a simple Web application that allows users to browse the themes currently in the ThemeTrip database. When theme is selected, optional destination together with sub-themes are presented as well. In order to demonstrate the Web Services concept, all these theme services and related sub-theme services are available and wrapped as Web Services and published in UDDI that can be found and used by other traveling agent.

2. Flight, Hotel, Car inquiry: The Flight, Hotel and Car inquiry Web Services are

designed, implemented and published in public UDDI that can be found and used by other organizations. These Web Services are offered by different service providers. In the prototype example, in particular, KLM airline, China airline, IBERIA airline, Sheraton hotel, Avis rental car Web Services are built.

3. Inquiry on flight, hotel, and car system: Travis incorporates offers from the other

companies through Web Services that built in the previous steps. As soon as a new service is available in the UDDI, Travis will be able to search and find it, consequently, combine its offerings into its package planning when appropriate. Because the Web Services are very loosely coupled to the Travis site, and can be dynamically discovered and bound at run time, Travis can offer dynamically created packages using services of service providers with whom Travis does not necessarily has tight relationship.

4. Travis prototype completion: Furthermore, additional GUI (Graphical User Interface)

modification for the completion of the entire prototype will be added. More advanced level functionality includes the single transaction to multiple services providers, rollback, etc., because of the time concern, can leave for the future research.

Because of the tool availability and development simplicity, Travis prototype demonstrated at IBM implements, in Java programming language, the Web Services interfaces and behaviors, with a SOAP/HTTP protocol binding for transport. The prototype also includes a graphical user interface to UDDI that supports the creation of, discovery of, access to, and deletion of Web Services.


3.2.2 Architecture Design

3.2.2.1 UML Modeling A Java class diagram hierarchy of the Travis prototype consists of major fields and operations is described in figure 9 below. It shows the static view of Travis application in terms of classes and relationships between the classes. The name of the class is derived from the scenario domain and tried to be as unambiguous as possible. The fields define the characteristics of the class and capture the information that describes and identifies the class; every attribute has a type, which specifies what kind of data it represents. Main methods besides normal getter and setter present major operations conducted by the objects. Classes can be related to each other through a number of relationships. The relationship association between classes is drawn as a solid line with different type of arrows and has a name representing the association. (see figure 9 in the next page)

Figure 9: Travis Prototype Design Flow Diagram

BookingbookingTitle : StringbookingID : Stringcategory : StringstartDateTime : DateendDateTime : Date

Flight Lodging Transport

Userlastname : Stringf irstname : Stringaddress : Stringcity : Stringpostcode : Stringstate : Stringgender : Stringbirthday : Datenationality : Stringlanguage : Stringe-mail : Stringphone : Integer

addReserv ation()remov eReserv ation()getReserv ations()

ThemethemeID : Integertitle : Stringdesc : StringimageURL : Stringinf o : String

Ordering

Book Souv enir

"Theme Trip" Java Class Design in UML

Reserv ationreserv ationID : Stringtitle : StringdeparturePlace : Stringarriv alPlace : StringstartDateTime : DateendDateTime : Dateconf irmed : Doubleconf irmStatus : String

addShoppingItem()remov eShoppingItem()getShoppingItem()conf irm()getPrice()

0..*

1

0..*

1

make

0..10..1isFor

ShoppingItembusinessName : StringbusineeDescription : Stringserv iceName : Stringserv iceDescription : StringimageURL : Stringserv iceKey : S tringserv iceContac t : Stringserv iceTy pe : Stringdiscov ery URL : Stringprice : Doublecurrency : Str ingconf irmed : Booleanpay ed : Boolean

conf irm()pay ()

0..*0..*contains

SubThemeCity : Stringcountry : StringstartDateTime : DateendDateTime : Date

0..*0..*

contains


28

3.2.2.2 Conceptual Architecture Design Figure 10 shows the conceptual system diagram of the components.

Figure 10: Travis Prototype Architecture Overview

• User’s web browser: this part is out of the classical Web Services model with three

components, but it is the initiator that starts using Travis. • Services provider: flight organizations, lodging organizations, transport organizations,

and theme services organizations are all designed as services provider, which can offer their implemented services to the third party, and are ready for registration. In figure 10 above, only KLM, Sheraton and Avis are listed as a representation of certain services type.

• Services requester: Travis, which behaves both as requester and provider; it offers theme inquiry services to the registry, which would be the case in real world practice.

• UDDI: in the Travis implementation, IBM UDDI registry review is used as private UDDI instead of public available UDDI. There are two reasons, first, performance achievement by using local network; second, avoidance of public access, which might influence demo and performance testing.

• Geographical distribution: three rectangles present the physical location of services provider, services requester and UDDI, which are distributed in three different servers.

• Operations are same as introduced in Web Services model, namely, find, register, and bind.

UDDIRegistry

Data Data

ati2.uit.nl.ibm.com

ati3.uit.nl.ibm.com

Prototype Travis Architecture

User WebBrowser

Browse

Data

Data

Data

FlightIBERIA WebServices

Flight ChinaAirline WebServicesFlight KLM

Register

LodgingSherraton

Hotel

Register

TransportAvis

Rental Car

Register

Theme

Register

Bind

Travis Bind

Bind

Bind

Find

Services Provider

Services Requester

User

UDDI Registry

Organization

ati15.uit.nl.ibm.com

Server


29

3.2.2.3 Model-View-Controller Design Pattern Model-View-Controller (MVC) design pattern consists of three kinds of objects. The Model is the application object, which exposes the business logic for a service; View is its screen presentation that renders the model; and Controller defines the behavior the user interface reacts to user input. In order to increase flexibility and reusability, MVC design pattern [13] decouples the functionality of an application into components that correspond to the data, the view of the data, and the control of the view and data. Specifically. The following Figure 11 shows the Travis prototype server side possible architecture using the MVC design pattern. In this architecture the servlet is in the role of the controller. The servlet receives and interprets the HTTP request. The servlet then works on the model, the resource, to perform the business logic and actually contacts with Web Services. The resulting data is then forwarded to the JSP for formatting the view. The resulting HTML or XML is returned to the browser with the HTTP response.

Browser HTTP Request

Forward

HTTPResponse

Data

Controller Model

View

InvokeWeb

Services

JSP

ResourceServlet

Figure 11: Model-View-Controller Design Pattern


30

3.2.2.4 Database Design The Travis application is based on a very simple database model. Data is stored in one database (using IBM DB2 7.0) for simplicity. Each service provider in the application, ThemeTrip, Flight, Lodging and Rental Car, has a set of tables. A theme table and a sub-theme table are illustrated as following. The sub-theme table points to the theme table though a foreign key. Theme ThemeID Title Desc imageURL info Integer Varchar(128) Varchar(128) Varchar(128) Varchar(128)

SubTheme ThemeID SubthemeID Title Desc ImageURL City Country Integer Integer Varchar

(128) Varchar (128)

Varchar (128)

Varchar (128)

Varchar (128)

A number of different data types are used in the tables for illustration of functionality in the application. The choices may not be appropriate for a real application.

3.2.3 Tool Assessment The following IBM tools support for building Web Services and have been assessed:

• WebSphere Studio Application Developer (WSAD) • Web Services ToolKit 2.4 (WSTK) • Web Services Development Environment 2.4 (WSDE)

One important aspect is ease of development and deployment of the application, both the Web Services and the Travis portal. All the products are assessed in currently available version (4Q 2001). All tools are briefly described as following:

• WSAD brings together most of the functionality offered by VisualAge for Java and WebSphere Studio “classic edition”. Besides that a lot of new features are added to the product, one of which is the possibility to create Web Services and applications that use them. The detailed explanation by means of Web Services development diagram will be described in the next implementation section.

• WSTK is a software development kit that includes a run-time environment, a demo, and

examples in designing and executing Web Services applications that can automatically find one another and collaborate in business transactions without additional programming or human intervention. It is available from the IBM AlphaWorks web site.

• WSDE is an environment that creates open, platform-neutral Web Services for

deployment across heterogeneous systems. It is targeted at developers who want to make a start in this area. Web developers can create Web Services with minimal knowledge of Java, XML or SOAP.


31

Eventually WSAD is chosen to help with implementation. This is mainly because of the tool functionality, its availability, reference support, cooperation with the deployment environment and usage simplicity.

3.2.4 Software and Hardware Development Setup For all the design, implementation and deployment two IBM servers (Pentium 1G MHz, 1G RAM) and one workstation have been used. All source codes have been developed using IBM VisualAge for Java and WSAD; complied and executed using the IBM Java 2 JDK, Standard Edition version 1.3.0. IBM DB2 Enterprise Edition 7.1 is used for database. The actual deployment has been done for both services provider and requester, with IBM HTTP Server 1.3.6.2, and WebSphere Application Server 4.0 Advanced Edition, three different versions have been used for different roles, due to the differences of corresponding software requirements: They are WebSphere Application Server Advanced Edition 4.0 for Web Services Requester; WebSphere Application Server Advanced Edition 3.5 for Web Services Provider; and WebSphere Application Single Server Edition 3.5 for UDDI Private Registry Preview.


32

3.3 Implementation

3.3.1 System Implementation Overview Before start developing this Web Services prototype, an overview of implementation steps is shown as following:

1. Analysis and design 2. Hardware and software installation 3. Web Services requester development " Travis server model design " Travis server development

4. Web Services provider development • Building functional Java Bean " WSDL generation from Java Bean " Generation of a Java stub implementation from a WSDL document " Development of Web Services into the WSAD WebSphere Test Environment

5. Web Services client development " Generation of a client side SOAP proxy from a WSDL document " Generation of a test client for a Web Service (from WSDL)

6. UDDI browser (both for static and dynamic binding) " Export operation (publish) " Import operation (find)

7. Using UDDI4J to realize automatic publish service, delete service and find service

3.3.2 Development This section gives a detailed description of prototype development by means of WSAD development diagram as shown in the figure 12 below, which illustrates steps in a pseudo-UML collaboration diagram. For successful development, deployment and use of Web Services, programming codes (e.g. (Enterprise) Java Beans) and definition files (e.g. WSDL) need to be created. The development tools mentioned in the tool assessment section are used to assist in the creation of these classes and XML files.


Let us walk through the diagram, which represents the development steps in a clear way:

SteEitdeim StedoStawiim SteWpadeenve StePureg SteReSepa

33

Figure 12: Web Services Development and Runtime Information Flow

p 1: Service provider side Java implementation. her develop Java code or define WSDL file depending on the top-down or bottom-up approach veloper is choosing. Consider about functionality of the program, build up Java plementation, keep it simple and straightforward, and wrap the program to a Java Bean.

p2: Conversion of existing programming language into WSDL interface and implementation cument. rt from an existing Java Bean, specify the methods that will be exposed as a Web Service, tool

zard generates the corresponding WSDL files (both service interface and service plementation files).

p 3: Generation of sever side SOAP deployment descriptor from WSDL specification. eb Services wizard generates the ISD file, which is the SOAP deployment descriptor for a rticular Web Service. All ISD files in a project are composed to form the SOAP deployment scriptor for all Web Services. SOAP encoding can be specified, which tells the SOAP runtime vironment how to translate from data structures constructed in Java into SOAP XML and vice rsa. Detailed encoding styles will be discussed in the following finding section)

p 4: UDDI export and import. blish, un-publish, and update of service registration in the UDDI registry; find service interface istration in the UDDI registry

p 5: Generation of client side SOAP stub and optional generation of Web Services test clients. quester generates Web Service proxy class makes easy to invoke Web Services. The Web rvice Proxy class contains the code to set the encoding styles for the input and output rameters and to make a SOAP request.


34

Step 6: Services invocation and execution.

• Dynamic lookup of service providers in the UDDI registry (step 6a). • Service requester side service invocation (step 6b). • Transport level communication between requester and provider (step 6c). • Service provider side service invocation (step 6d).

3.3.3 Static Binding vs. Dynamic Binding As discussed in Chapter 2, Web Services clients (service requester implementations) have to import the WSDL interface and implementation specification of the Web Services to be invoked from their environment. Three types of requesters can be identified. They import interface and implementation information at different points in time (build time vs. runtime).

• Static binding: No public, private or shared UDDI registry is required; the service requester obtains service interface and implementation description via a proprietary channel from the service provider (e.g. email), and stores it into a local configuration file [10].

• Provider-dynamic binding: The service requester obtains the service interface specification file from a public, private or shared UDDI registry at build time and generates proxy code for it. The service implementation document identifying the service provider is dynamically discovered at runtime.

• Type-dynamic binding: The service requester obtains both the service interface specification and the service implementation information from a public, private or shared UDDI registry at runtime. No proxy code is generated; the service requester directly uses the more generic SOAP APIs to bind to the service provider and invoke the Web Services.

Static binding and provider-dynamic binding have been used in Travis prototype because of the tool support and demonstration reason, more specifically, in the scenario, theme selection uses static binding; sub-theme selection, flight reservation, hotel booking, car renting services all use provider-dynamic binding. Static binding and dynamic binding are two important concepts for the rest of the thesis discussion, and are heavily addressed in both security and performance chapters. From technical perspective, differences between static binding and dynamic binding can be found in two points during development:

• In static binding, developer copy the WSDL implementation file directly to the requester side web project, but in dynamic binding, this transfer involves the UDDI registry, where the WSDL interface file is imported instead of implementation file.

• To generate the client proxy from WSDL file, use the file describing the service interface as opposed to the static binding. The generated Java code is very similar, however, the only difference is that the proxy no longer hard-codes the SOAP address of the service provider.


35

In order to clarify the difference of using dynamic binding, a screenshot of Travis prototype flight reservation is illustrated in Figure 13:

Figure 13: Flight Reservation Panel

Flight reservation in Travis prototype uses dynamic binding as introduced. The above figure shows the portal where the user can input departure location and date, arrival location and date, etc. parameters to query the available flight information. According to the dynamic binding definition, this query can expect to retrieve all registered flight organizations from the UDDI registry. The scenario sets two situations for validation: first, only two flight organizations (KLM and IBERIA) are registered in the UDDI registry, if “next” is clicked, these two companies’ detailed flight information can be retrieved. Second, if one more flight organization (China Airline) is added and registered into the UDDI registry, refresh the browser page, immediately the user will be able to see the third China Airline’s flight information shown on the portal. This result perfectly reflects the value of using dynamic binding, where service providers can be dynamically found by the service requester based on the proper query as long as it registers in the UDDI registry.


36

3.3.4 Process Step-by-Step Process of implementation consists of following two stages: Stage 1: Flight, Hotel, Car inquiry using static binding Flight KLM is listed in the following figure 14 to show the static binding Web Service invocation. Other flight organizations, hotel booking and car renting are implemented in the same manner.

Travis -- Theme Trip

Travis WebApplication

Server

Travis Database

Servlets

JSPs

JDBCHTTP

User Browser

Flight KLM

Travis Database

JDBC

DB2 UDB 7.1


Server

Servlets

WebSphere AdvancedEdition 4.0

SOAP Client

SOAP Server

Model

Figure 14: Stage 1 – Statically Bound Web Services Invocation


37

Stage 2: Dynamic inquiry on Flight, Hotel, Car services UDDI registry is involved in dynamic binding situation in figure 15. 1. Publish Web Services (manual or SOAP/HTTP)2. Find Web Services using SOAP/HTTP3. Invoke Web Services at service providers

Flight IBERIAFlight China Airline

UDDI RegistryTravis -- Theme Trip


Server

TravisDatabase

Servlets

JSPs

JDBCHTTP

UserBrowser

Flight Services

Travis Database

JDBC

DB2 UDB 7.1


Server

Servlets

WebSphere AdvancedEdition 4.0

SOAP Client

SOAP Server

3

3LodgingServices

SOAP Server

Rental CarServices

SOAP Server

3

UDDI DB

SOAP Server

2

1

1

1

Model

Figure 15: Stage 2 – Dynamic Lookup of Web Services in The UDDI Registry


38

3.4 Discussion During the design, implementation and deployment of Web Services prototype development, several technical issues are highlighted; limitations are found and discussed in the following section:

3.4.1 Encoding Styles and Mapping The following discussion about encoding style and mappings are in the context of using WSAD assisting the development. Assume Java and XML language are chosen to be the developing programming language; the encoding style defines how the Java types in the client and server are mapped to the XML types in the SOAP message. There are currently two encoding styles available [10]:

• Literal XML encoding: this must be selected if the element to encode is of type org.w3c.dom.Element. The XML element is then inserted directly into the SOAP message.

• SOAP encoding: Use this option for all other data types, including simple Java types, standard Java classes and non-complex custom classes.

There is a limitation in the current release of WSDL, which only allows an encoding style to be defined at an input or output level for the method signature. For a complex input signature, which requires a combination of XML and elements and other data types, developer must code a custom mapping and write their own serializers and deserializers. Figure 16 shows the mapping between Java and XML for the Web Services to operate.

Figure 16: Mapping for a Web Service

• Client input mapping: This takes the parameter from the Java client and maps it using

the input encoding style. In Travis, this input parameter is the flight departure place, arriving place, departure date and return date, defined using a Java String and Date class and using the SOAP encoding style. This is serialized to an XML type name of xsd:string.


39

• Server input mapping: The flight departure place, arriving place, departure date and return date are now deserialized from the SOAP encoding style in the message to a Java type of String, which is then used to invoke our Java Bean.

• Server output mapping: Once the Java Bean has completed its method execution, the returned value is inserted into the SOAP reply using the output encoding style. In Travis, the returned type is an instance of the java.util.Vector class, containing the result set for flight query. This data will be serialized by using the SOAP encoding style again. (If choosing to define the returned type as an instance of the org.w3c.dom.Element class, this data will be inserted into the SOAP message using the literal XML encoding styles.

• Client output mapping: The final stage is performed by the client proxy, which maps the returned SOAP encoding style into an instance of the Java Java.util.Vector data type. (If choosing to define the returned type as an instance of the Element class, the returned XML element encoding using literal XML style into an instance of the Java org.w3c.dom.Element data types.

For the earlier versions of WSAD, quite limited encoding is defined. In most of the case besides primary data type, extra programming efforts are required.

3.4.2 About UDDI Registry 1. There is a restriction for the current available IBM UDDI Test Registry, a public available

UDDI implementation from IBM, which allows to publish only one business entity per registered user, up to four services per business entity, two binding templates per business service, and 10 tModels per registered user.

2. UDDI4J (UDDI for Java): In order to programmatically access the UDDI information and

invoke the discovered Web Services, UDDIAccessor class is used to implement the locating of the service provider in the UDDI Registry. From the UDDIAccessor, the UDDI lookup is done in the findServiceImplementation method, which has the goal of collecting the access points defined for a given provider and service type and return the list as a Java vector. The findServiceImplementation (provider, service) method takes two parameters, one is the service provider, which is the Business Entity requester wants to find; another one is the service type, which comes from the binding attribute in the implementation. This is based on the assumption that this one business entity takes ownership of the WSDL interface document from certain number of service providers, which implement the same interface file differently.

3. It is discovered that dynamic UDDI lookup requires Web Services requester to specify the

business entity’s name as explicitly as possible, which can help to narrow down the query result; and get to know the service type before hand, so that the programmatically discovery can be taken. In this case, the action might be easy for the intra-enterprise integration, but for the inter-enterprise integration, extra actions are expected, for instance, getting contact and making agreement between different parties are required before the discovery is performed.

4. Regarding the dynamic UDDI lookup mechanism, the detected Web Services access point

needs to be examined. Firstly, tModels that have been discussed in Chapter 2 are found matching the specified service type depending on the registered services. The service type (tModel name) and the UUID (tModelKey) are displayed for each of them. Secondly,


40

Business Entity that matches the service provider description is displayed together with its key. Finally, all services that implement the Business Entity are found, each service is followed by the one binding/access point that implements the tModel, and is associated with a WSDL implementation file.

3.4.3 Limitations There are several limitations are found in terms of extra development effort beyond tool support. 1. XML Schema needs to be constructed by service provider and put them in a reachable URL,

this information can be found by service requester from WSDL file during invoking process. Together with the Web Service binding action, this XML Schema allows to perform validation action.

2. Rather than using java.util.Vector type (since it is a “dirty” String representation,

org.w3c.dom.Element can be used to construct complex data type. From a service requester perspective, this DOM tree needs to be broken down. Meaningful element can be used to construct information as user required; it can be manipulated according to different GUI design; and it also can be selectively provided based on different terms and conditions in the agreement.

3. There are two ways to transform the DOM tree representation to required HTML: one is

using related API to break down the element, get the attribute and entity reference from each node. By doing this, DOMParse() needs to be built for each retrieved DOM tree representation, since the content related markups are different. Another approach is to use .xsl stylesheet to do the transformation from XML to HTML. In this case, a stylesheet needs to be constructed and the transformation can be done by supported API. In the prototype development, since MVC design pattern is used, this transformation is coded in JSP instead of in the servlet, so that the displayed transformation result can be placed and manipulated in the JSP pages randomly.

Although the above mentioned limitations require some development efforts, indeed the tools well support the majority of the development and implementation. The conclusion can be made that Web Services standards are at a mature stage in their lifecycle.

Chapter 4 Security

41

Chapter 4 Security

4.1 Motivation Web Services have the advantage allowing heterogeneous distributed solutions, which enables delivering integrated, interoperable solutions. A typical Web Services setup might make use of many different technologies, object models and programming languages. Being able to interact across such diverse environments is one of the strengths of Web Services, but it has a price: it becomes difficult to secure such systems. As discussed in the previous chapters, Web Services use message-based communication; therefore, Web Services security is based on messaging security. The need for secure messaging with Web Services has grown since Web Services have access to sensitive enterprise processes and resources and perform financial transactions between organizations. At the time I started asking Web Services security questions in the research proposal some months ago, there were rarely few publication and discussion in this area. Nowadays, because of the importance of having secure Web Services, there are some on-going researches dedicated to this security issue. IBM and Microsoft recently have collaborated on a proposal to address Web Services security plan, roadmap and follow-on specification. Similar ideas have been expressed previously by these two organizations as well (namely the SOAP-Security, WS-Security and WS-License specifications). The following investigation has the goal of enabling secure identification, authentication, integrity and confidentiality over an open network with respect to the demonstrated prototype in Chapter 3. It provides some fundamental analysis of the security problem in the application; it includes some primary requirements that secure Web Services have to address; it presents the existing efforts and implementation; it proposes a security model that covers authentication, authorization, integrity, confidentiality and it describes the gap between the requirement and the current implementation, which might be filled in for the future research.

Chapter 4 Security

42

4.1.1 Seven Aspects of Security Web Services security is an open issue, standard and products implementing them are partially available for the time being, and are widely investigated now. By definition, Web Services security covers the following aspects: identification, authentication, authorization, integrity, confidentiality, auditing and non-repudiation across a wide spectrum of application and business topologies. These seven aspects are listed in the following together with questions that give the explanation:

• Identification: “Who are you?” • Authentication: “How do I know your identity is true?” • Authorization: “Are you allowed to perform this transaction?” • Integrity: “Is the date you sent the same as the data I received?” • Confidentiality: “Are you sure that nobody read the data you sent me?” • Auditing: “Record of all transactions so we can look for security problems after the fact.” • Non-repudiation: both sender and receiver can prove to a third party that the sender did

send the transaction, and the receiver received the identical transaction. Among these issues, four aspects as identification, authentication, integrity and confidentiality are addressed in this chapter. This is mainly because some standards for supporting these issues in Web Services environment are found, and will be discussed in the next part of this chapter. Authorization, auditing and non-repudiation are not covered by this thesis. They may be addressed for the future research work.

4.1.2 Web Services Complexity The complexity of Web Services environment is introduced as following with the prototype that implemented in the previous chapter and shown here again with some modification. This example, although somewhat contrived, captures important elements of real applications. This prototype illustrates many of the distinctive characteristics of the Web Services environment

• The participant parties are diverse and dynamic. Participants in such an integration process will include many organizations, located in different countries and will change frequently.

• The Web Services pool is large and dynamic. Because individual organizations decide whether and when to contribute services, the quantity and location of available services can change rapidly.

• The binding processes created by services requester may acquire and release services dynamically during its execution. Even in our simple prototype, the services acquired at several sites. In other words, the package Travis offered to the end user is composed of a dynamic group of processes using different services running on different sites.

• Different services in different sites may require different authentication mechanisms and policies, which services requester has limit ability to change.

To summarize, with these complexities, the problem is providing security solutions that can allow diverse access and to operate securely in heterogeneous environments.

Chapter 4 Security

43

4.2 Functional Requirements When talking about Web Services security for this research, the first thing is to decide what security functionality is required. This naturally depends on what Web Services are used for, and what trust relationships are involved. The security requirements that are discussed here have the purpose of specifying this. In this section, several functional requirements for a secure component interaction in the Travis Web Services environment are identified:

4.2.1 Between Provider and Requester The service requester Travis should be able to verify that it is actually talking to the right service provider, a flight organization (KLM for instance). Likewise, the service provider should be able to verify who is trying to access its service (e.g., flight inquiry). Except for both provider and requester authenticate themselves to the UDDI, which can name as indirect authentication, the alternative would be to shift the authentication to a mutual authentication procedure between each service provider and service requester directly. Now the trust is established between provider and requester, it is still important for the requester to be sure that the service Travis received is the same as the provider offered. This is the requirement of integrity.

4.2.2 UDDI Interaction Even the communication has been secured and services have been authenticated, there still will be some doubts about UDDI registry. Even if a UDDI registry provides service requester with untampered registered information, it might do so in an unfair manner. Instead of sending the service requester the cheapest service (or whichever it is interested in), it might always only supply its preferred service provider. From a service provider’s view even the knowledge of a service’s existence might be considered a valuable asset that must be protected. It is therefore necessary to trust the UDDI registry a service requester is talking to. This can be achieved by requiring the UDDI registry to authenticate itself to its clients. Although the infrastructure is trustable, it is still possible to have malicious services registered with secure UDDI. Therefore it is required the service providers to authenticate themselves to the UDDI. Likewise, service requesters to authenticate them to the UDDI. In some cases, services providers do not allow other organizations to observe the in-traffic service description. For example, KLM does not permit other flight organization to know it registers in a UDDI registry. It is therefore necessary to keep the connection between the UDDI and service provider confidential. The same applies to services requesters.

4.2.3 Administrative Secure Groups So far, the described requirements allow the service requester to have trusted services. No distinction was made between different services: they all have the same security level. But usually different levels of security are desired. An example is administrators that have access

Chapter 4 Security

44

rights for more services than ordinary users. The services can be partitioned by introducing secure groups. Services that have the same access registrations are put together to form a secure group. Every service registration is associated with one secure group. This is also the question about authorization: who or which group actually has the rights to access one service but not the other. To wrap up this section, there are three functional requirements that the secure Web Services have to cope with: " Authentication and integrity between service provider and service requester. " Confidential communication between service provider/service requester and UDDI, which is

authenticated as well. " Authorization of service provider and service requester. Although these three requirements are generally discussed above, only the first two issues will guide the design of the solution in the rest of this chapter, as authorization aspect is not in the scope of the thesis.

Chapter 4 Security

45

4.3 Related Efforts and Implementation Presenting the range of security technologies and the ones being adopted as standards provides the fundamental base for abstracting application specific security architectures. Currently there is a variety of security technologies exist, and some are being adopted as standards. Following is a brief overview of these technologies and standards. Transport Security – Secure Socket Layer (SSL) along with the Transport Layer Security (TLS) is used to provide transport level security for Web Services applications. SSL/TLS offers several security features including authentication, data integrity and data confidentiality. It provides point-to-point integrity and confidentiality for a message [2, 8]. IPSec is another network layer standard for transport security that may become important for Web Services. Like SSL/TLS, IPSec also provides secure sessions with host authentication, data integrity and data confidentiality [2]. Public Key Infrastructure (PKI) – the PKI model includes certificate authorities issuing certificates (e.g.X.509) with public asymmetric keys, and authorities that assert properties (e.g. identity). Kerberos – the Kerberos model relies on communication with the Key Distribution Center (KDC) to broker trust between parties by issuing symmetric keys encrypted for both parties and “introducing” them to one another. XML Digital Signatures – this provides different algorithms to allow XML documents to be signed in a standard way in order to securely verifying the origins of messages. It can be used for validation of messages and for integrity to ensure that messages are transmitted without modifications. Using XML digital signatures can provide data integrity. XML Encryption – it is used to keep message confidentiality. It allows partly encryption of digital content while leaving other parts open. Security Assertion Markup Language (SAML) – it is designed to offer single sign-on for both automatic and manual interactions between systems. It is expressed in the form of assertion statements about security subjects (e.g. users, machines or services). SAML has been thoroughly investigation in. As discussed in the previous section, authentication forms the foundation of a security policy that enables diverse local security policies to be integrated into a global framework.

Chapter 4 Security

46

4.4 Web Services Security Model What is needed in a comprehensive Web Services security architecture is a mechanism that provides end-to-end security. Successful Web Services security solutions will be able to leverage both transport and application layer security mechanisms to provide a comprehensive suite of security capabilities [2]. The purpose of this Chapter is to address some aspects of the security that involved in Travis prototype, and tries to use the existing security standards and technologies to draw a problem-solving model, which can meet these functional requirements. Therefore, in this section, first, a Web Services security token service model is introduced. Second, a detailed description of two selected scenario is presented based on demonstrated prototype, which intends to answer the questions that arise as functional requirement in section 4.2. Finally, a more general scenario combines

4.4.1 Web Services Security Token Model As investigated and introduced in [2], the security token concept is an important concept that is heavily used in the following discussions. It defines a security token as a representation of security-related information (e.g. X.509 certificate, Kerberos tickets and authenticators, mobile device security tokens from SIM cards, username, etc.). There are two types of security token can be defined: signed security token contains a set of related assertions cryptographically endorsed by an issuer (e.g. X.509 certificates, Kerberos tickets); and unsigned security tokens like username. The Web Services security model described herein follows a process:

• A Web Service can require that an incoming message prove a set of claims (e.g., name, key, permission, capability, etc.). If a message arrives without having the required claims, the service may ignore or reject the message. The set of required claims and related information are referred as policy.

• A requester can send messages with proof of the required claims by associating security

token with the message. Thus, messages both demand a specific action and prove that their sender has the claim to demand the action.

• When a requester does not have the required claims, the requester or someone on its

behalf can try to obtain the necessary claims by contacting security token services. Security token services broker trust between different trust domains by issuing security tokens.

Chapter 4 Security

47

This model is illustrated in the figure 17 below, showing that both requester and security token services may also be Web Services.

Security TokenService

Web Services

Requester

SecurityToken

SecurityToken

Policy

Policy

SecurityToken

Policy

ClaimsClaims

ClaimsClaims

ClaimsClaims

Figure 17: Web Services Security Token Services Model

4.4.2 Static Binding In the previous section, the security token model is illustrated. In the following two parts, the Travis prototype security will be discussed for two possible scenarios that extract from the entire process. By doing this, the functional requirements have been addressed can be reached. As mentioned in chapter 3, Travis prototype designed in a way that flight reservation services, hotel booking services, car renting services, and theme selection services can be invoked and combined into one single portal. Because all these services are bound into the Travis requester side in the same manner, it would be sufficient to discuss one of these bounded Web Services that can represent the rest scenarios. Flight Web Services are selected for the security scenario discussion. In the following, static binding and dynamic binding are explained from different security aspects corresponding to the first two requirements in section 4.2, with respects to the requirements for service provider and service requester, and while UDDI involved respectively. For each scenario, a demonstrating figure is given together with the description. Some of the security properties, such as federation, validation, delegation, access control, trust etc., are not common and more ad-hoc. Discussions to address these issues are identified in the future research.

Chapter 4 Security

48

4.4.2.1 Authentication and Integrity In order to meet the requirement proposed earlier in this chapter regarding service provider and service requester, authentication and integrity aspects of security must be addressed. Here are three possibilities: The first and most fundamental solution to solve the authentication problems between requester Travis and flight Web Services is to use username and password that Travis site provides, based on transport level security technologies (e.g. SSL/TLS) as illustrated in figure 18:

Requester FlightWeb Services

username/passwordtransport-level security

Figure 18: Web Services Security and Existing Transport Security Mechanism

Travis opens a connection to flight Web Services, which implements transport-level security, and then sends its username and password for validation. The second method is using security token as introduced previously. This scenario assumes that two parties have used some mechanism to establish a trust relationship for use of the security token, which can either be PKI certificate or Kerberos certificate technology.

Requester FlightWeb Servicessecurity token

Security TokenServices

1 2

Figure 19: Authentication by Trust Party

There are two possibilities to obtain security token for both parties as shown in figure 19:

1. Travis requester communicates with a certifying authority (security token services) to obtain a security token. Next it sends the security token together with its proof of identity to the flight Web Services and receives response.

2. Instead of sending security token, requester Travis can provide reference to the flight Web Services. Flight Web Services then use the reference to locate and acquire the security token, and then accomplish the communication by issuing response.

Chapter 4 Security

49

The third possible way of conducting authentication is by using firewall as shown in figure 20:

AuthorizedRequester

FlightWeb ServicesFirewall

UnauthorizedRequester

Service Provider

Figure 20: Firewall Processing SOAP Message

In this scenario, the firewall examines incoming SOAP messages and only allows those from authorized requesters to penetrate the firewall and reach the flight Web Services. The unauthorized requester’s message will be rejected. The assumption is Travis is authorized requester. The firewall makes this decision by examining the security token used to sign the message. XML digital signatures can be used here for signing. If the signature is valid, and the signing authority for the security for the security is trusted to authorize messages into the firewall, and the token says it does authorize messages into the firewall, then the message is allowed; otherwise it is rejected. The above three solutions regarding requester to Web Services invocation intend to address two requirements discussed previously: authentication to participant parties and access control to services. As for the issues related to the UDDI are examined in the later part.

Chapter 4 Security

50

4.4.2.2 Business Policy Enforcement In many business processes there are specific policies that must be enforced. For example, on one hand, Flight Web Services only want to interact with travel agencies whose services are proved by tour operator (as illustrated in the following figure 21 as solid line 1, 2, 3); on the other hand, Travis only wants to access flight companies whose flights are certified by the general flight organization (as illustrated in the following figure 21 as dashed line 4, 5 6).

Security TokenServices

KLM FlightWeb Services

TravisTravel Agency

Tour Operator Central FlightOrganization

IdentityToken

IdentityToken

TravelToken

TravelToken

FlightToken

IdentityToken

FlightToken

1

3

2

4

5

6

Figure 21: Business Policy Enforcement

As stated as solid line above, travel agency Travis goes to the tour operator and presents its identity token (2), which can be obtained from Security Token Services (1), and requests a security token from tour operator stating it is a certified travel agency (assuming it is certified and in good status). Travis could then contact KLM Flight Web Services and provide both security tokens (3). The other case is illustrated as dashed line in the figure; KLM Flight Web Services could go to the Travis and presents their identity token (5), which can be obtained from Security Token Services same as above case (4), and requests a security token from central flight organization stating they are certified flight company (same assumption). KLM Flight Web Services could then contact Travis and provide both security tokens (6). In this scenario, authorization between different parties can be addressed.

Chapter 4 Security

51

4.4.3 Dynamic Binding

4.4.3.1 UDDI Operator Node Often the existing trust models are based on business agreements. An example of this is the UDDI Web Services, where all participants provide their registered information through an agreement to support a set of APIs. Instead of requiring all operator nodes to implement a specific authentication mechanism, the “trust model” in UDDI gives the responsibility for authentication to each operator node, which is the party taking care of the registration information. This means each implementation of Web Services has its own authentication mechanism and enforces its own access control policy to its own information requesters and providers. This relationship is shown in the following figure 22.

UDDIOperator Node

1

UDDIOperator Node

3

UDDIOperator Node

2

UDDI4JAPIs

Trust

TrustTrustTrust

Policy 1 Policy 3Policy 2

Figure 22: UDDI Operator Node Trust and Policy

Defining individual authentication mechanism and access control, UDDI operator node can therefore enforce these policies to the participants want to interact with it, namely registered providers and finding requesters. Below a UDDI involved three components model are illustrated as an overview diagram showing UDDI Web Services security token services model.

Chapter 4 Security

52

4.4.3.2 Dynamic Binding Security Token Service

UDDI

Requester Web Services

Policy SecurityToken

PolicyPolicy

SecurityToken

SecurityToken

Signed proxy services & Services access control

Encr

ypte

d co

mm

unica

tion Encrypted comm

unication

SecurityToken

Services

SecurityToken

Figure 23: Dynamic Web Services Security Token Services Model

Figure 23 can be described as following steps:

1. Web Services provider communicates with a certifying authority (e.g. Security Token Services), which can be a Web Service itself, to obtain a security token, specifically a signed statement of assertions attesting to the provider’s identity. As stated before, PKI certificate and Kerberos certificate can be used as security token.

2. Web Services provider agrees to a certain policy (name, key, permission, capability, related information, etc.) because the UDDI Registry has a policy requiring that an agreement of the appropriate statement is necessary.

3. The provider next sends the registration information, with the security token and a proof of identity, and proof of implementation of policy attached to the message to the UDDI Register and receives a confirmation.

4. The provider can start registering its Web Services information into the UDDI using encrypted communication channel, where XML encryption technology can be used.

5. The same process for the requester, it communicates with a certifying authority (e.g. Security Token Services) to obtain a security token as stated in the step 1.

6. The requester does the step 2 as well in order to be authenticated. 7. The requester next sends the finding information, with all the needed proven to the UDDI

Registry. 8. After the signature that signed along with message has been authenticated, requester’s

finding operation will start and preferable response will be received.

Chapter 4 Security

53

9. In the next step, requester can finally use found information to communicate with several Web Services. This process has been detailed discussed in the previous static binding part, where various security technologies can be used to guarantee the authentication (security token) and integrity (XML digital signature).

The encrypted communication between UDDI Registry and Web Services provider, and between UDDI and requester can be similarly implemented as three ways as discussed for provider and requester communication: username/password based on transport security, security token services and firewall, respectively. This general messaging model supports several more specific models such as identity-based-security, access control lists, and capabilities-based-security. It allows use of existing technologies such as X.509 public-key certificates, Kerberos shared-secrete tickets and even password digests to enable identification and authentication. Standards like W3C digital signature and W3C encryption also can be used to support Web Services integrity and confidentiality. Security token provides an integrating abstraction allowing systems to build a bridge between different security technologies (transport security, PKI, Kerberos). The general model is sufficient to construct higher-level key exchange, authentication and trust mechanisms.

4.5 Gap Analysis As indicated at the beginning of this chapter, there was quite limited material available for Web Services security research while starting the proposal, but now the on-going academic works are increasing very fast in this area, which absolutely gives a broader view and provides enormous help. The proposed Web Services security model that is discussed in the previous section is enlightened by several current research contributions [2, 8, 46, 54]. Some of them describe single sign-on [46], user must be able to “log on” (authenticate) just once and then have access to multiple Web Services defined in the other provider via the same requester, without further user intervention; several discuss one specific security property [8, 54]; some address entire picture with specific technologies and simple scenarios [2]. Some issues are more generally reviewed than the other [2]. Hardly any work can give the overview of all involving research and higher-level security usage scenario. Rather than only the technologies and standards, some implementations have been widely available. XML digital signature, XML encryption are combined in the IBM security suite; SOAP message security implementation has been available in WebSphere 4.0; two implementation demo are introduced in WSTK 3.0, one is Web Services implementation on HTTPR (reliable HTTP), another one is XML Key Management Specification (XKMS) implementation. The advantage of introducing all relevant security technologies such as transport –level security, PKI, Kerberos, XML Digital Signature, XML Encryption, SAML, is to give the overview of all the possible techniques for security abstraction. There will always be a gap between architecture model and real implementation. As application security requirements change over time, organizations need to define the most appropriate security architecture based on their own problems and requirements.

Chapter 4 Security

54

The final goal security issues research is to let the proposed model that emerges be broadly available from multiple vendors and be considered by appropriate standards organizations. Together, the model, specifications, and standards process enable businesses to quickly and cost-effectively increase the security of their existing applications and to confidently develop new interoperable, secure Web Services. The business advantage of such a model is clear. By framing comprehensive security architecture for Web Services, organizations and customers can be better ensured that their investments and assets are protected as business processes become increasingly recast as Web Services [2].

4.6 Summary and Comments Building upon foundational technologies such as SOAP, WSDL, XML Digital Signature (integrity), XML Encryption (confidential), SSL/TLS (identification, authentication), PKI certificate (authentication), and Kerberos (authentication) enable Web Services service providers and service requesters in both static binding and dynamic binding to develop solutions that meet the individual security requirements of their applications. In this chapter, the introduced security technology in conjunction with the demonstrated prototype, which has been split into static and dynamic scenarios according to different demonstration usage, is examined based on the different functional requirements presented. This intends to give an example of how the implementation can be designed from an abstract level. There is no security implementation developed for the prototype due to the limited time concern.

Chapter 5 Performance Testing

55


5.1 Motivation As traditional distributed computing concept, CORBA, DCOM, and RMI use binary encoding for arguments and return types, which indeed results in a fast network performance. In addition, they assume that both sender and receiver have full knowledge of the message context and do not encode any meta-information such as the names or types of the arguments. This approach results in good performance, but makes it difficult for intermediaries to process messages. And since each system uses a different binary encoding, it is hard to build systems that interoperate. Because SOAP uses XML to encode messages, it is very easy to process messages at every step of the invocation process. In addition, the ease of debugging SOAP message leads to a quick convergence of the various SOAP implementations, which is important because large-scale interoperability is what SOAP intends to achieve. A frequently articulated concern regarding the SOAP is that a string-based protocol has a high overhead in terms of bandwidth and CPU requirements. Meta information such as XML tags and namespace prefixes add to the problem. The related research with respect to this performance issue is not actively conducted, and the concern with Web Services due to message transmitting and UDDI lookup is still under discussion. This is also the reason why this part of the thesis has its own contribution. In this chapter, performance and scalability testing have been taken for implemented prototype “Travis”, to identify the performance aspect of SOAP. And UDDI lookup is another essential factor of Web Services performance in terms of dynamic binding, which will be investigated as well. The following issues are presented: first, performance testing method is specified; second, technical setup including software and hardware is introduced, performance testing tools are assessed; third, results are presented and explained; finally, some improvement recommendations are given.

5.2 Method The goal of the performance testing is to measure the overhead of SOAP communication and the UDDI lookup time under single and multiple-client load. Namely, to measure the ratio of SOAP and UDDI in total response time with scalability. The results will be obtained that can make it possible to understand how the Web Services model perform, where is the bottleneck of the entire communication and why there are differences in performances compare with static binding and dynamic binding. There are three main relevant aspects that are discussed, different binding types, multi-client scenarios and break-downed communications, which are especially important in global networked applications. Based on the successful implementation of the “Travis” Web Services prototype, measurement is done both for static binding and dynamic binding. It is important to know how multi-client


56

interaction influences the results. Therefore, round trip times (RTT), throughput and scalability for one and up to large number of simultaneous clients are measured. The following steps are taken in order to fulfill the testing goal: First, using AKtools, which is a high-performance, simple, threaded HTTP engine tool that capable of simulating hundreds HTTP clients, using a highly configurable set of directives in a human readable and easily modified configuration file. This is the testing from end user point of view, time is measured from the URL is invoked till the target page or information is retrieved.

• Advantage: easy and simple to do; large amount of users can be simulated; monitor tuning can be easily taken; macro-analysis is available.

• Disadvantage: tooling effected performance; micro-analysis is difficult; performance can not be broken down; the reason/trigger of lower performance during the process is hardly to find

• Propose another approach: timer built in the Java code, which can easily find the bottleneck of the lower performance process.

Second, using timestamp “timer” embedded in the Java code. Analyze the Web Services finding and invoking process, different timers are built in the code, and final result will show different performance regarding different process. Issues as total response time, proxy invocation, UDDI lookup (in dynamic binding case) and XML transformation are measured. Third, advanced approach, combine the previous two steps to conduct performance testing, which can both simulate hundreds HTTP clients and do the procedure spit up, break down the process and investigate the scalability and bottleneck.

5.3 Pre-Analysis of Performance Components Understanding the system’s components and how they can affect the overall performance is the prerequisite of starting measuring and tuning the performance of any system. In order to know every part of the Travis prototype system that is involved in the process, the following figure 24 shows a detailed view: about the dynamic binding performance components, static binding is a simplified case of the one mentioned above without showing UDDI server. There are three major components of Web Services environment, with their own performance characteristics and requirements:

• Client • Server -- Provider Server, Requester Server, UDDI Server • Network


57

5.3.1 Client performance This is the performance on the user side. Web Services are program-to-program applications, which tend to do the entire processing on the server side. Therefore, the role of a client (here is a user’s workstation) is reduced. In most cases, to facilitate a user interface, typically a Web browser, Microsoft Internet Explorer in this prototype, is used. From this point of view, the client’s affect on the overall performance testing is less significant than the performance of a network or Web Services provider, requester and UDDI servers. As the testing focuses on Web Services component interaction, performance of a user is out of the scope of the discussion.

SOAP Messaging

SOAP Messaging

UDDI Lookup +SOAP Messaging

UDDI Server

HTTPServer

Win NT4.0UDDI

WebSphereApplication

Server Single

HTTPServer

Window2000

Professional

WebServices

Application

WebSphereApplication Server

4.0

Provider Server Requester Server

HTTPServer

Window2000

Professional

TravisApplication

WebSphereApplication Server

3.5

User Browser

TCP/IP Network

Figure 24: Performance Test Component on Dynamic Web Services

5.3.2 Network performance Usually, the network has much more performance impact than the client, which results from various factors (e.g., throughput, network traffic, and speed of communication links) and network components (e.g., routers, LAN topology, proxy or socks servers). The network is a dynamic environment, which is very difficult to control. This performance test is based on IBM intranet token ring network, which is not covered as major issue for thesis purpose.


58

5.3.3 Server performance The server performance components are integrated in three major areas:

• Web Server and Web Application Server, in this case are HTTP server and WebSphere Application Server 3.5, 4.0 and single version for different use, in service requester, service provider and service registry side respectively. These are the main factors in this test influence the performance and tuned thoroughly in order to obtain better result, which is discussed in detail in following sections.

• Travis application, contains application architecture and application design. • Server hardware, includes CPU, memory, cache, communication and disk space.

5.3.4 Communication overhead The items shown on the arrow in figure 24 are major issues measured and discussed for the performance test purpose: SOAP messaging and UDDI lookup time. Finding operation that illustrated as SOAP messaging between service provider and UDDI does not discussed.

5.3.5 Software and Hardware Testbed “Travis” code is in two IBM eSeries servers, for service provider and service requester respectively, and the UDDI server will remain the same as described in Chapter 3.

• VisualAge developed Java code, includes all servlet and Java Beans and model code (operating system independent)

• XML Schema for the validation purpose • XSL stylesheet for service requester side XML to HTML transformation • All JSP code, images and stylesheet for the presentation purposes

For all the performance measurements the IBM JDK Standard Edition version 1.3 has been used. All the servers used Microsoft Windows 2000 Professional as their operating system. UDDI uses Microsoft NT4.

• DB2 7.1 • IBM WebSphere Application Server (WAS) Advanced Edition 4.0 on the service

provider side and WAS Edition 3.5 on the service requester side • IBM HTTP Server

The actual performance measurements have been done for up to 64 simultaneous clients. AKtools 1.9.2.0 is used as initial performance test tool and JMeter 1.7 as visualization tool, in order to simulate multiple user loads. The servers are connected into a 16 Mbps token ring network by using IBM intranet.


59

5.3.6 Performance Test Tool In order to test the throughput and scalability of Travis application, a performance test tool is needed to simulate a load. The WebSphere Application Server does not include any tools for the purpose of load generation or client side performance monitoring. There are three tools available for the period of implementing performance testing, some of them are available for free and some are at cost. PushToTest PushToTest is offered as free open-source, designed and used as specific tool for Web Services system testing, monitoring, and automating in terms of functionality, scalability and performance. It works with the combination of Java object and XML-based script language. AKtools AKtools are a set of internal IBM applications, which allow a user to test Web application performance, and is the tool used in writing this chapter. It is a primarily stress test tool, which has been used for the Sydney Olympics and the NBC Olympics web sites. It contains two applications akrecord and akstress. Akrecord is a simple proxy that records a user’s session against a web server for later playback in akstress. Akstress is a threaded HTTP engine, which is capable of simulating hundreds of HTTP clients, using a configurable set of directives in a human readable and easily modified configuration file, which is built by akrecord and tuned according to the user’s need. In the prototype scenario, AKtools is chosen to conduct the testing. There are two reasons, first, performance testing is more emphasis on two issues as has been discussed in the previous part, overhead and scalability, which can be simply configured and logged with AKtools; second, based on these needs, this tool also can be well combined with pre-defined scenario. JMeter Another tool that is available and found at the later stage of the performance testing is called JMeter from Apache. It is a 100% pure Java desktop application designed to load test client/server software or web application. In the Travis testing case, it is used to simulate a heavy load on a server to test its strength or to analyze overall performance under different load types. There are several parameters that can be set before hand for the simplicity of testing. “Thread group” is used to set the number of threads, time intervals between different threads and number of times per thread. It is better to specify a delay by adding one of the three timers to the Thread Group. If the delay is not added, JMeter could overwhelm the server by making too many requests in a very short amount of time.

• Limit the number of threads. The hardware’s capabilities will limit the number of threads that can effectively run with JMeter. It also depends on how fast the server is. The more Jmeter works, the less accurate its timing information will be. The more work it does, the more each thread has to wait to get access to the CPU, the more inflated the timing information gets. If the large-scale load testing needed, running Jmeter remotely should be considered across multiple machines.

• Using the proxy server. The most important thing to do is filter out all requests that are

not interesting. For instance, there’s no point in recording image requests, stylesheets, javascript files, and other included files, testing can always exclude these elements.


60

5.4 Testing Result and Discussion The detailed performance evaluation of implemented Travis prototype is carried out through a series of simulations by varying the number of users, binding types and communication breaking points. The testing result is shown in this section below. It includes three parts: the first one is “equilibrium” test, which finds the appropriate number of pages per user per test; in second and third test, static binding and dynamic binding are measured respectively, from RTT, breakdown and multi-user aspects.

5.4.1 “Equilibrium” Test Users accessing the application at difference time may experience different response time due to various reasons. In order to be more accurate on performance test for each user, average time is calculated for sequential accessing the same service. In the measurement, there are four simultaneous users accessing the same Web Service (ThemeService in this case) with difference numbers of sequential testing (1, 10, 20, 30, 40, 50 times) continuously. The testing result is illustrated in following table, which include number of users, average data (milliseconds) and standard deviation (milliseconds):

Users 1 10 20 30 40 50 Average 2134 1757 1601 1595 1591 1591

Standard Deviation 713 345 161 123 100 103 It can be seen from the result that with four simultaneous users accessing the same Web Service (with 1, 10, 20, 30, 40, 50 pages per user), the standard deviation is decreasing while numbers of page per user is increasing. But up to 40 till 50 pages per user, the standard deviation remains almost the same, which indicates that around 40 pages per user is the “equilibrium” number for testing. For more than 50 users test, the standard deviation does not increase, but remain nearly the same. Therefore, in the following multi-user test and breakdown test, the number 40 (pages per user) is used. Both static binding and dynamic binding have been measured by using same set of Web Service (ThemeServices), which guarantees the same client, same network, same server in terms of both hardware and software configuration. The comparison can be done easily based on the binding time they spent on JDBC call, SOAP messaging, proxy invocation, XML parsing, UDDI lookup (dynamic binding case) as defined earlier before. Direct remote call without using Web Services has been originally considered for comparison of Web Services performance to the ones using Web Services. Due to different remote call design and strong dependency of various Java servlet implementations, the comparison is not applicable. Therefore, it has been done in such a way that only static binding and dynamic binding are measured, for both single client and multi client scenarios for further discussion.


61

5.4.2 Static Binding Test In the static binding case, the evaluation is carried out from single user scenario to multi-user testing on Theme Service. There is no input parameter; output is a complex datatype of org.w3c.dom.Element. The DOM element mapping is used when do Web Service XML to Java Mappings. The service provider side Theme Service contains five elements in the prototype. The following figure 25 shows for concurrent users (1, 2, 4, 8, 16, 32, 64) the RTT mean time and its standard deviation. It can be seen clearly from the graph that total response time increases nearly linearly while numbers of users are increasing. The standard deviation also grows as well, but keeps less than 10% of the total response time, which is acceptable in this case. The test is only measured up to 64 users, because within these 64 uses, only 62 successfully finish their request. When number of users increase after this, server cannot handle more users without further performance tuning.

Scalability for Static Binding

0

5000

10000

15000

20000

25000

30000

0 10 20 30 40 50 60 70

Number of Users

Mill

isec

onds

request mean time standard deviation

Figure 25: Scalability for Static Binding

For the total RTT, it is very important to know how much time it spends for each part of the communication. Remaining 40 requests per user setting, mainly there are three issues that are addressed:

• Proxy method invocation, which starts from the proxy method is called till the result is returned back, and it contains:

a) The JDBC call on the service provider side, b) The entire SOAP encoding (e.g., XML passing, Java to XML mapping), c) Network overhead, etc.,

Adding all of these is the invocation time. • XML - HTML transformation, this is done by using .xsl stylesheet to transform the

parsed DOM tree (in XML) to displayed HTML style, this is the display time on


62

requester side. This time differs from one method to another in terms of the different presentation approaches.

• Total response time, it is the time that elapses between the initiations of a method invocation by the client until the results are returned to the client.

Breaking down the total response time into significant pieces as discussed above, which can reflect the bottleneck of the communication. The result is plotted as shown in figure 26:

• Service provider side JDBC call • SOAP communication • Network overhead • Service requester side XML presentation • Others

Scalability Breakdown for Static Binding

0

5000

10000

15000

20000

25000

30000

35000

1 2 4 8 16 32 64

Number of Users

Mill

iSec

onds

JDBC SOAP Netw ork XML transformation Others

JDBC

SOAP + Network + XMLtransformation

Figure 26: Static Binding Performance Breakdown

It can be seen clearly from the figure 26 that most of the total response time is spent on JDBC call on service provider side and it is even not possible to show the precise number of the other parts of the communication. The arrow in the figure shows the sum of SOAP, network, XML transformation and others. Therefore, the other parts of the communication except for JDBC calls are plotted separately in figure 27 in terms of the performance purpose concern.


63

In order to get an idea of how this JDBC call influence the total response time, the table below shows the exact number:

Users

JDBC (milliseconds)

RTT (milliseconds)

Percentage

1 393.18 774.93 0.50737486 2 506.58 914 0.554245077 4 1283.758 1694.5 0.757602833 8 3053.426 3475 0.878683741 16 6401.42 6809.471 0.940075962 32 13300 13694 0.971228275 64 28226.35 28643 0.985453689

The observation is the more concurrent users access the same requester, the more percentage JDBC takes within RRT. It grows from one user 50% time spent on JDBC, up to 64 users more than 98% time spent on service provider side database communication. SOAP encoding, Network overhead, XML presentation and others in RRT except JDBC calls are plotted below in figure 27:

Partial Breakdown (static)

0

50

100150

200

250

300

350

400450

1 2 4 8 16 32 64

Number of Users

Mill

isec

onds

SOAP Netw ork XML Transformation Others

SOAP

XML transformation Network

Others

Figure 27: Partial Breakdown for Static Binding (SOAP, Network, XML, others)

Time spent on SOAP messaging remains nearly the same around 200 milliseconds regardless increasing number of simultaneous users. And the same result is observed for service requester side XML to HTML transformation. Network overhead is measured by using snoop servlet from HTTP server.


64

5.4.3 Dynamic Binding Test The same measurement is taken for dynamic binding, from single user scenario to multi-user testing on Theme Service. There is no input parameter; output is a complex datatype of org.w3c.dom.Element, where only three elements are remained for dynamic testing. This is mainly because of previous testing result, which shows large percent of the response time is consumed by JDBC calls. Therefore, element size is reduced in order to show better breakdown. The DOM element mapping is used when do Web Service XML to Java Mappings. Furthermore, UDDI registry looks up for services are involved. The following figure 28 shows for concurrent users (1, 2, 4, 8, 16, 32, 50) the RTT mean time and its standard deviation. The figure looks similar to the static binding in that the total response time increases nearly linearly while numbers of users are increasing, besides for one and two users case, the differences are not much. The standard deviation also grows as well, but keeps less than 10% of the total response time, which is acceptable in this case. The test is only measured up to 50 users, because within these 50 uses, only 44 successfully finish their request. When number of users increase after this, server cannot handle more users without further performance tuning. Compare to the static binding, this “maximum” simultaneous users that Travis can afford is less in dynamic binding situation.

Scalability for Dynamic Binding

0

5000

10000

15000

20000

25000

30000

0 10 20 30 40 50 60

Number of Users

Mill

isec

onds

request mean time standard deviation

Figure 28: Scalability for Dynamic Binding


65

Total response time for both static binding and dynamic binding based on the same setting and performance tuning, can be plotted in one graph as shown in figure 29:

Scalability Static vs. Dynamic

0

5000

10000

15000

20000

25000

30000

35000

0 10 20 30 40 50 60 70

Number of Users

Mill

isec

onds

Static Binding Dynamic Binding

Figure 29: Comparison Static Binding vs. Dynamic Binding It has been clearly indicated that dynamic binding takes more time than static binding, and the difference remains the same. This is the UDDI lookup time for dynamic binding.


66

There are four issues that are tested for dynamic binding in terms of breaking down, in order to judge what is the bottleneck for the performance decline.

• UDDI lookup, the time is measured from provider and services are set till the service implementation results are retrieved from UDDI, this is the time for the finding operation.

• Proxy method invocation, which starts from the proxy method is called till the result is returned back, and it contains:

a) The JDBC call on the service provider side, b) The entire SOAP encoding (e.g., XML passing, Java to XML mapping), c) Network overhead, etc.,

Adding all of these is the invocation time. • XML - HTML transformation, this is done by using .xsl stylesheet to transform the

parsed DOM tree (in XML) to displayed HTML style, this is the time for the display operation on the requester side. In the prototype, stylesheet is used for XML to HTML transformation, this is not the single way to perform this task, so the performance can vary a lot depends on the actual display method the service requester is chosen.

• Total response time, it is the time that elapses between the initiations of a method invocation by the client until the results are returned to the client.

The result is shown in figure 30:

Scalability Breakdown for Dynamic Binding

0

2000

4000

6000

8000

10000

12000

14000

16000

18000

1 2 4 8 16 32

Number of Users

Mill

isec

onds

JDBC SOAP UDDI Netw ork XML Others

JDBCSOAP

UDDINetwork

OthersXML Transformation

Figure 30: Dynamic Binding Performance Breakdown

The same as the breakdown test for the static binding part, even though the elements size has been reduced to three, JDBC still remains a big percentage.


67

Similar method is applied in order to maximize the other parts’ time and results are shown in figure 31:

Partial Breakdown (dynamic binding)

0

200

400

600

800

1000

1200

1 2 4 8 16 32

Number of Users

Mill

isec

onds

SOAP UDDI Netw ork XML Others

SOAP

UDDI

Network

Others

XML Transformation

Figure 31: Partial Breakdown for Dynamic Binding (SOAP, UDDI, Network, XML, Others)

The figure 31 shows nearly constant amounts of time spend for UDDI lookup (in this case around 650 milliseconds) for 1 up to 32 users, which indeed takes a big percentage of total response time as expected. Similar to static binding, both times for SOAP messaging (nearly 200 milliseconds) and XML transformation for the presentation (around 27 milliseconds) remain the same.


68

5.5 Discussion

5.5.1 XML-based Scheme vs. Binary-based People might think an XML-based scheme would be intrinsically slower than that of a binary-based model. But a text based protocol such as SOAP is not necessarily slower than binary ones, taking into account that client stubs supporting binary protocols such as IIOP or DCOM might have to be downloaded and initialized before the message exchange can start. Within the limited time scale, there is no implementation for other technologies (e.g., CORBA, DCOM) to verify this statement. A lot of efforts have been made in order to find the evidence, however, due to different implementations, it is hardly compare with the existing publication results. Second, when SOAP is used for sending messages across the Internet, the time to encode/decode the messages at each endpoints is tiny compared with the time to transfer the bytes between endpoints. As observed from the testing result, SOAP messaging takes approximately 200 milliseconds, which includes two times (provider side and requester side) endpoints encoding and decoding. This encode/decode operation is not measured due to practical reason, but can be assumed consuming similar amount of time as for XML to HTML transformation, which is around 27 milliseconds. This finally results in nearly 150 milliseconds for XML messaging. Third, when SOAP is used to send messages between endpoints in a closed environment, such as between departments within the same company, it is likely that the endpoints will be running on the same SOAP implementation. Thus, there are opportunities for optimization that are unique to that particular implementation. For example, a SOAP client could add an HTTP header tag to a SOAP request that indicates that it supports a particular optimization. If the SOAP receiver also supports that optimization, it could return a HTTP header tag in the first SOAP response that tells the client that it will cooperate to use that optimization in subsequent communications. At that point, both the client and server could start using the optimization. This is not conducted for the performance testing, and this point here just for the discussion reason. There is room for both technologies; in a heterogeneous world such as the Internet, however, an open, interoperable protocol such as SOAP has clear advantages. As usual, the solution to be preferred in a concrete project situation depends on the actual requirements. A proof of technology (PoT) can help to gain an understanding whether Web Services are the right fit for the environment. Obviously there is a lot of room for improvement.


69

5.5.2 Performance Tuning Performance is a balancing act, such that there is an optimum point at which the expenditure of time to measure matches the value of the improvements that may be obtained [5]. When looking for performance improvement, all the factors should be considered as a whole. Performance testing in this chapter is measured based on the same hardware and software settings and configurations. The relatively easy opportunity for performance gains is with the WebSphere Application Server and HTTP Server. There are a large number of “knobs” that can be tweaked, which extracts bit of performance from the system. Therefore, some preliminary performance tunings have been done for Travis testing. The next, and often the most costly step is to change the application code. Understanding the coding practices that adversely impact performance is important. Identifying where poor performance code is located is difficult. So all the results are obtained without further tuning on code and application design. As hardware becomes faster and the Java technology matures, some of these issues become less important. However, solving a performance problem by simply adding more hardware is often not the best solution and can in some cases, proves inefficient or simply not work. A good application design, deployment methodology, and system tuning should always be the first step to solve a performance problem. For example, in static binding case, current system can only successfully finish 62 requests among 64; and in dynamic binding case only 44 succeed among total 50 users. Certainly a better performance can be obtained if more efforts can put in the tuning process. Or as suggested by the performance methodology [5], to use a formal problem determination process, which roughly follow: initiation, determine the area of focus, exploration, focus on specific areas, information collection, resolution and closure, this will increase a probability of making all necessary measurements. The objective is to resolve the problem with minimum (measurement) effort.

5.5.3 Highlight Issues As has been discussed in the previous section, JDBC calls consume large amount of total response time, which increases while numbers of concurrent users are growing. Although this is not the major concern of this thesis, some relevant discussions are presented as following:

• Rather than using DB2 database, this can possibly be solved by using other methods to store the provider side data (e.g., file) if the data size is appropriate. This can indeed facilitate the formation of Web Services in provider side.

• Another way is to use data source JDBC connection pool provided by WebSphere

Application Server. JDBC API provides a Java application programming interface to SQL databases. JDBC providers and data sources are used by Java components, enterprise beans in the prototype, for database-independent connectivity. The WebSphere administrator has an important role in stabling and maintaining database connections through JDBC providers and data sources. First, configuring the JDBC providers and data sources used in connection pooling. WebSphere uses data source configurations to establish a pool of connections to a database. Second, adjusting connection pooling parameters for optimal performance.


70

Two other major discoveries of the testing are approximate constant amount of time spent on SOAP communication and UDDI lookup per user regardless total user numbers. It can be seen from the result that UDDI consumes three times response time as much as SOAP communication (mainly XML paring) spend. However, the UDDI lookup time is not split up into detailed service requester find operation, UDDI checking operation and the query results return operation. All of these can be measured and evaluated precisely if time permits. An approximate assumption can be made here:

• Service requester find operation to the UDDI: WSDL is involved in the operation, so basically it is a XML messaging. Time can be similar to SOAP communication.

• UDDI checking operation: it certainly depends on different UDDI implementation. UDDI

private registry as used in the Travis prototype is much more efficient than UDDI public registry (the one globally available) in terms of performance. Even for UDDI private registry, it also depends on data operation. As has been illustrated previously, using JDBC call to the database is indeed a time-consuming process, which needs to be avoided. Rather than using database and consuming so much time for data searching and matching, other methods as [18] proposes a more general XML Object infrastructure to be a replacement of existing UDDI in terms of XML meta-data registering and searching function. And possible development of Semantic Web [12, 18] will be relevant.

• Query return operation to the service requester: WSDL is once again used in the

operation, same as find operation, this XML messaging cost similar time as SOAP part. All of these three operations add up to a big consuming part of total UDDI lookup time. Therefore, it would be wise to choose an approach that on one hand requester can dynamic find update information from UDDI in terms of all the changing, on the other hand, keep time as short as it can be and try to avoid UDDI lookup operation if possible. There are some options can be thought about, such as, using caching technology, using coarse-grained services as will be discussed in the following section. However, actually how to make this balance happen is still an open issue and can be studied in the future research.

5.5.4 Improvement Granularity: Web Services granularity can be divided into fine grained and coarse grained in terms of aggregation of different functionalities. Simple and less functional Web Service (e.g. StockQuote information searching WS) can be seen as fine grained Web Service, and more functional Web Service with large aggregation of services (e.g. Flight Booking WS in the prototype) is viewed as coarse grained Web Service. If all services are found by service requester from UDDI registry are mostly fine grained Web Services, the invocation of all these WS can generate a big amount of unnecessary network traffic and overhead of the communication stack. In order to avoid this and reach relatively good performance, these existing JavaBean/EJBs with fined grained methods/operations can be aggregated into coarse-grained Web Services. This is line with the Request Batching technique recommended by [69]. The advantage of using this technique also makes it possible to push the transaction integrity requirements to the Web Services provider making for “clean” design. In other words if a coarse grained request did not


71

successfully complete, then the Web Service provider can roll back that entire transaction. However, trade-off between fine grained and coarse grained Web Services need further discussion. Scalability: There are two ways to enhance the scalability of Web Services. First is using existing web techniques for increasing throughput, for instance, acceleration hardware or consider load balancing. Second is using caching technology:

• Maintain state information on the Web Service provider side, use session id to access persistent data.

• Despite being dynamic, caching of responses for certain transactions may be feasible, and this work is well for non-user specific data, especially if invalidation is simple. User specific data can be cached.

In General, there are two methods can make the improvement, first, design for coarse-grained interactions; second, make load balancing service architecture, and re-use some numbers of invocations per transaction if necessary.

Chapter 6 Web Services and Grid Computing

72

Chapter 6 Web Services and Grid Computing In this chapter, Grid computing is introduced; the Grid service concept is described, the Web Services combined Grid computing values is specified and followed by some examples of usage in computational science area and discuss its limitations.

6.1. Grid Computing Overview Grid is indicated as a proposed distributed computing infrastructure for advanced science and engineering [28]. It is distinguished from conventional distributed computing by its focus on large-scale, resource sharing, innovative application and high-performance orientation, which has been explained and defined as Virtual Organization (VO) in terms of the rising “Grid problem” and the encountered issues in [1]. Grid computing defines the sharing clearly as what is shared, who is allowed to share, and the conditions under which sharing occur. The real and specific problem that underlies the Grid concept is coordinated resource sharing and problem solving in dynamic, multi-institutional virtual organization [30]. The establishment, management, and exploitation of dynamic, cross-organizational VO sharing relationships require Grid architecture, in which protocols, services, application programming interfaces, and software development kits are categorized according to their roles in enabling resource sharing. The grid will have advanced applications running on a tremendously powerful supercomputing facility to aid the radiologist, or any other physician, in analyzing precisely what’s going on in a particular patient. If multiple physicians, perhaps scattered across the country (or even spread all over the world) need to consult and view a particular mammogram, this Grid will give them access to the information as if they were in the same room of the same hospital. That’s the example of the kinds of virtual collaboration and virtual organization that Grid computing is trying to address. For instance, brain mapping research, which is absolutely critical to better understand and treat Alzheimer’s, schizophrenia, Parkinson’s, multiple sclerosis and a whole set of neurological diseases that people don’t fully understand now. The problem with brain mapping research is that each MRI of the brain can take up a huge amount of storage. And physicians need lots of images of different brains for comparison; and need to do this as a collaborative effort between multiple centers, each of which can share the data and analyzing tools with others. Desired attributes for distributed computing on the Grid:

• Allow computing resources to be accessed and shared across a heterogeneous wide area network, which provides language independent; platform independent; support resource discovery, access, brokering; access not only software, but also underlying computing resources.

• Deliver qualities of service transparently, which includes seamless integration with

existing IT resources; distributed application workload management; scalable performance; distributed security model across administrative domains; logging; problem determination; health monitoring, checkpoint, coordinated fail over.


73

Grid computing, emerging from the science and technical community, generates new e-business infrastructure opportunities with expansion of resource sharing and problem solving on the Internet. This allows all researchers to build and participate in virtual organizations. Grid computing also highlights the need for open standards and for self-managing technologies. There are two points need to be highlighted in terms of the relation with Grid computing and Web Services. First, grid capabilities are actually also emerging in the commercial world. But in the commercial domain, it has been using Web Services terminology to describe how to start integrate applications with each other. Web Services applications are very much in the spirit of the Grid initiative, in that they are focused on sharing resources over the Internet, especially applications. Open protocols will enable an enterprise to link anything-to-anything easily, making outsourcing a simple business decision rather than a major architectural issue. Second, interoperability is the central issue to be addressed. In a network environment, interoperability means common protocols. Hence, the advantage of Grid computing and Web Services architecture are their protocol architectures, with protocols defining the basic mechanisms. A standards-based open architecture facilitates extensibility interoperability, portability, and code sharing; standard protocols make it easy to define standard services that provide enhanced capabilities.

6.2. Grid Services Grid computing has been discussed in Chapter 2. In this section, an innovative Grid services concept will be explained, which addresses the relations between Web Services and Grid computing in a much broader area. Grid architecture has established requirements for the protocols and APIs that enable sharing of resources, services, and code. However, as indicated in the [31], Grids constructed with these different protocols are not interoperable and cannot share essential services – at least not without gateways. Therefore, the long-term success of Grid computing requires selecting and achieving widespread development of one set of protocols at the Connectivity layer, which enable different organizations to interoperate and exchange or share resources. This is the place where Web Services come to the way. In paper [30], it describes how Grid mechanisms can implement a service-oriented architecture, explains how Grid functionality can be incorporated into a Web Services framework and be applied within commercial computing as a basis for distributed system integration. Open Grid Services Architecture (OGSA) [30] complements the previous protocol-oriented descriptions and views Grid as an extensible set of Grid services that may be aggregated in various ways to meet the needs of Virtual Organizations [31], which themselves can be defined in part by the services that they operate and share. OGSA uses WSDL to achieve self-describing, discoverable services and interoperable protocols, with extensions to support multiple coordinated interfaces and change management. It defines conventions and WSDL interfaces for a Grid Service, a Web Service that provides a set of well-defined interfaces and that follows specific conventions. The interfaces address reliable and secure invocation, lifetime management, notification, policy management, credential


74

management, and virtualization. It also specifies interfaces for the discovery of Grid service instances and for the creation of transient Grid service instances. Just as the World Wide Web began as a technology for scientific collaboration and was adopted for e-business, Grid technologies is expected a similar trajectory. Nevertheless, [30] argues that grid concepts are critically important for commercial computing not primarily as a means of enhancing capability, but rather as a solution to new challenges relating to the construction of reliable, scalable, and secure distributed systems. In OGSA, the services are referred to computational resources, storage resources, networks, programs, databases, etc., which has more broader meaning than it is stated in Web Services concept. The development of OGSA also represents a natural evolution of Web Services. By integrating support for transient, stateful service instances with existing Web Services technologies, OGSA extends significantly the power of the Web Services framework, while requiring only minor extensions to existing technologies.

6.3. What Can Web Services Bring to Grid Computing? The nature of Web Services has the same properties as Grid computing: interoperability, protocol architecture, standard-based open architecture and standard services, application programming interface and software development kits. Similarity of Web Services and grid computing also reflect in their layered architectures. Grid computing has fabric, connectivity, resource, collective, application layers, which can be mapped into different layer in the Internet Protocol Architecture. Similar architecture for Web Services has been introduced in Chapter 2. Web Services framework has two advantages to be used in the OGSA. First, mainly achieving by using WSDL, which provides a standard mechanism for Web Services registering and discovering interface definitions and endpoint implementation descriptions; it helps dynamically generating proxies based on bindings for specific interfaces; it separates the service interface with its embodiment within a particular binding. Second, Web Services open standards attract widely adoption and enormous developing efforts, which results in numerous tools and extant services. One of the significant properties of Web Services is its composable, which can be exposed through WSDL. Therefore all those composition mechanisms are really interchangeable by means of WSDL. This is a layer of abstraction that adds up to the robustness of Web Services technology, which can very much contribute to the Grid computing. The major values Web Services can bring to Grid computing can be summarized as: Enable interoperability:

• Definition of service interface • Identification of the protocol used to invoke a particular interface


75

Encapsulation:

• Realize local/remote transparency • Separate and distinct the common interface and diverse implementation

Composition:

• Individual service form sophisticated services • Component-based workflow

Uniform services semantics

• Transient service instance emphasize on lightweight entities/short-lived activities • Standard interfaces (discovery, dynamic service creation, lifetime management,

notification, etc.) Integration is easier if service functions can be expressed in a standard form, so that any implementation of a service is invoked in the same manner. With respect to this, WSDL is thought to be most valuable standard for Grid services combination for its composable, interface and implementation separation, which generates a model for Services with ports communicating by message with a general XML specified structure. A critical requirement in a distributed, multi-organizational Grid environment is how to enable interoperability, which can be interpreted as two parts: one is the definition of service interface and the other one is identification of the protocol that can be used to invoke a particular interface. The application of Web Services mechanisms to Grid computing has also been investigated and advocated by others (e.g., [16, 17, 18]), with a recent workshop focusing on this issue and providing overviews of a number of interesting and relevant efforts. For example, [11] discusses the application of various contemporary technologies to e-science applications and propose “application factories” as a means of creating application services dynamically. [12] discusses how to extend the Grid to construct a smarter “Semantic Grid”, by analogy to the Semantic Web, and propose a range of higher-level services.


76

6.4. Contribution and Limitation to Scientific Computing Web Services are being developed actively by many major companies with the idea of componentizing business-to-business or business-to-consumer applications. However, it is not limited to business activities, but applied to science and engineering as well, just as discussed in the previous two sections about Grid services and values result from the combination. As stated in [18], a similar approach is useful in both Grid system services but also more generally to develop “Science as a Web Service”, which has been termed and heavily investigated in a series of UK national e-Science projects. There are several obvious ways that the Web Services model can be used in Grid computing as explained in [11], which are also called Grid-Web Services. For example, Grid authorization service, Grid application resource broker, Grid co-scheduling service, Grid file object metadata directory, etc. However, in order to be more specific and in particularly, clarify how Web Services can be used in scientific computing environment in a more clear way, here are four general computational science problems, which can be wrapped as Web Services. Some of these problems have been discussed in [17]:

• Simulation services: make separate simulations by using different solver. • Pattern dynamics analysis services: data analysis system enables users to build and test

modules. • Image processing services: make separate services by using different algorithms. • Visualization services: process the data and display the visualization result.

There are several important problems in Web Services for scientific use that are not being addressed by commercial world.

• The latency of Web Services component communication is much slower if low-latency parallel algorithm is required.

• It is very difficult to handle when gigabytes or terabytes large data size file is separate from the visualization or simulation tool, which are only remotely available.

• Precise data measurement and fragile hardware (supercomputer) require far more higher robustness and quality of services.

Composable Web Services by means of open standard WSDL interface and component-based workflow require carefully designed process to break the entire system into modules. Thus one should carefully evaluate where to break one system into components and keep this reasonably coarse grain.


77

6.5. Future Research Due to their critical interoperability requirements, gird architectures are moving toward standard protocols and a service-based architecture, although, again, Web Services standards are at a more mature stage in their lifecycle. It is clear, however, that grid-type of computational power can be described and provided as a service, once all the issues with security, dynamic partnership, access control, and quality of service have been properly addressed. There are several issues that would be valuable to discuss for the further Grid computing research addressing:

• Within grid environments, define a good mechanism to let services to have fast access to large amounts of data (terabytes or even petabytes), which are often distributed in a wide-area network, with considerable diversity, dynamic behavior and geographical distribution. This indeed requires varied quality of service requirements, such as security, data transport, performance and replication etc.

• Security for the high performance computing services needs consideration, authentication, authorization, integrity, confidentiality, etc.

• Complicated grid Web Services for scientific application can be composed as component-based simple “atomic” grid services; defining workflow and job event in this case is very difficult in terms of numerous error conditions.

• Diversity of grid services, in terms of large-scale datasets, powerful visualization tool, complicated simulation environments, scientific instruments, requires highly defined requirement regarding QoS (quality of services).

• Precise event model for specific scientific application is very important to fulfill the promised synchronous collaboration.

• Performance issues, such as resource balancing, scalability, utilization of the infrastructure, etc.

• Using scientific instruments in real-time computation and visualization, producing a situation similar to synchronous collaborations.

Chapter 7 Conclusions and Future Directions

78


7.1 Summary Web Services describe an important emerging distributed computing paradigm that differs from other approaches such as DCE, CORBA, and Java RMI in its focus on simple, Internet-based standards to address heterogeneous distributed computing. Web Services define a technique for describing software components to be accessed, methods for accessing these components, and discovery methods that enable the identification of relevant service providers. To support the thesis that Web Services architecture and properties can deliver significant value to services providers, requesters, compared to traditional approaches. The following actions have been taken:

• Investigated the model, architecture, added value and different scenarios that Web Services support.

• Discussed how Web Services technology relates to other contemporary technologies, and

stated that Web Services concepts and technologies complement and have much to contribute to these other approaches.

• Designed a Web Services scenario called Travis, which is generic enough to

accommodate different usage models and maps well onto the architecture of wide-area distributed systems.

• Developed a Web Services prototype based on the Travis scenario, which uses several

Web Services development and implementation techniques and has been demonstrated in various presentations. The prototype also creates Web Services environment to allow repeatable performance evaluation under different scenarios.

• Identified the major problems and key requirements that Web Services security needs to

support. Designed a Web Services security token services model on different scenarios based on the existing security efforts and implementation.

• Evaluated the performance of SOAP message and UDDI lookup communication

overhead through a series of simulations by varying the number of users, type of bindings, and

• Specified the advantage and disadvantage of Web Services, and its contribution to Grid

computing. Discussed the future directions of Grid services development.


79

7.2 Conclusions In this thesis, Web Services are not only seen as an application integration concept, but also put in a more general – distributed computing area – with other diverse range of new and emerging distributed computing approaches. Regardless of the application, Web Services can be used for systems integration: flexible, loosely-coupled systems integration yielding systems that can be decomposed and recomposed to reflect changes in the computing environments. To address the major features of Web Services, a prototype called Travis has been developed. The use of component-based architecture has enabled the implementations of integrating multiple, geographically distributed services using both static-binding and dynamic-binding with a minimal development effort. In addition, several development tools have been examined to facilitate the development. And the tools well support the majority of the development and implementation. The results of experiments with different requirements show promising insights into the effectiveness of Web Services standards for systems integration and its usefulness in interoperable collaboration with encapsulation (interface separates from implementation). It also proves that Web Services indeed enable the sharing and aggregation of geographically distributed resources for solving real-world computing problems easier. The conclusion can be made that Web Services standards are at a mature stage in their lifecycle. A number of security aspects have been discussed with a variety of functional requirements by selecting different related security efforts and implementations. They can be categorized into the following two issues:

• Communication between provider and requester: identification, authentication, and integrity;

• UDDI involvement: identification, authentication, and confidentiality. In a Web Services environment as Travis demonstrated, the preliminary security token model is proposed based on different binding types (static and dynamic). In static binding case, three authentication and integrity approaches are discussed together with business policy enforcement. In the dynamic binding case, the UDDI operator node and general dynamic security token model are proposed. This general messaging model allows use of existing technologies such as X.509 public-key certificates, Kerberos shared-secrete tickets and even password digests to enable identification and authentication. Security token provides an integrating abstraction allowing systems to build a bridge between different security technologies (transport security, PKI, Kerberos). The general model is sufficient to construct higher-level key exchange, authentication and trust mechanisms. Some tests have been designed to evaluate the performance of established prototype through a series of simulations by varying the number of users, binding types and breakdown points. The scalability result shows that as number of users increases total response time is increased nearly linearly until it reaches the maximum system affordable load without further performance tuning. The major reason has found due to the JDBC call in the service provider forming the Web Services. Also, the results of breaking down timers demonstrate that SOAP communication and UDDI lookup are bottlenecks in messaging system performance. It allows requesters to trade-off between static binding and dynamic binding. There are two suggested approaches, grain coarse and caching technology.


80

The discussion about relation of Web Services and Grid computing offers an insight of the concept of Grid computing and Grid Services, proves that scientific computing, in particular, Grid computing can benefit very much from Web Services regardless some limitations.

7.3 Future Directions This thesis work has laid a demonstrated Web Services architecture prototype, security and performance evaluation and it opens up several avenues for future work in Web Services technology.

7.3.1 Accounting Within Web Services community, there is a great interest in building an accounting model and infrastructure. In the prototype chapter, a single portal single transaction to multiple service providers concept has been proposed. Now the questions rise: How to define how long a user can access and execute a Web Service? How to charge for provided services? Will the dominant model be subscription-based, or pay-as-you-go? Can a Web Service be totally consumed on use, or the service can be reused multiple times as part of the purchase agreement? To support anonymous online payments, digital currency might be very useful. It has been noted that electronic currency technology is rapidly progressing with emerging e-business infrastructures such as NetCash, NetCheque, and Paypal [51].

7.3.2 Composed Web Services Another remarkable feature as discussed previously is one Web Service can be composed with other Web Services, which represent the work flow of part of the process or even entire process. The Web Services in Travis prototype are all simple and straightforward functional services. Rather than simply using inquiry flight Web Service, Flight company can designed to aggregate search service, booking service, payment service, notification service, etc. into one sophisticated flight service. In medical field, hospitals in the future would like to be able to store patient folders on-line, enabling doctors to search data and use services within and across folders, within and across organizations boundaries. More advanced, physicians can compose various services, for example, visualization service (e.g. MRI scanning data), blood flow simulation service, document management service (e.g. lab report), image process service etc. into one profound treatment service.


81

7.3.3 Other Security Aspects Only a few aspects (identification, authentication, integrity) of Web Services are discussed so far in the thesis, there are more issues (authorization, privacy, etc.) need to be addressed by Web Services security architecture in the future. There are not (yet) standards that address auditing, non-repudiation and authorization. Single sign-on is another significant issue of Web Services security.

7.3.4 Performance Enhancement Preliminary results have been found regarding static and dynamic binding on Travis prototype in terms of performance scalability. The current measurement can be extended to a comparison with CORBA and DCOM techniques based on an implementation. Furthermore, more research can be conducted to allow trade-off between different bindings.

7.3.5 Computing as a Utility While the Application Service Provider (ASP) model currently is renting computing on their own platform to consumers who generally pay on a monthly subscription basis, the future trends would be using computing as a utility regardless the platform and application functionality provider dependency by using Web Services. For example, Stephen arrives at his hotel room, plugs in his PDA in a so-called computing plug in the wall and starts working. His software agent finds the services that he is going to need, based on where he is and what he wants to achieve. These could be software services (e.g. collaborate with some colleagues in different location; use Travis to book his holiday), or hardware services (e.g. run a stress simulation on an application design).

Appendix A

82

Appendix A Abbreviations Used in The Thesis ASP – Application Service Provider DTD – Document Type Definition EAI – Enterprise Application Integration HTML – Hypertext Markup Language HTTP – Hypertext Transfer Protocol HTTPR – Reliable HTTP J2EE – Java 2 Platform Enterprise Edition JDBC – Java Database Connection JDK – Java Development Kit JMS – Java Messaging Service MSMQ – Microsoft’s Message Queue PKI – Public Key Infrastructure QoS – Quality of Service RMI-IIOP – Remote Method Invocation over Internet Inter-ORB Protocol RPC – Remote Procedure Call RTT – Round Trip Time SAML – Security Assertion Markup Language SMTP – Simple Mail Transfer Protocol SOAP – Simple Object Access Protocol (Services Oriented Architecture Protocol) SQL – Standard Query Language SSL – Secure Socket Layer UDDI – Universal Description Discovery Integration UML – Unified Modeling Language URL – Uniform Resource Locator W3C – World Wide Web Consortium WAS – WebSphere Application Server WSAD – WebSphere Studio Application Developer WSDE – Web Services Development Environment WSDL – Web Services Description Language WSIF – Web Services Invocation Framework WSTK – Web Services Toolkit XML – Extensible Markup Language

Reference

83

Reference 1. “CORBA: Common Object Request Broker Architecture”, http://www.corba.org 2. “Security in a Web Services World: A Proposed Architecture and Roadmap”, a joint security

whitepaper from IBM corporation and Microsoft corporation, April 7, 2002, Version 1.0 3. A Primer to HTTPR, http://www.ibm.com/developerworks/webservices/library/ws-http/ 4. A. van Dorp, A. de Mes, E. Rongen, T. van Velzen, R. van Wel., Enterprise Application

Integration with Web Services (Technical Report), January 2002. 5. A. Vidovic, B. Maatta, B. Jenkin, B. Matzen, P. Nuutinen, “Java and WebSphere

Performance on IBM eServer iSeries Servers”, International Technical Support Organization, February 2002

6. AKtools. http://aktools.raleigh.ibm.com/ 7. Apache SOAP, http://xml.apache.org 8. B. Atkinson, G. Delta-Libera, S. Hada, M. Hondo, P. Hallam-Baker, J. Klein, B. LaMacchia,

etc. Web Services Security (WS-Security), a joint effort from IBM corporation and Microsoft corporation, April 5 2002, version 1.0

9. Bieszczad, A., Wite, T., Pagurek, B. (1998); Mobile Agents for Network Management. In IEEE Communications Surveys, September 1998.

10. Creation and Usage with WebSphere Studio Application Developer (IBM Redbook) UDDI Community, http://www.uddi.org/community

11. D. Gannon, R. Bramley, G. Fox, etc., Programming the Grid: Distributed Software Components, P2P and Grid Web Services for Scientific Applications, Department of Computer Science, Indiana University 2002.

12. De Roure, D., Jennings, N. and Shadbolt, N. Research Agenda for the Semantic Grid: A Future e-Science infrastructure. UK National eScience Center, 2002, www.semanticgrid.org.

13. Design Patterns: Elements of Reusable Object-Oriented Software. Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides. Addison Wesley Publishing Company, 1995.

14. Dynamic e-business: Using Web Services to transform business, http://www-106.ibm.com/developerworks/library

15. Entropia, http://www.entropia.com 16. Fox, G., Balsoy, O., Pallickara, S., Uyar, A., Gannon, D. and Slominski, A. Community

Grids. Community Grid Computing Laboratory, Indiana University, 2002 17. G. Fox, M. Pierce, S. Ko, etc., Grid Services for Earthquake Science, Indiana University,

Florida State University, etc. 2001 18. G. Fox, S. Pallickara, The Narada Event Brokering System: Overview and Extensions.

Community Grid Labs, Indiana University. 2001 19. G. R. Malan, F, Jahanian, C. Rasmussen, and P. Knoop, “Performance of a Distributed

Object-Based Internet Collaboratory”, Technical Report CSE-TR-297-96, University of Michigan EECS Department, July 1996.

20. G. R. Malan, F. Jahanian and P. Knoop, “Comparison of Two Middleware Data Dissemination Services in a Wide-Area Distributed System”, Proceedings of the 17th IEEE International Conference on Distributed Computing Systems, May 1997, Baltimore, MD.

21. Global Grid Forum, http://www.gridforum.org/ 22. Globus Project, http://www.globus.org 23. Gnutella: http://gnutella.wego.com/ 24. Grid Web Services Workshop 2001:

https://gridport.npaci.edu/workshop/webserv01/agenda.html 25. Heather Kreger (May, 2001), Web Services Conceptual Architecture (WSCA 1.0), IBM

Software Group, http://www-106.ibm.com/developerworks/library

http://www.semanticgrid.org/

Reference

84

26. HTTPR Specification, http://www.ibm.com/developerworks/webservices/library/ws-phtt/httprspecV2.pdf

27. HyperText Transfer Protocol (HTTP), http://www.w3.org/Protocols/ 28. I. Foster and C. Kesselman, The Grid: Blueprint for a Future Computing Infrastructure.

Morgan Kaufmann Publishers, USA, 1999. 29. I. Foster, C. Kesselman, J. M. Nick, S. Tuecke: The Physiology of the Grid: An Open Grid

Services Architecture for Distributed Systems Integration. 2002 30. I. Foster, C. Kesselman, S. Tuecke, “The Anatomy of the Grid: Enabling Scalable Virtual

Organizations”, Intl. J. Supercomputing Applications, 2001 31. I.Clarke, O. Sandberg, B.Wiley, and T. W. Hong, “Freenet: A Distributed Anonymous

Information Storage and Retrieval System”, ICSI Workshop on Design Issues in Anonymity and Unobservability, 1999.

32. Intel Proposals on Peer-to-Peer Computing, http://www.intel.com/ebusiness/products/peertopeer/index.htm

33. Internet Performance Measurement and Analysis (IPMA) project homepage, http://nic.merit.edu/ipma/

34. J. Hunter, “Java Servlet Programming”, 1st edition, O’Reilly, California (1998). 35. Java Remote Method Innovation,

http://java.sun.com/products/jdk/rmi/http://java.sun.com/products/jdk/rmi 36. Java Servlet API Specification, http://java.sun.com/products/servlet/2.2/ 37. JiPANG - A Jini based Computing Portal System, http://ninf.is.titech.ac.jp/jipang/ 38. JMeter: http://www.apache.org/ 39. L. Gong, Project JXTA: A Technology Overview, Technical Report, Sun Microsystems Inc.,

April 2001, http://www.jxta.org/project/www/docs/TechOverview.pdf 40. M. B. Juric, I. Rozman, M. Hericko, T. Domajnko: CORBA, RMI and RMI-IIOP

Performance Analysis and Optimization. University of Maribor, Slovenia. 2001 41. M. Hondo, N. Nagaratnam, A. Nadalin, “Securing Web Services”, IBM System Journal, Vol

41, No 2, 2002 42. M. Pierce, C. Youn, G. Fox, The Gateway Computational Web Portal: Developing Web

Services for High Performance Computing. Indiana University. 43. Mazumdar, S; Mapping of Common Management Information Service (CMIS) to CORBA

Object Services; Bell Labs.; September 1996; 44. Microsoft .NET, http://www.microsoft.com/net/ 45. Napster, http://www.napster.com/ 46. P. Kovari, V. Amor, M. Fuchs, J. Hodgson, J. Roca. IBM WebSphere V4.0 Advanced Edition

Security. IBM Redbook, International Technical Support Organization, March 2002. 47. Parabon, http://www.parabon.com 48. PushToTest. http://www.pushtotest.com/ptt/ 49. R. A. Whiteside, E. J. Friedman-Hill, and R.J. Detry, “PRE: A framework for enterprise

integration”, Proc. Of Design and Informaiton Infrastructure Systems for Manufacturing (DIISM), Fort Worth, TX, May 1998.

50. R. Buyya: Economic-based Distributed Resource Management and Scheduling for Gird Computing. Ph.D. Dissertation, Monash University, Melbourne, Australia, April 2002.

51. S. Graham, S. Simeonov, T. Boubez, G. Daniels, D. Davis, Y. Nakamura, R. Neyama: Building Web Services with Java: Making Sense of XML, SOAP, WSDL, and UDDI. Sams Publishing, January 2002.

52. SETI@home, http://setiathome.ssl.Berkeley.edu 53. Simple Object Access Protocol (SOAP), http://www.w3.org/TR/SOAP 54. SOAP Security Extensions: Digital Signature, published February 6th, 2001.

http://www.s3.org/TR/SOAP-dsig/ 55. Sun ONE, http://www.sun.com/sunone

http://www.apache.org/

http://www.pushtotest.com/ptt/

Reference

85

56. U. Wahli, M. Fielding, G. Mackown, D. Shaddon, G. Hekkenberg. Servlet and JSP Programming: with IBM WebSphere Studio and VisualAge for Java. IBM Redbook, International Technical Support Organization, May 2000.

57. UDDI4J Project, http://www.ibm.com/developerWorks/library/ws-uddi4j.html 58. Universal Description Discovery and Integration (UDDI), Technical White Paper,

(September 6, 2000), http://www.uddi.org 59. Web Services Description Language (WSDL), http://www-

106.ibm.com/developerworks/library/w-wsdl.html 60. Web Services Flow Language (WSFL),

http://www.ibm.com/software/solutions/webservices/pdf/WSFL.pdf 61. WSDL4J Open Source, http://oss.software.ibm.com/developerworks/projects/wsdl4j 62. Apache AXIS: http://xml.apache.org/axis/index.html 63. Web Services Development Toolkit (WSTK): http://www-106.ibm.com/developerworks 64. Web Services Development Environment (WSDE): http://www-106.ibm.com/developerworks 65. Jini Network Technology, http://www.sun.com/jini 66. Presentation on IBM client ODINA, April 22, Jaarbeurs, Utrecht, The Netherlands 67. T. Li, Web Services Technology, Seminar on Modern Advanced Technology, Association of

Chinese Students and Scholars in The Netherlands (ACSSNL), December 1, 2001, Utrecht, The Netherlands

68. "Skills Me" session presentation, April 10, 2002, Uithoorn, IBM, The Netherlands 69. Super Scalable Architecture Report, http://coe.ibmus2.ibm.com