Ryan Michael

7/29/2019 Ryan Michael

1/156

Enterprise System Integration with Web Services:

A Case Study with a Book Broker Application

by

Michael Ryan

Submitted in partial fulfillment of the requirements

for the degree of M.S. in Computer Science

at

School of Computer Science and Information Systems

Pace University

August 2005


2/156

ii

ABSTRACT

Web services are gaining a tremendous amount of momentum in recent years as a viable tool indistributed computing. Web Services have evolved from other distributed technologies, whichinclude Java RMI, CORBA, and DCOM, but their specification deficiencies with respect to

complete platform and programming language independence, and interoperability are creating aneed for a more suitable solution. Despite its youth, Web Services offer to provide such asolution by inheriting the beneficial traits of its predecessors, utilization of an IDL in the form ofa WSDL (Web Service Description Language) for one, and at the same time, avoiding thenegative aspects associated with its predecessors, which include tight coupling specifications,potential for firewall blocking, long development times, and higher costs. Through the use ofstandardized technologies (HTTP, SOAP, and XML), Web Services offer to deliver results.

I present a book broker in two formats: as a web interface and as a Composite Web Service.Both formats provide book-pricing data from various vendors and book search functionalitybased on any combination of factors, such as author, title, publisher, keyword and ISBN. The

purpose of this project is to provide a publicly accessible book broker that is superior infunctionality to existing book brokers today, to enable developers to integrate my Web Serviceinto their own applications, promoting data exchange regardless of the platform or programminglanguage being used and lastly, to provide a good case study of how to bring out the best in WebServices.


3/156

iii

ACKNOWLEDGEMENTS

I would like to thank my advisor, Dr. Lixin Tao, for his guidance and expertise. Many timeswhen I began to veer off course, he would step in and put me back on track.

I would like to thank the department Chairperson, Dr. Narayan Murthy, for convincing me topursue my thesis and making me aware of the potential personal rewards that come about fromthe entire process.

A special thank you to Dr. Mary Courtney for her motivational comments, finding time todiscuss my project and for re-shuffling her schedule on my behalf.

Finally, I would like to thank my entire family for their feedback, support and love.


4/156

iv

TABLE OF CONTENTS

LIST OF TABLES viii

LIST OF FIGURES ix

CHAPTER 1 INTRODUCTION

1.1 Enterprise Integration Dilemma 11.2 Web Service Defined 11.3 Enterprise Integration Web Service Solution 21.4 Phases of Adoption 41.5 CWS Solution 41.6 Overview 5

CHAPTER 2 B2B SYSTEM INTEGRATION TECHNOLOGIES

2.1 Distributed Computing Technologies 62.1.1 Java RMI 62.1.2 CORBA 72.1.3 DCOM 72.1.4 Web Service Evolution 8

2.2 Web Service Architecture 112.2.1 Protocol Layer-HTTP 112.2.2 Packaging Layer-SOAP 122.2.3 Information Layer-XML 142.2.4 Service Layer- Web Service & WSDL 14

2.2.5 Discovery Layer-UDDI 162.2.6 Alternative Layers-REST and HTML Scraping 172.2.7 Web Service Stack Analysis 18

2.3 Web Service Industry Trends 19

2.4 Current Book Broker Environment 20


5/156

v

CHAPTER 3 CWS ANALYSIS & ARCHITECTURE

3.1 CWS Requirements 21

3.2 CWS Functional Specifications 22

3.3 CWS Design 243.3.1 Architecture 243.3.2 Methods Used 263.3.3 Data Structures 293.3.4 CWS Web User Interface-CWSUI 293.3.5 CWS Composite Web Service-CWSWS 29

3.3.6 Hardware and Software Specifications 30

CHAPTER 4 CWS IMPLEMENTATION

4.1 Overview 31

4.2 CWS Web Interface 314.2.1 View 314.2.2 Controller 33

4.2.2.1 The searchIsbn() Method 354.2.2.2 Vendor methods 35

4.2.2.3 The amazon() Method 374.2.3 Model 38

4.3 CWS Web Service 384.3.1 CWS Service 384.3.1.1 Deployment 404.3.2 CWS Client 414.3.2.1 Java Client 424.3.2.2 .NET Client 434.3.3 CWS Discovery 434.3.3.1 Publishing CWS 444.3.3.2 Performing a CWS Query 45

CHAPTER 5 CWS TEST CASES

5.1 Use Case Verification 48

5.2 CWS vs. Current Book Brokers 61


6/156

vi

5.2.1 Third Party Web Services 615.2.2 BookFinder4u.com 645.2.3 Chambal.com 645.2.4 FetchBook.info 65

CHAPTER 6 CONCLUSION

6.1 CWS Interoperability Solution 66

6.2 Future of Web services 676.2.1 Market Research Statistics and Forecasts 676.2.2 Potential Trends 686.3 Potential Pitfalls 69

APPENDIX 1 Web service enabling products 71

APPENDIX 2 Index.jsp 84

APPENDIX 3 Results.jsp 86

APPENDIX 4 Controller.java 88

APPENDIX 5 BookBean.java 100

APPENDIX 6 Error.jsp 102

APPENDIX 7 Search.jsp 103

APPENDIX 8 CWS.wsdl 105

APPENDIX 9 Aboutus.jsp 107

APPENDIX 10 BookServerImpl.jws 108

APPENDIX 11 IBookSearch.java 120

APPENDIX 12 CWSBookSearchClient.java 121

APPENDIX 13 cwsForm.cs 125

APPENDIX 14 BookServerImplService.cs 130

APPENDIX 15 AssemblyInfo.cs 132

APPENDIX 16 PublishCWS.java 133


7/156

vii

APPENDIX 17 FindCWS.java 135

APPENDIX 18 Configurator.java 137

APPENDIX 19 PropCWS.properties 139

APPENDIX 20 CWS Build Manual 141

APPENDIX 21 CWS User Guide/Maintenance Manual 143

REFERENCES 146


8/156

viii

LIST OF TABLES

Table 1 Current Web Book Brokers 20

Table 2 CWS Hardware and Software Specifications 26

Table 3 UDDI Registry Access Point URLs 41

Table 4 Future Trends in Web Services 66


9/156

ix

LIST OF FIGURES

Figure 1 Web Service Stack 10

Figure 2 SOA Model 24

Figure 3 Model 1 JSP Architecture 25

Figure 4 Model 2 JSP Architecture 25

Figure 5 CWS MVC Architecture 27

Figure 6 CWS Sequence Diagram 28

Figure 7 CWS Data From IBM UDDI Registry 45


10/156

1

CHAPTER 1 INTRODUCTION

1.1 Enterprise Integration Dilemma

Enterprises continue to face the dilemma of integrating heterogeneous applications to

meet the demands of business. Firms struggle to manage the costs associated with

correcting internal, integration inefficiencies or with efforts to expand existing

applications to trading partners, service providers or third parties. Firms are continuously

attempting to maintain and improve their business-to-business (B2B), business-to-

consumer (B2C), department-to-department, or peer-to-peer relations. Web services are

gaining a tremendous amount of momentum in recent years as a viable solution to this

problem. Whether the environment is within an enterprises intranet or beyond their

firewall, Web services offer to connect disparate systems regardless of platform,

programming language or vendor.

1.2 Web Services Defined

In it simplest form, a Web service is an application or function that is defined and

published to be called over a network. Web services are classified as a distributed

technology, are appropriate to any type of networking environment and can support

business-to-business (B2B), business-to-consumer (B2C), department-to-department, or

peer-to-peer relations. Web services incorporate open standards (i.e. SOAP, XML,

HTTP), which result in a modular structure that provides a foundation for application

integration, data exchange, elimination of component lock in and improved

interoperability. The functionality provided by a Web service can vary from simple data

retrieval requests to complex business processes. A basic Web service may be


11/156

2

discovered and invoked to access a weather report, research currency exchange rates, or

retrieve a book price. A more complex Web service may be invoked to handle multiple

transactions within an enterprises supply chain application, which includes purchase

orders, work orders, financial and client reporting, and manufacturing data.

One of the most compelling aspects of Web services is the ability to aggregate various

Web services into one higher-level Web service by way of process composition that is

executed in a specific sequence. The open standard, building blocks that make up the

Web service architecture allow for the implementation of multiple Web service

invocations and can lead to new functionality. A consumer can now invoke a composite

Web service and shop for multiple currency exchange rates from numerous Web services

all from one locale. An enterprise can improve their supply chain application by adding a

composite Web service that researches suppliers offering the best prices. Web service

composition creates more flexibility for consumers and enterprises, promotes code re-

usability and increased quality of service.

1.3 Enterprise Integration Web Service Solution

Through the use of open standards, process composition, and loose coupling

specifications, Web services offer to correct the integration problems many Enterprises

face today. The cause of these integration problems is that since many applications are

built around different platforms and programming languages, it is difficult to have these

applications interoperate effectively. Many business applications are written in various

programming languages, such as C++, Java, Visual Basic, and reside on various


12/156

3

platforms, such as Windows or Linux based systems. Moreover, most business data are

still kept on mainframes in non-relational (VSAM) files and accessed by mainframe

applications written in COBOL. The programming languages themselves present a few

barriers. A few specific conflicts include the use of Javas Collection class, passing an

array with a null element, and namespace conflicts. Despite these obstacles, Web

services present a solution by establishing a common ground for all parties to interoperate

effectively.

Additionally, in an effort to provide Web service guidelines, constraints and practical

recommendations, the Web Services Interoperability Organization (WS-I) has been

formed and delivers sets of use cases, profiles, sample applications and test tools. WS-I

has provided the Basic Profile (BP) 1.0 specification to address existing interoperability

issues. A few of the key BP constraints [8] include:

Precludes the use of SOAP encoding

Requires the use of HTTP binding for SOAP

Requires the use of HTTP 500 status response for SOAP Fault messages

Requires the use of HTTP POST method

Requires the use of WSDL1.1 to describe the interface of a Web service

Requires the use of RPC-literal or document-literal forms of WSDL

Precludes the use of RPC-encodedstyle WSDL

Precludes the use of solicit-response and notification style operations

Requires the use of WSDL SOAP binding extension with HTTP as the required transport

Requires the use of WSDL1.1 descriptions for UDDI tModel elements representing a Web service

Overall, Web services are still in their youth, but the technology is being employed today

and is continuously undergoing fine-tuning. The optimism is so high that research firms

have laid out a potential schedule for its progress.


13/156

4

1.4 Phases of Adoption

Surveys from leading market research firms (Gartner Group, Forrester, IDC, and others)

find the adoption of Web services involves three distinct phases of progression. The

initial phase entails organizations beginning to adopt Web Services behind the firewall.

They experiment with pilot projects to gain hands-on experience and implement low-risk

incremental strategies when migrating over to a Web service solution. As firms establish

a comfort zone, they progress to the next phase of Web service adoption where they start

integrating applications and business processes beyond the firewall. Enterprises begin to

build sophisticated, collaborative systems with trading partners. The final phase deals

with the presence of numerous publicly available Web Services. Firms initiate the

development of complex applications by pulling together and incorporating existing

public Web Services. Each phase presents numerous challenges for enterprises and

developers. These include security issues, interfacing with legacy systems, and service

level agreements.

1.5 CWS Solution

I present CWS, a book broker composite Web service that fulfills three objectives. First,

CWS provides a superior tool for consumers, allowing them to search for book

information from numerous web sites from one centralized web site. Currently,

numerous book brokers (i.e. Chambal.com, FetchBook, BookFinder4U) exist, but fail to

offer the same robust, book search functionality that CWS offers and are not making the

leap forward toward applying Web services technology.


14/156

5

Secondly, CWS enables developers to integrate CWS J2EE-based Web service into their

own applications regardless of the platform, programming language or component model

being used on their end. A .NET client application has no difficulty exposing CWS

methods.

Lastly, CWS presents a good case study of how to bring out the best in Web Services by

emphasizing the power of process composition, the ability to alter the building blocks of

the Web service stack and providing dual B2B and B2C supports.

1.6 Overview

Chapter 2 begins with a brief summary of B2B distributed technologies and details the

component layers of the Web service standard. Recent Web service trends and the

current book broker environment are also discussed. Chapter 3 outlines CWS

requirements, functional specifications through specific use cases and CWS architecture.

Chapter 4 addresses the implementation of CWS Web interface and composite Web

service. Chapter 5 covers test cases which verify how successful CWS is in satisfying the

use cases specified in Chapter 3, and how CWS functionality matches up to third party

Web services and the major book brokers. Lastly, Chapter 6 details the future of Web

Services and the problems which still need to be addressed.


15/156

6

CHAPTER 2 B2B INTEGRATION TECHNOLOGIES

2.1 Distributed Computing Technologies

Distributed computing, in its simplest form, deals with providing a tool for a client

program, running on a local host, to call or invoke a server method, running on a remote

host, and to retrieve the result of the remote execution. A client can utilize different

communication styles when contacting a remote server. A client can simply call a remote

method or procedure (Remote Procedure Call or RPC), invoke a method on a remote

object (Remote Method Invocation or RMI) or even put messages or receive messages

from a remote queue (Message queuing). Many distributed technologies have been

developed over the years utilizing various styles, but three key distributed technologies

stand out from the rest: Java RMI, CORBA, and DCOM. Each distributed computing

paradigm is unique in its own right, but they all share one critical trait: they have all

contributed to the evolution of Web Services.

2.1.1 Java RMI

Java RMI or Java Remote Method Invocation entails having an object call a method of a

remote object. The remote object is located on a different Java Virtual Machine (JVM)

and possibly, on another machine. In order for the two objects to communicate, a "stub"

or "proxy", located on the caller's JVM, and a "skeleton" or tie, located on the remote

object's JVM, are needed. The stub and skeleton represent Java public interfaces.

The process involves a caller gaining direct access to the stub, the stub transforms the

programming language input parameters into a byte stream (a process known as

marshaling or serialization), the stub relays the caller's method call to the skeleton


16/156

7

using a given protocol and transport mechanism, the skeleton converts the incoming byte

stream back into its respective programming language (a process known as

unmarshaling or deserialization), the skeleton executes the method on the remote

object based on the received parameters, and the response comes back through the

reverse path. Java RMI utilizes a wire protocol known as Java Remote Method Protocol

(JRMP).

2.1.2 CORBA

CORBA or Common Object Request Broker Architecture (CORBA) is a binary

specification created by a group of vendors called the Object Management Group.

CORBA utilizes an Interface Definition Language (IDL), which allows for client/server

object interaction within a specific Object Request Broker (ORB). The ORB is the

intermediary that creates the connection between distributed objects. A CORBA object is

represented by an interface with a set of methods. The client of a CORBA object

acquires its object reference and uses it as a handle to make method calls. The ORB is

responsible for all the mechanisms required to find the object's implementation, prepare it

to receive the request, communicate the request to it, and carry the reply back to the

client. The wire protocol that is used by CORBA is known as Internet Inter-ORB

Protocol (IIOP). CORBA employs an object-oriented RPC communication style.

2.1.3 DCOM

DCOM is the distributed form of Component Object Model (COM), which builds an

object remote procedure call layer on top of DCE RPC. A COM client interacts with a


17/156

8

COM object by acquiring a reference to one of the object's interfaces and invoking

methods through that reference. DCOM employs an object-oriented RPC communication

style where the client interface is called the proxy and the server interface is called the

stub. The specification of DCOM is at the binary level and permits integration of

components written in various programming languages.

2.1.4 Web Service Evolution

Java RMI, CORBA, and DCOM are still utilized today, but their specification

deficiencies with respect to complete platform and programming language independence,

and interoperability are creating a need for a more suitable solution: Web Services. Web

Services are evolving by inheriting the beneficial traits of its predecessors which include

the utilization of an IDL in the form of a WSDL (Web Service Description Language)

and the use of object-oriented RPC style communication via stubs and skeletons. At

the same time, the specification of Web Services is avoiding the negative aspects

associated with its predecessors, which include tight coupling specifications, potential for

firewall blocking, long development times, and higher costs.

Distributed computing technologies of the past operate under a tightly coupled

specification, meaning a client can only interact with a server when both sides have the

appropriate libraries installed on their machines. CORBA requires each endpoint, the

client at one end and the server at the other, to have a compatible Object Request Broker

(ORB). The same holds true for Microsoft DCOM and Java RMI where endpoint


18/156

9

implementations must match. Granted a tight coupling specification has its place when

needed, but a more diplomatic and flexible format is the answer. Fortunately,

Web services specifications enforce loose coupling, meaning a client and a server can

interact independently irrespective of each endpoints platform and programming

language. This promotes flexibility, interoperability and improved integration. A .Net

client can interact with a J2EE server without having to worry about installing required

components and libraries. Various departments within an enterprise, running on different

platforms, can exchange data freely.

Additionally, distributed technologies in use today, namely CORBA and DCOM, are

geared more for internal enterprise use and utilize non-standard ports to communicate.

Thus, a client from outside the enterprise utilizing a standard port, who has appropriately

installed the required libraries, attempting to interact with a firms server is going to be

unsuccessful. Aside from the security benefits for the enterprise, such traffic is blocked

by the institutions firewall by default due to port differentials. This limits the use of

such distributed technologies beyond enterprises. A firewall has to be configured every

time an open port has to enter the mix. This is time consuming, inefficient and costly.

Undoubtedly, the presence of a universal standard protocol with security measures in

place expands the use of distributed technologies beyond the enterprise arena. Web

services operate generally via one standard protocol, Hyper Text Transmission Protocol

(HTTP), over open port 80. This eliminates the problem of firewalls blocking traffic due

to port differentials and the need to perform additional gateway configurations. It


19/156

10

furthers relationships beyond the enterprise and expands the use of distributed

technologies.

Finally, the development process for distributed technologies of the past tends to take an

enormous amount of time to complete. The existence and installation of numerous

components, and the possibility of performing additional plumbing (i.e. additional

gateway configurations) lead to such an unpromising result. Furthermore, the increased

cost associated with the additional development time is a major drawback, especially for

IT managers. A more cost effective and reduced development time solution is desired.

Web services are simple to implement and deploy. The components associated with

Web services generally revolve around three technologies: HTTP, SOAP and XML.

Web services operate under a text based protocol, unlike the binary protocols employed

by past distributed technologies. This expedites the development process, reduces costs

and improves overall productivity.

Admittedly, Web services possess their share of disadvantages. One of the key issues

facing Web services today is misuse. Web services have generated a tremendous amount

of hype. It is very common to get caught up in the latest industry trend or buzzword.

Freeman and Jones point out that when a new and exciting technology arises, it is

frequently over-prescribed and shoehorned into inappropriate situations, often because

people misunderstand the benefits and limitations of the technology, but also because

programmers simply want to experiment with the new technology. [1] Additional

disadvantages include security loopholes, network failures, service level agreements and


20/156

11

quality of service non-compliance, latency and poor return on investment(ROI). Despite

the few negative aspects surrounding Web Services, the technology is being utilized

today and is continuously being improved upon.

2.2 Web Service Architecture

Currently, the Web Service architecture consists of many layers. The following stack

demonstrates the building blocks of a Web Service and the corresponding technologies:

Figure 1: Web Service stack. Source: www.embedded.com

2.2.1 Protocol Layer-HTTP

The initial layer is the Protocol layer. This layer specifies which mechanism is used to

communicate or invoke a Web Service over a network. FTP or File Transfer Protocol is

used for transmitting files across networks and SMTP or Simple Mail Transfer Protocol

is used for sending e-mail. The most common protocol used over the Internet today is


21/156

12

HTTP 1.1 or Hyper Text Transport Protocol. HTTP is a request/response, text-based

style protocol where a client opens a connection to a server, sends a request, the server

processes its specific utility based on the client request and sends a response back to the

client.

2.2.2 Packaging Layer-SOAP

The packaging layer houses a mechanism or protocol that packages and binds messages

sent over a network. SOAP or Simple Object Access Protocol occupies this layer. SOAP

is a lightweight protocol that specifies the format of messages used in Web services and

enables cross-platform integration independent of the programming language or

distributed object infrastructure being used. For a detailed description of SOAP, visit

http://www.w3.org/TR/SOAP/. From a Web Services standpoint, there are a total of two

SOAP messages crossing the wire: a client request and a server response. SOAP

messages are formatted in XML or Extensible Markup Language and consist of four

parts: an optional XML declaration, a SOAP Envelope, an optional SOAP Header, and a

SOAP Body. The following example demonstrates a SOAP request/response dialogue

where a client is invoking a server method named multiply with two parameters:

Request

23


22/156

13

Response

6

Both SOAP messages contain the XML declaration

which specifies the XML version and the character encoding of the XML message. The

SOAP Envelope consists of the XML root element, SOAP-ENV:Envelope, which specifies

the namespaces used in the SOAP message. The optional SOAP Header tag is contained

within the SOAP Envelope, but is not represented in the example above for simplicity.

The SOAP Header is commonly used to transmit authentication and session management

data. The SOAP Body, located within the SOAP Envelope, contains what is commonly

called the payload. In the client request, the SOAP Body contains the name of the

method the client wishes to call, multiply, along with the method's input parameters, 2 and

3 in this case. The server response SOAP Body contains the method name concatenated

with Response and the results of the method invocation, 6. Note that even if there is no

return value, a message is still sent back to verify that the method executed.


23/156

14

2.2.3 Information Layer-XML

XML occupies the Information layer of the Web Services stack. XML or Extensible

Markup Language is a text-based meta-language that not only describes how data is

structured, but also describes the context of the data, gaining a better understanding of its

significance. Visit http://www.techcourt.com/technologies/xml/whyimp.htm for a

detailed introduction to XML. XML plays a key role as the main data interchange format

for Web Services.

2.2.4 Service Layer- Web Service & WSDL

The Service layer specifies the mechanism, WSDL in this case, for describing the Web

Service and the actual Web Service itself. WSDL or Web Service Description Language

is an XML vocabulary for describing web services. A client needs to know various

pieces of information in order to interact with the Web Service. These include: where the

service can be reached, how the service can be reached, what methods and parameters are

required, and what data types are used by messages sent or received by the web service.

The WSDL document provides all this information in a very unambiguous way. A

WSDL document consists of six major elements and two utility elements:

The definitions element is the root element and specifies the name of the web service and thenamespaces used throughout the document.

The message element specifies the message name along with zero or more part elements. The partelements define the parameters that are required. Zero parts means zero parameters. The messageelement only specifies the name, value(s) and the type of each value. It is the job of the portTypeelement to specify whether the message is for input or output.

The portType element defines a group of one or more operations, each of which has an operationelement. Each operation element has a name value and defines which message is the input andwhich is the output. If an operation represents a request/response dialogue, then the operationwould include two messages. If an operation represents only a request with no response or aresponse with no request, it would include only a single message.


24/156

15

The types element declares all the types that are used between the client and the web service forall the services declared in the WSDL document. Types can be simple or complex.

The binding element defines a specific portType implemented using a specific protocol such asSOAP. If a service supports more than one protocol (SOAP, CORBA, etc.), the WSDL documentincludes a listing for each.

The service element specifies the actual location or endpoint of the web service in the form of a

URL. The documentation element is a utility element which permits comments to be placed throughout

the WSDL document The import element is utilized to import other WSDL documents or XML Schemas

The following example displays a HelloService WSDL document [6]:


25/156

16

WSDL File for HelloService

A client in possession of the HelloService WSDL document has all the required data

needed to invoke the service. By checking the service element, the client discovers the

actual service is located at http://localhost:8080/soap/servlet/rpcrouter. The binding element

reveals the web service can be invoked with an RPC communication style via HTTP and

SOAP. Lastly, the client learns from the portType element that the actual name of the

method to be called is sayHello and the method requires one parameter in the form of a

String type, specified by the part element within the message element.

Not only does a WSDL document describe fully the details of a Web Service, but also a

key selling point for its continued use is that its structure makes it possible to generate

code from WSDL descriptions and WSDL descriptions from code. This expedites client

code development and reinforces the use of XML as a universal format for data

interchange.

2.2.5 Discovery Layer-UDDI

The Discovery layer completes the Web Service stack and is occupied by a mechanism,

which publishes information about various Web Services. UDDI or Universal

Description, Discovery, and Integration resides here. For a detailed description of UDDI,

visit http://www.uddi.org . UDDI provides a repository where any entity, at design or run


26/156

17

time, can search to find specific Web Services. As the number of Web Service systems

grows, the need for an organized directory is a necessity. The repository contains

information about businesses, the services they provide(Web Services and Non-Web

Services), version changes, and how to access services. A UDDI can be structured for

public use where any person or business can publish their services to the world and

establish partnerships or for private use, where an individual company can create their

own isolated UDDI registry to list the services available within their private network.

An entity that wishes to register their Web Service must do so using XML-based

documents and provide four key data elements, which are used in the discovery process:

The businessEntity element specifies the web service owner and includes business name,description, address, and contact information. Every business receives its own UUID (UniversallyUnique Identifier) called a businessKey.

The businessService element describes one specific service. A business can have multiple webservices. Each service is given a unique serviceKey.

The bindingTemplate element specifies the technical aspects of a single service such as theendpoint URL and interface information. Each template is uniquely identified by a bindingKey.

The tModel element orserviceType provides a URL location to a document that provides moreinformation (metadata) about the service. This document can be a WSDL document(preferred) ,

HTML page, etc. Each tModel is uniquely identified by a tModelKey

2.2.6 Alternative Layers-REST and HTML Scraping

Alternative mechanisms can be added to the Web Service stack and consequently,

removing a few existing mechanisms in the process. Two tools that are in widespread

use today are REST and HTML Scraping. Both tools simplify the Web Service Stack

and serve as formidable supplements to the Web Service architecture. REST or

Representational State Transfer is an architecture style created by Roy Fielding in his

dissertation [5], which attempts to capture the characteristics of the Web. In short, a

client using HTTP specifies or binds the method name and parameters directly into the


27/156

18

URL and the server responds by returning an XML-formatted response. A hypothetical

REST example using a similar method call from the SOAP request/response example

above is:

http://www.mywebservice.com/xml?method=multiply&param1=2&param2=3

The server makes available a URL to a resource to multiply numbers and return the

results in an XML-formatted response. The REST style, commonly termed XML over

HTTP, eliminates the SOAP layer in the Web Services stack and is especially useful for

simple applications. (see Chapter 4 Amazon implementation).

HTML scraping is the process of programmatically making a connection to a specific

URL, gathering the HTML source code from the URL, and then pulling the necessary

data from the code through pattern matching. The process does not involve calling a

method and receiving a response, but more of locating a resource through a URL and

fetching the data oneself. HTML scraping involves a tremendous amount of

housekeeping on the part of a client since any change to the HTML source code from the

URL forces a client to alter their pattern matching code. On the flip side, HTML

scraping is dynamic, can gather up to the minute data and is considered a legitimate last

resort when no other mechanisms are available.

2.2.7 Web Service Stack Analysis

Overall, the Web Services stack presents a framework for seamless interoperability.

HTTP is a common transport protocol that everyone can utilize. SOAP can bridge the

gap between parties of different languages and platforms. XML is a data exchange


28/156

19

mechanism that every a programming language can employ by its text based nature.

WSDL documents provide a universal guidebook and key starting point. Lastly, the

UDDI provides the window to web services, providing a yellow pages for existing

services and for those yet to arrive.

2.3 Web Service Industry Trends

Theoretically, the Web Service distributed architecture appears to have the ingredients for

success and current industry trends support this. Perhaps the most compelling trend deals

with the number of companies that have already deployed Web services. Line56.com

points out that in a Yankee Group survey of 437 enterprises, 48 percent have already

deployed Web services, and another 39 percent plan to do so in 2005 [2]. Additionally,

corporations are solidifying their positions in the Web Services market through

acquisitions. Computer Associates has recently acquired Adjoin. Hewlett-Packard is in

talks to acquire Talking Blocks. This can be a huge driving force and can generate a

tremendous amount of momentum toward increased Web service implementation.

Software vendors are making a key contribution to the success of Web Services by

creating formidable Web service enabling products for various platforms and

programming languages. Not only do they provide the tools for implementing the

distributed component, but are simplifying the process. One Java toolkit that is in use

today is Apache Axis. Axis through its API simplifies the Web Service building process

by performing many low level tasks (i.e. dynamic WSDL creation and stub/skeleton

code generation), enabling a developer to focus more on higher level problem solving

and faster deployment of the finished product. JavaSkyline [3] outlines a few Java


29/156

20

related products and a few Java-competitive products in Appendix 1. Lastly, a unified

effort exists among big corporations like IBM, Microsoft, and Hewlett-Packard to

standardize the distributed technology. In the past, these firms were competing amongst

themselves to get the upper hand and gain market share. Today, firms are working

together to come up with a standard and are realizing the financial benefits of forming

business partners as opposed to business opponents.

The combination of all these factors demonstrate that the Web Services architecture is

gaining the support and confidence of many corporations and this foundation can lead to

not only a promising future, but a productive one.

2.4 Current Book Broker Environment

The following table illustrates a list of current book brokers on the Web:

Chambal BestBookDeal PriceSCAN

Allbookstores AddAll like2read

Bookpool Bublos isbndb

Bookchecker MetaPrices PriceFarmer

Isbn.nu BestWebBuys EveryBookstore

Fetchbook.info BookFinder.us FindBookPrices

Bookfinder4u BookPriceCompare BookWormer

Bigwords FastBookFinder thecheapestbook

Table 1: Current Web Book Brokers


30/156

21

CHAPTER 3 CWS ANALYSIS & ARCHITECTURE

3.1 CWS Requirements

CWS is a Web-based book broker application designed to provide book pricing and book

search functionality for a client via a browser and for a client via an application. CWS

allows a client to input specific, book search criteria. Search criteria includes author

name, book title, ISBN, publisher, year of publication, subject, and keyword. In addition,

a client can input a combination of search criteria and not be limited to just one form.

This promotes search refinement and faster response time. Upon receiving a search

request, CWS takes on the role of a book broker and a client itself, and begins to navigate

to various vendors searching for book data originally specified by the client. Once CWS

gathers all the book information from its business partners, CWS presents the results in

list form to the client. Results from a price search are presented with a complete book

detail summary (author, title, publisher, ISBN, manufacturers retail price) and a list of

the vendor, current price, and vendor link. Results from a book search are presented with

a total number of books found, a brief summary for each book and option to perform a

price search for a selected book. In the event of an error, an error message is displayed

and a client is asked to perform a new search. Overall, CWS responds to all requests

within 60 seconds.

For a client utilizing a Web browser over the Internet, CWS offers a Web interface,

allowing a user to provide the necessary search criteria for CWS to process and respond

back with data.


31/156

22

For a client accessing CWS via an application, CWS supplies a composite Web service.

A client application can initially find CWS through a UDDI registry. Upon successful

CWS discovery, a client application can invoke CWS Web service. CWS in turn

invokes Amazons Web service to gather all book data originally specified by the client

application. Upon completion, CWS Web service returns book results in XML format.

In the event of an error, an error message is returned in XML format. Only client

applications that can parse XML documents can utilize CWS Web service.

3.2 CWS Functional Specifications

In order to demonstrate CWS functionality, use cases are presented. Use cases are

written reports describing a system and its functionality from an external usage

perspective. Use cases provide a discrete collection of task-related activities. In this

case, the external point of view comes from a person shopping for book prices via their

browser, accessing CWS through CWS web user interface (CWSUI) or from an

application searching for book data, accessing CWS through CWS composite Web

service (CWSWS).

Use Case 1: Search ISBNPrimary Actor: StudentSupporting Actor: Multiple vendorsPre-Condition: User has correct ISBN number

Actor: Student System: CWSUI

1. Arrives at CWS home page

2. Present company logo and links3. Present list of search parameters

4. Enter ISBN number for specific book5. Submit request

6. Verify parameter(s) have been sent7. Edit ISBN by removing dashes, spaces8. Retrieve prices from multiple vendors9. Display book details, vendor name,


32/156

23

price and link

10. Select preferred, vendor link

Exception- Step 6: Search parameter(s) are invalid. Report error to user

Use Case 2: Search AUTHOR and YEAR PUBLISHEDPrimary Actor: StudentSupporting Actor: Amazon Web servicePre-Condition: User has correct author name and year of publication

Actor: Student System: CWSUI

1. Arrives at CWS home page

2. Present company logo and links3. Present list of search parameters

4. Enter author name5. Enter year published6. Submit request

7. Verify parameter(s) have been sent8. Retrieve books from Amazon9. Display books (title, author, publisher,

year, ISBN, link to Use case 1)

10. Select book11. Submit request

12. Go to Use case 1

Exception- Step 7: Search parameter(s) are invalid. Report error to user

Use Case 3: Invoke searchISBN() method

Primary Actor: Java Client ApplicationSupporting Actor: Multiple vendorsPre-Condition: User has correct ISBN number

Actor: Java Client Application System: CWSWS

1. Invokes searchIsbn() method

2. Edit ISBN by removing dashes, spaces3. Retrieve prices from multiple vendors4. Build results in XML format5. Return book results

6. Parse results

Use Case 4: Invoke searchAll() methodPrimary Actor: .NET Client ApplicationSupporting Actor: Multiple vendorsPre-Condition: User has correct author name and year of publication

Actor: .NET Client Application System: CWSWS

1. Invokes searchAll() method withauthor name and year of publication


33/156

24

parameters

2. Verify parameter(s) have been sent3. Retrieve books from Amazon4. Build results in XML format5. Return book results.

6. Parse resultsException- Step 2: Search parameter(s) are invalid. Return error to user in XML

3.3 CWS Design

3.3.1 Architecture

In order to fulfill system requirements and functional specifications, CWS architecture

applies two design patterns. The first is the Service Oriented Architecture (SOA) model

(see Figure 2), which consists of a service provider, service broker and service requester.

Figure 2: SOA Model. Source: www.ibm.com IBM Systems Journal Vol. 41, No 2, 2002

CWSWS fills the role of the service provider, providing a service interface to a specific

resource and publishing its service with the UDDI registry. The UDDI registry takes on

the role of the service broker, providing a locale for service requesters to find Web

services. The role of the service requester is filled by a client, usually a person or

computer, who searches registries for Web Services and then binds itself to the provider.


34/156

25

The second design framework that CWS applies is Model 2 architecture. Since the

introduction of Java Server Page (JSP) technology, Model 1 and Model 2 architectures

have emerged for building server-side applications. Model 1 (see Figure 3) employs the

use of JSP and JavaBeans to separate business logic from presentation. Model 2 (see

Figure 4) takes it a step further by incorporating Servlets and presenting a format that

follows the Model-View-Controller (MVC) model. The Model consists of data and

business logic, the View is responsible for presenting data and the Controller takes in

client requests, dictates application behavior and dispatches responses to the View.

Figure 3: Model 1 JSP Architecture [4]

Figure 4: Model 2 JSP Architecture [4]


35/156

26

In the Model 2 framework, the Servlet acts as the controller, taking in requests,

forwarding responses to the appropriate JSP (the view), and instantiating any required

JavaBeans (the model) needed by the JSP environment.

Overall, the utilization of specific design patterns provide numerous benefits to

developers. These benefits include capturing the experience of developers from the past

who have already tested such patterns, providing a common vocabulary for team

members to reduce miscommunication, defining roles to reduce cross participation, and

expediting the development process as a whole.

3.3.2 Methods Used

The Controller is structured as a Java Servlet and consists of a doPost() and a

doGet() method to handle client requests. doPost() performs server-side form

validation and invokes a normalize() method to housekeep and trim client parameters.

There is a method for each of the 11 vendors. A searchIsbn() method addresses client

requests that specify an ISBN parameter and invokes each of the 11 vendor methods. All

other types of client requests are handled by an amazon() method. A scrape() method

performs HTML scraping and is invoked by each vendor who does not provide Web

services functionality (At the time of this writing, Amazon is the only CWS vendor

offering Web service capabilities). A getCharacterDataFromElement() method assists

the amazon() method with spacing when there are multiple authors for a given book.


36/156

27

The methods of the BookBean class (Model) consist of all the accessor methods

pertaining to properties of a given book. These properties include vendor, retail price,

vendor link, title, publisher, year of publication and author. A compareTo() method is

invoked to assist in sorting book price results.

The following diagram presents CWS MVC architecture, classes, class inter-

relationships, underlying methods and fields:

Figure 5: CWS MVC Architecture


37/156

28

The following sequence diagram demonstrates the events that can potentially take place

during a CWS book search:

Figure 6: CWS Sequence Diagram


38/156

29

3.3.3 Data Structures

CWS does not utilize a database. The BookList, an instance of the Java Vector class,

serves as the key data structure for storing book results. The BookList is not to be

shared by all client requests. Each individual client request must result in the creation of

a new BookList.

3.3.4 CWS Web User Interface-CWSUI

CWS Web user interface operates as a form page and lists each search criteria: Author,

Title, Publisher, Publish Year, Subject, Keyword, and ISBN. To the right of each

criteria, a user can enter their corresponding search text. In order to initiate a search, a

user selects the CWS Search button. The Clear button erases all text entered by a

user. CWS logo, About Us link, Contact Us link, and Home page link are also

displayed.

3.3.5 CWS Composite Web Service-CWSWS

In order for CWS to meet the role of a Web service provider, CWS will register via a

Web browser with two UDDIs (IBM and Microsoft) to facilitate discovery. In addition,

CWS provides two methods for client consumption: searchIsbn() and searchAll().

The searchIsbn() method addresses client requests that have specified an ISBN

parameter. The searchAll() method handles all other types of client requests. Each

method returns book results in XML format. CWS utilizes the Apache Axis 1.1 toolkit as

its SOAP engine for deploying CWSWS dynamically and WSDL generation.


39/156

30

3.3.6 Hardware and Software Specifications

The following table summarizes CWS hardware and software specifications:

Operating System Red Hat Linux 7.2

CSIS Server MatrixFile Transfer Application/Protocol Secure Shell Telnet Client (SSH)

Java SDK version 1.5.0.01

Application Server Tomcat 4.1.18

Java Servlet specification 2.3

Java JSP specification 1.2

WSDL version 1.1

SOAP Engine Axis 1.1

Table 2: CWS Hardware and Software Specifications


40/156

31

CHAPTER 4 CWS IMPLEMENTATION

4.1 Overview

The following implementation of the CWS web interface and the CWS Web Service

demonstrate how effective Web service technology can lead us closer to seamless

interoperability. The chapter is divided into two sections. The first section details the

CWS web interface, which provides book search functionality to the public over the

Internet via a browser. The second section details the actual CWS web service. The

complete source code is located in the Appendix.

4.2 CWS Web Interface

4.2.1 View

The web interface follows Model 2 architecture and consists of a total of seven files:

index.jsp results.jsp search.jsp aboutus.jsp

error.jsp Controller.java BookBean.java

Index.jsp represents the home page for CWS, providing a means for a user to enter any

combination of specific book-search criteria based on author name, title, publisher,

publication year, subject, keyword and international standard book number (ISBN).

Once a user selects the search button, the request is passed via the HTTP post method to

the servlet, Controller. The following excerpt from index.jsp demonstrates how the

post method is initiated:

Author:


41/156

32

As an example, if a user performs an author search by entering James Gosling in the

text field, the name/value pair becomes author/James Gosling. If a user selects the search

button without making changes to the text fields, then the request is still sent with the

corresponding name and all values defaulting to . Index.jsp does not perform form

validation. All validation is performed on the server side.

Results.jsp displays the results of an ISBN search. The page displays the details of the

specific book (i.e. author, title, cover image icon, etc.), how many vendors have been

found, and a listing of the results with vendor, price and buy-link headings. Since results

are forwarded from the Controller servlet as a session attribute in the form of a Vector

ofBookBean objects, the BookBean class must be imported via a JSP page directive and

an instance of a BookBean must be created via the useBean JSP standard tag as follows:

This allows the id value, booklist, to be used like any Vector object. In order to access

each BookBean, the elementAt() method of the Vector class is utilized along with a

BookBean cast, since the method returns an Object type. The following scriptlet

demonstrates accessing an author of a specific book from the bookList:

Search.jsp displays the results of a non-ISBN search. The page displays how many

books have been found, the details of each book, a corresponding radio button, and a

Shop Prices button to search prices for a specified book. The page lists twenty books

per page. The Shop Prices button forwards a request to the Controller via the HTTP


42/156

33

get method. If a radio button is not selected by the user, the request is still forwarded, but

results in an error from server side validation.

Error.jsp displays any errors, which may have occurred servicing a request. The page

accesses a session attribute in the form of a String, displays that String, invalidates the

session and provides a link to begin a new search.

Aboutus.jsp displays corporate information about CWS.

4.2.2 Controller

The servlet, Controller, is the workhorse of the application performing numerous tasks,

which include processing all requests, forwarding requests, bean creation, and form

validation. The following excerpt from the doPost method shows how the users search

parameters are gathered and validated:

String []author = request.getParameterValues("author");

String []title = request.getParameterValues("title");

String []publisher = request.getParameterValues("publisher");

String []year = request.getParameterValues("year");

String []subject = request.getParameterValues("subject");

String []keyword = request.getParameterValues("keyword");

String []isbn = request.getParameterValues("isbn");

if ( (author[0].equals("") && title[0].equals("") && publisher[0].equals("") && year[0].equals("")

&& subject[0].equals("") && keyword[0].equals("") && isbn[0].equals("") ) ||

(author[0].equals(" ") || title[0].equals(" ") || publisher[0].equals(" ") || year[0].equals(" ") ||

subject[0].equals(" ") || keyword[0].equals(" ") && isbn[0].equals(" ")) ) {

String err = "Invalid search criteria entered.";


43/156

34

session.setAttribute("err", err);

ServletConfig cfg = this.getServletConfig();

ServletContext thisCxt = cfg.getServletContext();

RequestDispatcher rd = thisCxt.getRequestDispatcher( "/error.jsp" );

rd.forward( request, response );

Each parameter is gathered using the getParameterValues() method of the request

object, which returns an array ofStrings. Utilizing the James Gosling search example

earlier, the String is not tokenized, but placed entirely into the author array at index

zero. As for validation, if all parameters equal , then a user has not entered any search

criteria, resulting in the servlet setting up an error session attribute labeled err and

forwarding the request to the error.jsp page. Form validation also addresses the

possibility of a user entering a white space for all parameters. This results in an error as

well.

In the event of a user submitting a request with a valid parameter or a combination of

valid parameters, the Controller creates a bookList, an instance of the Vector class, to

serve as the data structure to gather all the books that surface from a search. In order to

ensure thread safety, the bookList is declared as a local variable inside the doPost

method. This guarantees that a bookList is created for each request that the servlet

receives. IfbookList is declared as a global variable, then all requests would share the

same bookList.

The Controller verifies if an ISBN number has been requested. If so, the

searchIsbn() method is invoked. Otherwise, control passes to the amazon() method.

Upon completion of the relevant method call, the Controller sorts the bookList by


44/156

35

price, establishes a bookList session attribute named bookList, and forwards the

request to either the results.jsp page for an ISBN search or to the search.jsp page

for a non-ISBN search.

4.2.2.1 The searchIsbn() Method

The searchIsbn() method accepts two parameters: the ISBN request from the user and

the bookList. Initially, the ISBN is edited in the event that a user has entered an ISBN

number with hyphens or spaces. The StringTokenizer class is utilized to break up the

ISBN into tokens or pieces, eliminate hyphens and spaces, then concatenate to ensure a

pure number sequence. From here, each vendor method is invoked accepting the newly

edited ISBN and the bookList as parameters.

4.2.2.2 Vendor methods

With the exception of the amazon() method, all vendor websites utilized by CWS are

deficient in implementing Web service functionality. As a result, each CWS vendor

method resorts to HTML scraping to gather book data. Each vendor possesses a specific

Uniform Resource Locator (URL) for accessing his or her book data. Each vendor

method invokes the scrape() method with their corresponding URL concatenated with

the users ISBN request. A connection to the URL is made using the java classes,

java.net.URL and java.net.URLConnection. The process involves creating a URL

object, u, then calling the openConnection() method ofu to create a URLConnection

object, urlconnx. Then the setup parameter, setDoInput, is assigned to true since the

URL connection is being used for input. Lastly, the connection is made using a socket


45/156

36

for a network connection or a file input stream for a local connection. The response

header information is read from the server. Data is read from the connection by using the

input stream returned by getInputStream(). The scrape() method returns a String of

the entire web page. In the event a connection can not be made and an exception occurs,

the exception is caught and the scrape() method returns null. This enables processing

to continue when certain vendors are unavailable.

Each vendor method utilizes the String from the scrape() method, captures the specific

price that is offered from the vendor based on a stable identifier, creates a book object of

the BookBean class, sets the price, vendor and URL link of the book via the accessor

methods of the BookBean class, and finally adds the book to the bookList.

The difficulty with the HTML scraping process is that all the URLs and stable identifiers

must be collected and researched by a server-side programmer prior to implementation.

Additionally, if a vendor alters their respective site or URL, then existing code must be

altered to reflect such changes. HTML scraping requires a tremendous amount of upkeep

and is prone to generating numerous runtime errors. However, it does serve as a last

resort when no other alternative, data-gathering methods exist. One common strategy

that is used to reduce the amount of upkeep is to centralize all URL and stable identifier

information from each vendor into one key file on the server. This way when changes

occur, a programmer only has to modify the key file.


46/156

37

4.2.2.3 The amazon() Method

The amazon()method demonstrates the power of Web service technology by utilizing

Amazon.coms Amazon Web Services (AWS 3.0). AWS, recently changed to Amazon

E-Commerce Service (ECS 4.0), allows access to numerous Amazon.coms web sites in

the form of a Web Service (Registration and programming information is available at

http://www.amazon.com/gp/aws/registration/registration-form.html ). AWS can be

accessed through either SOAP or REST requests. CWS utilizes the REST or XML over

HTTP approach via Amazon.coms PowerSearch function. AWS is utilized for ISBN

searches and is the only vendor CWS utilizes for non-ISBN searches due to its

consistency. Basically, a connection is made to a specific URL, which includes a users

request data, and AWS returns book results in the form of an XML document (AWS

returns ten items per page, so subsequent connections are required for multiple pages).

The CWS amazon() method retrieves the XML document as a String, parses the

document utilizing the Document Object Model (DOM) from the Java APIs for XML

Processing (JAXP), creates a book of the BookBean class for Amazon books as well as

for used books being sold by the public through Amazon.com, sets numerous properties

of the book via accessor methods, and finally adds the book to the bookList.

Regarding XML processing, DOM is utilized instead of SAX or JDOM for two reasons.

First, DOMs biggest drawback is its efficiency problems which can impact performance,

but performance is not a critical ingredient to CWS functionality. Moreover, the AWS

XML document is not exceptionally large and combined with the fact that CWS sets a

500 book-result threshold, loading the entire document into memory is not very resource


47/156

38

intensive. Secondly, the DOM API offers feature-rich methods, specifically the

getElementsByTagName() method, which provides random access to any tag name.

4.2.3 Model

The BookBean class is a JavaBean component that represents a single book. Each book

possesses numerous properties, which include title, author, vendor, ISBN and price.

Properties can be accessed or modified through a properties corresponding accessor

method. The BookBean class implements the Comparable interface to provide a price

sorting mechanism for the bookList. Sorting is initiated by the Controller using the

sort() method of the Collections class. The Comparable interface assists the sort()

method by clarifying which particularbook property is used in the comparison. A

ClassCastException is thrown otherwise. The Comparable interface contains one

method, compareTo(), which takes an Object as a parameter and returns an integer. The

compareTo() method returns zero if the object passed is equal to the current instance. It

returns a positive integer or a negative integer if the current object is greater or smaller

than the passed object. The bookList is sorted by price in ascending order.

4.3 CWS Web Service

4.3.1 CWS Service

The CWS Web Service (CWSWS) consists of the following source files:

BookServerImpl.java IBookSearch.java BookServerImpl.jws

IBookSearch is an interface that defines the two methods that are to be exposed as Web

Services: searchIsbn() and searchAll(). BookServerImpl implements the


48/156

39

IBookSearch interface and is derived from the Controller class of the CWS web

interface. The key difference is that CWSWS does not use the BookBean class, but

resorts to a more simplified type, the String class. Instead of constructing a bookList,

CWSWS sequentially builds an XML document consisting of the book results from each

vendor. An instance of the StringBuffer class is utilized to contain the book results.

The append() method of the StringBuffer class is called to add book information to

the buffer as they come about in the form of a String. A relevant property of a book

(vendor, title, author, ISBN, etc) is added to the buffer in XML format. The following

code excerpt demonstrates how book information is added to a buffer:

sb.append("");

sb.append("half.com");

sb.append("");

sb.append("");

sb.append(priceHalf);

sb.append("");

sb.append("");

sb.append(halfUrl);

sb.append("");

In the event of a successful book search, the assembled XML document within the buffer

is edited. Certain characters in XML have special meaning to XML parsers and can be

represented incorrectly in an XML document. Such characters include < , >, and &.

Built-in entities must be employed to ensure correct representation. The ampersand is a

commonly used URL character and therefore, CWS replaces all instances of & with

& to ensure accurate representation. The following code demonstrates the

replacement process within the sb buffer:


49/156

40

int ind=sb.indexOf("&");

while(ind != -1){

sb.replace(ind,ind+1,"&");

ind=sb.indexOf("&",ind+1);

}

Finally, the toString() method of the StringBuffer class is invoked to change the

entire buffer to a String and this String is returned to a client. If an unsuccessful book

search occurs, CWS returns the following String:

"No books found"

In the event of an error, CWS returns:

"Invalid search criteria"

4.3.1.1 Deployment

Utilizing the Apache Axis 1.1 framework, there are two ways to deploy a web service:

JWS instant deployment and WSDD custom deployment. CWS utilizes the JWS (Java

Web Service) method of deployment which simply involves changing the extension of a

java source file, BookServerImpl.java in this case, from .java to .jws and placing it into

the Axis webapps folder. CWSWS can then be accessed via the following URL:

http://matrix.csis.pace.edu:23451/axis/BookServerImpl.jws

Moreover, the WSDL for CWSWS is accessed by adding ?wsdl to the above URL:

http://matrix.csis.pace.edu:23451/axis/BookServerImpl.jws?wsdl

Axis automatically compiles the class and dynamically generates the WSDL document.

The WSDD (Web Service Deployment Descriptor) method involves static deployment of

a service. The steps are:


50/156

41

1) creation of java source file and java interface

2) creation of WSDD file, deploy.wsdd, specifying methods to be exposed and type mappings

3) construct the WSDL file using Axis Java2WSDL tool

4) generate server-side wrapper code and stubs using Axis WSDL2Java tool

5) modify the xxxxSoapBindingImpl file with correct return statements and objects

6) compile all class files (creation of jar file is optional)

7) copy class files to the Axis/WEB-INF/lib folder

8) start the server and deploy service using Axis AdminClient tool with deploy.wsdd

The WSDD-deployed service can then be accessed via the following hypothetical URL:

http://matrix.csis.pace.edu:23451/axis/services/XXXX

The WSDD-deployed service can be undeployed using the AdminClient tool with a auto-

generated undeploy.wsdd file.

CWS utilizes JWS instead of the WSDD because of its simplicity, dynamic capabilities

and loosely coupled structure. The WSDD method promotes a tightly coupled structure

due to the presence of stubs and skeletons. Each time the underlying implementation

changes, new glue code must be generated as well. David Bau states since automatic

WSDL and stub-generation tools work by directly generating a message shape from a

function signature (or vice versa), when you change your implementation code, it

changes your public contract at the same time. [7].

4.3.2 CWS Client

A client has two options when invoking a JWS service. The first option is dynamic

invocation in which a client uses Axis implementation of JAX-RPC. The services

WSDL is not directly used, but can be referenced for endpoint, namespace, and operation


51/156

42

details. The second option is standard stub generation. In an effort to demonstrate

CWSWS interoperability, a Java client and a .NET client (C# implementation) are

presented. Both clients implement a graphical user interface (GUI) to facilitate use.

4.3.2.1 Java Client

The java client, CWSBookSearchClient, invokes CWSWS using dynamic invocation:

public void searchIsbn(String isbn) {

String ret = null;

try {

Service service = new Service();

Call call = (Call) service.createCall();

call.setTargetEndpointAddress(new java.net.URL(endPoint));

call.setOperationName( new QName("BookServer", "searchIsbn") );

call.addParameter("isbn", XMLType.XSD_STRING,ParameterMode.IN);

call.setReturnType(XMLType.XSD_STRING);

ret = (String)call.invoke(new Object[] {isbn});

results.setText(ret);

results.setCaretPosition(0);

}

catch (Exception e) {

results.setText("Unable to process searchIsbn request at this time. Please try again.");

}

} // end searchIsbn method

After gathering and setting the endpoint, operation, parameter type, and return type

information from the CWSWS WSDL, the service is invoked using the invoke() method

of the Call class, which takes an array ofObjects as a parameter. The CWSWS XML

document is returned with a mandatory String cast.


52/156

43

4.3.2.2 .NET Client

The .NET client, cwsForm.cs, invokes CWSWS using stub (proxy) generation:

private void button1_Click(object sender, System.EventArgs e) {try{

display.Clear();string result = null;

BookServerImplService svc = new BookServerImplService();if(!isbnx.Text.Equals("")) {

result = svc.searchIsbn(isbnx.Text);display.AppendText(result);

The .NET framework provides a tool, wsdl.exe, for generating proxy classes for XML

Web Services clients from WSDL contract files. The following command generates a

proxy class, BookServerImplService.cs, from the CWS WSDL:

wsdl /out:BookServerImplService.cs http://matrix.csis.pace.edu:23451/axis/BookServerImpl.jws?wsdl

The client then creates an instance of the proxy class and simply calls the desired service

method. The .NET client has no difficulty processing the String returned from the J2EE

based CWSWS.

4.3.3 CWS Discovery

Numerous firms or operators provide public, UDDI registries and testing registries. A

few of the most common include:

Operator Inquiry URL Publish URL

HP http://uddi.hp.com/inquire https://uddi.hp.com/publish

IBM http://www-.ibm.com/services/uddi/inquiryapi https://www-3.ibm.com/services/uddi/protect/publishapi

IBM Test http://www-3.ibm.com/services/uddi/testregistry/inquiryapi

https://www-3.ibm.com/services/uddi/testregistry/protect/publishapi


53/156

44

Microsoft http://uddi.microsoft.com/inquire https://uddi.microsoft.com/publish

MicrosoftTest

http://test.uddi.microsoft.com/inquire https://test.uddi.microsoft.com/publish

SAP Test http://udditest.sap.com/UDDI/api/inquiry/ https://udditest.sap.com/UDDI/api/publish/

Systinet http://www.systinet.com/wasp/uddi/inquiry/ https://www.systinet.com/wasp/uddi/publishing/

Table 3: UDDI Registry Access Point URLs

UDDI registries can be accessed using an operators web interface via a browser or

programmatically. Java developers can utilize SOAP APIs, custom Java-based UDDI

client APIs (i.e. UDDI4J and WASP UDDI), and the Java API for XML Registries

(JAXR). CWS utilizes Microsofts and IBMs UDDI registry for publishing and IBMs

UDDI4J class library for queries.

4.3.3.1 Publishing CWS

CWS utilizes the web interfaces from Microsoft and IBM to register and publish CWS

functionality. The process entails providing a business name, description, contact

information, overview document (location of CWS WSDL file) and tModel data.

Further data can be entered such as business relationships and categories, which refine

the search process. The following is a screen capture of CWS data from the IBM

registry:


54/156

45

Figure 7: CWS Data From IBM UDDI Registry

4.3.3.2 Performing a CWS Query

A CWS query can be performed using IBMs UDDI4J project. UDDI4J is a Java class

library that provides an API that can be used to interact with a UDDI registry. The UDDI

client implementation is derived from IBMs sample files from the UDDI4J kit and

consists of three customized files:

FindCWS.java Configurator.java propCWS.properties

propCWS is a properties file which centralizes all the key information needed to interact

with a UDDI registry. This information includes usernames and passwords when

publishing, the URLs for the inquiry and publish APIs of the target registry, SOAP


55/156

46

transport classes, security settings, and logging options. When a developer needs to

access a different registry, one only has to alter the settings of the properties file. This is

convenient and adds an additional layer of security.

Configuratoris responsible for reading the properties file, setting the SOAP transport,

and configuring the SSL/JSSE provider.

FindCWS is the driver of the client application and performs a simple query based on

business name. FindCWS begins by enabling the Configurator to perform its duties via

the creation of a Configurator object, config, then calling the load() method of

config. Once the correct environment settings are configured, FindCWS creates a

UDDIProxy object, proxy. UDDIProxy is the central class in the UDDI4J class library

and represents a proxy for the UDDI server. Its methods map to the UDDI Version 2 API

Specification (For details visit http://uddi.org/pubs/ProgrammersAPI_v2.htm). FindCWS

then sets the URL for the inquiry API of the target registry, Microsoft UDDI registry in

this case, as follows:

proxy.setInquiryURL(config.getProperty("inquiryURL"));

Next, FindCWS specifies the specific business name to be queried:

Vector names = new Vector();

names.add(new Name("CWS"));

Lastly, FindCWS adds a specific case sensitive qualifier to the query and calls the

find_business() method of the UDDIProxy class to initiate the query to the Microsoft

registry. Surprisingly, the client application returns two business names for CWS. This


56/156

47

is due to the fact that CWS is published with Microsoft and IBM, and the registries not

only return data from their side, but from their companions as well.

Queries are not limited to just business names, but can include business descriptions,

tModels, categories and a host of other criteria.


57/156

48

CHAPTER 5 CWS TEST CASES

5.1 Use Case Verification

The following is a summary of the use cases from Chapter 3:

Use Case 1: Search ISBNPrimary Actor: StudentSystem: CWSUISupporting Actor: Multiple vendorsPre-Condition: User has correct ISBN number

Use Case 2: Search AUTHOR and YEAR PUBLISHEDPrimary Actor: Student

System: CWSUISupporting Actor: Amazon Web servicePre-Condition: User has correct author name and year of publication

Use Case 3: Invoke searchIsbn() methodPrimary Actor: Java Client ApplicationSystem: CWSWSSupporting Actor: Multiple vendorsPre-Condition: User has correct ISBN number

Use Case 4: Invoke searchAll() methodPrimary Actor: .NET Client Application

System: CWSWSSupporting Actor: Multiple vendorsPre-Condition: User has correct author name and year of publication

Each use case has been tested to verify if CWS can fulfill the specific requests for

resources. Each test case number corresponds to each use case number. Test cases 1 and

2 have been tested using Microsofts Internet Explorer and Mozillas Firefox browsers.

CWSUI is accessible at http://matrix.csis.pace.edu:23451/pace/index.jsp.


58/156

49

Test Case 1

A student is greeted with the CWS homepage which displays the user interface:


59/156

50

The student, shopping various prices for Steve GrahamsBuilding Web Services withJava, enters the books correct ISBN number 0672326418:


60/156

51

After the student clicks on CWS Search, CWS successfully returns a book summary,sorted prices, and links from numerous vendors:


61/156

52

Test Case 2

A student searching for books written by Walter Savitch with a publication year of 2004enters the data as follows:


62/156

53

After the student clicks on CWS Search, CWS successfully returns various books basedon the students search parameters:


63/156

54

Regarding Test cases 1 and 3, in the event of an error, CWS displays the following:


64/156

55

Test Case 3

Launching the Java client application, CWSBookSearchClient, from the command line orfrom an IDE results in the display of a user interface:


65/156

56

A user of the application, shopping various prices forMicrosoft .NET XML Web ServicesStep by Step written by Adam Freeman, enters the books correct ISBN number0735617201:


66/156

57

After the user clicks the Search button, CWS successfully returns the following XMLdocument:


67/156

58

The output displays a well formed XML document. The complete XML document is asfollows:

Microsoft .NET XML Web Services Step by StepAdam Freeman,Allen Jones,Adam FreemanMicrosoft Press073561720139.99

Amazon26.39http://www.amazon.com/exec/obidos/ASIN/0735617201 Amazon-Used16.50http://www.amazon.com/exec/obidos/ASIN/0735617201 Barnes and Noble31.99http://search.barnesandnoble.com/booksearch/isbnInquiry.asp?endeca=1&isbn=07356

17201eCampus27.99http://www.ecampus.com/bk_detail.asp?ISBN=0735617201 Powells20.80http://www.powells.com/cgi-bin/biblio?isbn=0735617201 BiggerBooks27.43http://www.biggerbooks.com/bk_detail.asp?ISBN=0735617201 BooksAMillion27.99http://www.booksamillion.com/ncom/books?isbn=0735617201 AllDirect.com24.79

http://www.alldirect.com/book.asp?isbn=0735617201 VarsityBooks39.99http://www.varsitybooks.com/Search.aspx?SearchType=ISBN&SearchValue=0735617201half.com16.50http://half.ebay.com/search/search.jsp?&product=books&keyword=0735617201


68/156

59

Test Case 4

Launching the .NET client application, cwsForm.cs, from the command line or from anIDE results in the display of a user interface:


69/156

60

A user of the application, searching for books written by M. Morris Mano with apublication year 1992, enters the information as follows:


70/156

61

After the user clicks on the Search button, CWS successfully returns the following XMLdocument:

5.2 CWS vs. Current Book Brokers

5.2.1 Third Party Web Services

Xmethods.net is a popular Web site that offers a listing of third party web services. Only

three Web services exist which provide book search functionality. One Web service,

BNPriceWS, returns Barnes and Noble book prices based on a client ISBN number


71/156

62

request. The Xmethods listing directs one to the publishers Web page at

http://www.abundanttech.com/default.asp?content=WebServices/BNPrice/default.aspx.

Initially, the Web service appears to be a legitimate resource for CWS to incorporate in

its composite, Web service capabilities. However, when a test is performed on

BNPriceWS with an ISBN number of 0672326418, the following results are

disappointing:


72/156

63

If one compares BNPriceWS generated price to Barnes and Nobles actual price listed

on their Web page, BNPriceWS does not provide accurate pricing. They provide the

publishers list price, not Barnes and Nobles price. The screen captures above

demonstrate that the correct Barnes and Noble price is $39.99, not $49.99.

The second Web service that provides book search functions is ISBNInformation,

available at http://www.webservicex.net/isbn.asmx?op=GetISBNInformation, which

returns in XML format basic book information such as title, author, publisher and year of

publication, but does not provide any vendor prices.

Thirdly, BookService , available athttp://www.winisp.net/cheeso/books/books.asmx,

returns in XML format title, author, publisher, publication year and price information, but

the service only quotes prices from Amazon.com.


73/156

64

5.2.2 BookFinder4u.com

BookFinder4u.com is a fierce competitor offering a great deal of functionality which

includes price alerts, currency converter, and a broad scope of bookstores. CWS fails to

match BookFinder4u in this regard. However, CWS does distinguish itself from

BookFinder4u in two areas. One, BookFinder4u does not expose its functionality as a

Web service. The only way to programmatically access this resource is via HTML

scraping. Secondly, BookFinder4u does not allow a user to enter a combination of search

parameters in their request. The following screen capture displays their search

mechanism:

BookFinder4us radio button structure limits a users search to only one criteria. CWS

enables a user to submit multiple search parameters in a single request resulting in a more

refined and faster search response.

5.2.3 Chambal.com

Chambal.com is one step ahead of all book brokers by providing 13 digit ISBN search

capabilities. Recently, the International Organization for Standardization (ISO) approved

plans to transition from the existing 10 digit ISBN structure to a 13 digit ISBN structure

[14]. The change is taking place because the supply of available 10 digit numbers is


74/156

65

exhausting. By January 1, 2007, all book and book-related products must carry 13 digit

ISBN numbers. Currently, no other book brokers offer this functionality. CWS executes

a 13 digit ISBN search request, but responses are limited to prices from Barnes and Noble

and Booksamillion. However, Chambals advantage is short lived once Amazon and the

other players update their systems for 13 digit ISBN compliance. Also, Chambal only

provides ISBN, title and author search functionality, reducing the effectiveness of their

search mechanism.

5.2.4 FetchBook.info

FetchBook.info provides a broad scope of bookstores, price alerts, currency converter,

and customizable views of search results. However, they only allow keyword, title,

author and ISBN search capabilities. Additionally, if a user submits a 13 digit ISBN

request, the request is altered to a title-type request, probably due to a 10 digit form

validation rule, with zero results.


75/156

66

CHAPTER 6 CONCLUSION

6.1 CWS Interoperability Solution

Certainly, CWS does not solve the interoperability problem at all levels, but has

illustrated interoperability to a small degree between two different programming

languages. The CWS solution itself has its disadvantages and advantages. One

drawback behind returning an XML document as a String is that it lacks programming

structure. Secondly, the burden of interpreting and parsing the XML response is placed

on the client. Thirdly, the solution breaks down the layers of abstraction in the Web

service stack and does not hide the complexities of the service, but exposes the

implementation details.

On the positive side, the solution makes full use of the XML language. Any entity

programming with XML parsing capability can utilize CWS as a resource. Also, the

solution avoids some of the current, interoperability trouble spots, which include

employing Java Collection classes and returning an array with null elements. Lastly,

the solution omits the use of creating book instances of the BookBean class to optimize

performance. By this omission, specifically the omission of the new keyword, this

conserves server resources, reduces memory usage, and potential garbage collection.

Overall, this optimization can increase performance between CWS and a client.

Furthermore, CWS raises a few key points. First, XML is the pivotal, underlying

language that can connect disparate systems and lead to seamless interoperability. There

must be some common ground allowing for two parties to communicate. XML provides


76/156

67

this. Secondly, the decision by WS-I through its Basic Profile 1.1 towards RPC-literal

and Document-literal emphasizes a movement toward document passing Web service

solutions. Thirdly, the CWS solution demonstrates that complexity is not always a

required ingredient for every software solution. Security is one functionality that CWS

does not need to operate since the data being sent by the client and server is publicly

available. Fundamentally, CWS is passing XML documents over the HTTP wire.

LaMonica states that sending XML documents over existing Internet protocols is suited

for relatively simple applications. But businesses wanting the benefits of the flexible

systems design called a services-oriented architecture should adopt Web services. [11]

The important issue is to recognize the needs of the application and compose a solution

based on those needs. Additional levels of complexity may be unwarranted. Lastly, the

ability to aggregate various Web services into one higher-level Web service by way of

process composition is an attractive feature, leading to more functionality and greater

flexibility when business demands change.

6.2 Future of Web services

The future of Web services is difficult to forecast. Recent market research data and

trends illustrate the outlook appears promising, but a few potential pitfalls must not be

overlooked.

6.2.1 Market Research Statistics and Forecasts

An October 2004 Evans Data Corp survey [15] of over 400 developers finds that 60

percent of developers believe that Web services can be im

Ryan Michael

Documents

Transcript of Ryan Michael