Table of Contents

1.0 Chapter 1: Introduction...................................................................................................1

1.1 Motivation...........................................................................................................................1 1.2 Problem Statement.............................................................................................................2 1.3 Structure..............................................................................................................................3 1.4 Introducing Web Services ....................................................................................................................................................3 1.5 Web Services Architecture.................................................................................................5 1. 6 Web Services Stack............................................................................................................7 1.7 Characteristics of Web services.......................................................................................13 1.8 Advantages of Web Services............................................................................................14 1.9 Integration of Information Systems................................................................................15

2.0 Chapter 2: Web Services Implementation....................................................................19

2.1 Overview............................................................................................................................19 2.2 Java Implementation........................................................................................................21
Synopsis:...............................................................................................................................................21 Components Utilized.............................................................................................................................22 Assumption...........................................................................................................................................22

2.3 PHP Implementation:.......................................................................................................32

2.3.1 Synopsis:......................................................................................................................................32 2.3.2 Components Utilized....................................................................................................................32 2.3.3 Assumption..................................................................................................................................33

2.4 Conclusion.........................................................................................................................36

3.0 Chapter 3: Business and Market Dissection................................................................38

3.1 Market Overview..............................................................................................................38 3.2 Vendor Landscape............................................................................................................40
3.2.1 The Vendors.................................................................................................................................42

3.3 Web Services Adoption....................................................................................................44 3.4 Value Proposition of Web Services..................................................................................47 3.5 Challenges.........................................................................................................................52
3.5.1 Technical barrier to success.........................................................................................................52

iv

3.5.2 Market barrier to success.............................................................................................................53

4.0 Chapter 4: The End Is Only the Beginning.................................................................55

4.1 Limitation and Opportunities in research......................................................................55 4.2 Recommendation and Conclusion...................................................................................55

References:............................................................................................................................59 ...............................................................................................................................................61

List of Tables

Table 1: Summary of functions that can be performed with Google API Web Services ................................................................................................................................................21 Table 2: Parameters required to call Google Search Service...........................................25 Table 3: Who is moving towards SOA? (Heffner, 2005)..................................................39 Table 4: Stages of Web Services and SOA strategy (Adam, 2005)..................................54

vi

List of Figures

Figure 1: Web Service components (Kreger, 2001)............................................................7 Figure 2: Web Services Stack (Tomlinson, 2005)...............................................................8 Figure 3: Data Interaction Evolution (McCarthy, 2004).................................................17 Figure 4: Client interaction with Google Web services....................................................21 Figure 5: Client for Google Search....................................................................................24 Figure 6: Snippet of doGoogleSearch.xml.........................................................................26 Figure 7: doGoogleSearch.xml...........................................................................................27 Figure 8: Google Search results.........................................................................................29 Figure 9: GoogleSearchResult Schema.............................................................................30 Figure 10: ResultElement Schema.....................................................................................30 Figure 11: Client for Google Spell Check .........................................................................31 Figure 12: Front End Interface in PHP for Google Search as explained in 2.3...........35 Figure 13: Front End Interface for Google Search with Search Results as discussed in 2.3...........................................................................................................................................36 Figure 14: Gartner Magic Quadrant 2005........................................................................41 Figure 15: Phases of Web Service Adoption (Marks & Werell, 2003)............................46 Figure 16: Perceived Value of Web Services (Accenture, 2003).....................................50 Figure 17: Business advantage to using Web Services (IDC, 2004)...............................51

vii

viii

1.0 Chapter 1: Introduction

1.1 Motivation
Large enterprise systems, composed of disparate legacy systems, are notoriously difficult to connect with each other. Business to business collaboration has been

plagued by expensive integration efforts, inflexible enterprise business applications, and the inability to extend and/or augment existing business applications to accomplish new business functions as business needs change (Marks & Werrell, 2003). Enterprises are turning to Web Services and Service Oriented Architecture in order to solve integration problems. Gartner, Inc. study indicates that Service Oriented Architecture (SOA) will, in fact, provide the basis for 80 percent of development projects (Hayward, 2005). Unlike other business application integration concepts that are prevalent among large enterprises, Web services promise to provide a flexible cross platform communication. At its premise is its ability to ease integration issues between systems as well as to reduce interoperability challenges for uses. Former McKinsey consultant John Hagel, in Edging into Web Services, published in McKinsey Quarterly, November 2002 (Number 4), points out that in the decades ahead, companies will pursue strategic opportunities and performance improvements abetted by a new generation of technologies called Web services (Hagel III, 2002). In light of this problem faced by many in the IT field, this paper attempts to shed more light on the emerging Web services phenomenon and explore business and market dynamics of Web services.

1.2 Problem Statement

Do Web services enable independence and loose coupling among its systems? What dimensions of Web Services do business leaders need to examine?

The intention of this paper is to evaluate Web services technology and its potential. In reaching its goal, the paper will discuss standards associated with Web services and analyze its market forces. In order to find some answers to the above question Does Web services enable independence and loose coupling among its systems? the research project explores the Web Service phenomena by conducting a small experimentation with Google Web Services. It provides a description of the enabling technologies and shows how they work together in different environments, thus illustrating the idea of loose coupling and system independence. This paper approaches the second question with a market research on the current state of Web Services. Other key research questions to be examined include rationale for adopting Web Services, major players in the industry, possible adoption paths and business values that take advantage of Web Services. Overall, the purpose of this paper is to help the reader understand the business and technical context in which Web services operate.

1.3 Structure
To achieve its objective, the work of this paper is organized as follows: Chapter 1 describes basic technological and conceptual elements that constitute Web Services. The study will then elaborate on technological aspects of Web services architecture. Chapter 2 further explores the Web services concept with focus on their possible application in modern business environment. Two experiments will be implemented to show how Google Web Service can be invoked using different client environments. Chapter 3 focuses on the state of Web services from business user perspective. This paper extracts information mainly from market analysis and research data from various consulting and research companies such as Forrester Research, IDC, and Gartner. Furthermore, the chapter examines critical issues facing Web services in light of the hype surrounding these technologies. Chapter 4 concludes the study by summarizing the findings and discusses opportunities for further research. It also provides recommendations that business leaders can utilize.

1.4 Introducing Web Services

Web services provide a systematic and extensible framework for application to application integration that are based on service-oriented architecture (SOA), built on top of existing web protocols which rely on open XML standards (Francisco, 2002). It could just be the tip of a technological change that can have the potential to revolutionize the business world. According to IDC, a global market intelligence firm in the information technology industry, worldwide spending on software in support of Web services-based

projects reached $1.1 billion in 2003 and $2.3 billion in 2004. It estimates that spending will reach $14.9 billion by 2009 (Rogers, 2005).

Web services represent an array of interconnected technologies which are meant to enhance developers abilities to program applications for the internet. They provide an application framework for communication between enterprise systems by utilizing the concept of services. Such framework exists for popular platforms such as Java 2 Enterprise Edition (J2EE) and Microsoft .NET. Services are offered via simple protocols and formats such as HTTP, XML (eXtensible Markup Language) and SOAP (Simple Object Access Protocol). The applications do not need to be aware of the implementation of the services they wish to invoke, but simply need to know their existence and access their interfaces. By utilizing such open environments and

standards, individual Web services are ensured of platform independence and languageneutrality. The functionality provided by a Web services can vary widely from the simplest information retrieval to the most complex business operation. Basic Web services may be invoked to retrieve stock quote or zip code. More complex Web services may be called to manage complicated transactions in an enterprise supply chain application (Johnston, 2002). It is however a daunting task to pinpoint one clear definition of Web services because of the technologys evolving nature. Existing definitions -- ranging from all-inclusive and very generic to the very specific are plenty yet incomplete. Gartner, for instance, defines Web services as "loosely coupled software components that interact with one another dynamically via standard Internet technologies." Forrester Research takes a more open approach to Web services as "automated connections between people, systems and applications that expose elements of business functionality as a software

service and create new business value." Anne Thomas Manes, author of Web Services: A Manager's Guide, however cautions about definitions of Web Services that are being proposed which are nothing more than hype (Manes, 2003). She defines Web services simply as an application that provides a Web API. Nonetheless, many would agree that Web services have three key components: interoperability, common representation and a heavy reliance on standards. The World Wide Web Consortium (W3C), an international consortium created in October 1994, oversees development of common protocols related to World Wide Web.

According to W3C, A Web service is a software system designed to support interoperable machine-tomachine interaction over a network. It has an interface described in a machineprocessable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards1. The W3C definition will be the basis of this paper. However, it must be stressed that although the actual definition of Web services is not complete, Web services affect many standardization efforts.

1.5 Web Services Architecture

The architectural concept behind Web services is the service oriented architecture (SOA). In SOA, applications are modeled as compositions of services provided by components that can be discovered and invoked dynamically (Wainewright, 2002). The core architecture is based upon the interaction between three primary roles (see Figure 1): i.
1

Service Provider:

http://www.w3.org/TR/2004/NOTE-ws-gloss-20040211/

The service provider provides access to the Web services and publishes the service description in a service registry. Service provider, in a business sense, is the owner of the service. Once Web services are created, they can be published to service registry, describing the services functionality as well as information about the creators. This is currently achieved using Web Services Definition Language WSDL. ii. Service Registry

The service registry is an entity that acts as a searchable repository for the software interfaces published by the providers and that can be discovered by potential service requestors. It provides a centralized location for storing service descriptions and can be described as middlemen acting as broker for service providers and requestors. The de-facto description and query support is currently based on UDDI. iii. Service Requestor

The service requestor is an entity that discovers and invokes other software services in order to accomplish a task or provide a business solution. It finds the service description in a service registry and uses the information in the description to invoke a service. The service requestors are those businesses that require certain tasks covered by corresponding service providers. They are the actual consumers of Web services. Information in the WSDL is used to connect and invoke each Web service. These 3 roles interact using publish, find and bind operations. Publish Find Bind

After a Web service is built by the Service Provider, a description of its service is posted to the Service Registry. Thus, a Service Provider publishes its service to Service Registry to make it possible for a Service Requestor to find a web service. The Service Requestor, an entity which needs Web services, searches the service registry and locates the desired service description. In other words, the Service Requestor finds a service description by inquiring the Service Registry. This find operation can occur in two different lifecycle phases for the Service Requestor: at design time or at runtime. The Service Requestor finally connects to the service using the binding details in the service description to locate, contact and invoke the service.

Provider Description

Service Description

Service Registry

Publish via UDDI

Find via UDDI

Service Description

Service Provide r Service

Bind via SOAP

Describe via WSDL

Service Requesto r (Consum er) Client Application

Figure 1: Web Service components (Kreger, 2001)

1. 6 Web Services Stack

Web Services are modular, distributed applications based on industry standard technologies such as SOAP, UDDI, WSDL and BPEL4WS. Kart Gottschalk, Web Services Technical Strategist at IBM Software Group, introduces Web Services Stack as

a collection of standardized protocols and application programming interfaces that lets individuals and applications locate and utilize Web services (Gottschalk, 2002). This section briefly describes standards such as SOAP, WSDL, UDDI, WS-Security, WS-TX and BPEL4WS.

BPEL4WS WSDL, UDDI

Business Processes Description

Process es
Quality of Service

Security SOAP

Reliable Messaging

XML, Encoding

Transport & Encoding

Figure 2: Web Services Stack (Tomlinson, 2005)

1.6.1 Simple Object Access Protocol (SOAP) SOAP is based on XML and Hypertext Transport Protocol. It provides a way for applications to communicate and work together through remote procedure calls implemented via HTTP. W3C defines SOAP as [an] XML based protocol that consists of three parts: an envelope that defines a framework for describing what is in a message and how to process it, a set of encoding rules for expressing instances of applicationdefined datatypes, and a convention for representing remote procedure calls and responses. To put it simply, SOAP is the protocol that Web services use to communicate in a distributed environment.

A SOAP message contains an XML document whose root element is called the Envelope. We can define a SOAP message as a transmission of information from a sender to a receiver. A SOAP message can be a request message, a response message or a fault message. The envelope is the top element of the XML document, providing a container for control information, the addressee of a message, and the message itself (Laftsidis, 2002). Within the envelope, there are two child elements called the header and the body. Application payloads are carried in the body, while the information held in the header blocks usually contains data from the various Web services protocols that augment the basic SOAP infrastructure. 1.6.2 Universal Description, Discovery and Integration (UDDI) UDDI describes how to publish and discover information about Web services applications. It is a Web-based directory where one can search for Web services. It therefore offers a unified and systematic way to find service providers through a centralized registry of services that is roughly equivalent to an automated online phone directory of Web services (Francisco, 2002). The information provided in the UDDI directory contains three components:

1. White Pages: It includes the business name, contact details and a text
description of the businesses services

2. Yellow Pages: It includes industrial categorization based on business and

service types

3. Green Pages: It includes references to specifications for Web services

and pointers to a various file, i.e. technical data about the services

1.6.3 Web Services Description Language (WSDL)

WSDL is a standard specification for describing Web services interface and provides mechanics of service interaction. In other words, it is a structured mechanism to describe functional interface of Web services. It provides a formalized description of publisher-consumer interaction. For example, when an enterprise is ready to publish Web service and its description, it can publish them in a UDDI repository. Consequently, a Web service consumer can request the WSDL file so it can determine its location, function calls and method to get to them.

1.6.4 Business Process Execution Language for Web Services (BPEL4WS) BPEL4WS is a business process modeling language to orchestrate interactions between Web services. It defines a set of communication activities dealing with the sending and receiving of messages so that a workflow process instance can communicate with partners Web services. WSDL did not pay enough attention to the processes and workflows that coordinate these services (Kim, 2003). To complement this, BPEL4WS was proposed by IBM, Microsoft, and BEA Systems in July 2002, based on two earlier standards XLANG and WSFL, for design and implementation of Web Services-based processes. The core of BPEL4WS is the process. Research firm Gartner Inc. sees the Business Process Execution Language for Web Services as the strategic direction for process definition (Radcliffe, 2004).

Specifically geared for SOA processes, BPEL4WS is increasingly seen as the preferred open, interoperable, and portable solution that enables Business Process Management (BPM) within a diverse, shared computing environment. It is layered on top of WSDL and separates deployment of the process from the process model. Standards such as

10

BPEL4WS will drive the evolution of Web services into a technology that can help enterprises orchestrate complex business processes (Smith, 2003).

BPEL4WS provides three activities such as invoke, receive, and reply each of which handles a different type of interaction between partners in a workflow. The ultimate goal of BPEL4WS is to abstract underlying Web services such that the business process language effectively becomes the Web services API.

1.6.5 WS-Security WS-Security specification, ratified by Organization for the Advancement of Structured Information Standards (OASIS) on 2004, is the core security framework that enables interoperability between Web services security standards and security protocols. It is a Simple Object Access Protocol (SOAP) extension that can be used when building secure Web services to implement message content integrity and confidentiality (Evers, 2004). In other words, WS-Security defines additional headers that can be added to a SOAP message to provide Quality of Service (QoS) criteria such as message integrity, single message authentication and message confidentiality in Web services applications. These mechanisms can be used to accommodate a wide variety of security models and encryption technologies (Thompson, 2003). WS-Security supports multiple security tokens, trust domains, signature formats and encryption technologies.

According to OASIS, WS-Security is comprised of three main components: security token propagation, message integrity and message confidentiality. These can be used independently or in different combinations, for example signing and encrypting a message and providing a token associated with the keys.

11

WS-Security provides a foundation for further security specifications that are under various stages of development, including WS-Trust, WS-SecureConversation and WSSecurityPolicy. WS-Trust is an extension to WS-Security that ensures the service requestor is properly authenticated before security tokens are issued. WS-

SecureConversation extends the trust derived from positive authentication to groups of messages. It is built on top of the WS-Security and WS-Trust models to provide secure communication between services. And WS-SecurityPolicy enables services to exchange security policies and to negotiate authentication and authorization without user intervention (Rist, 2005).

1.6.6 WS-I WS-I is an industry organization designed to promote the development and deployment of interoperable Web services across a variety of platforms, applications and programming languages. WS-I was created to provide implementation guidance to support customers deploying Web services, promote consistent and reliable

interoperability among Web services, and articulate a common industry vision for Web services2. Specifically, WS-I creates, promotes and supports generic protocols for the interoperable exchange of messages between Web services.

Dan'l Lewin, Microsofts Corporate Vice President for .NET business development, believes WS-I has two key goals. First, is to provide implementation guidance and education to accelerate customer deployments. Second, to articulate and promote a common industry vision for Web-services interoperability to ease customer decision making, to grow market adoption of Web services and to ensure the continued evolution of Web services technologies (Lewin, 2002).
2

www.ws-i.org

12

1.6.7 WS-TX WS-TX is a set of standards-based protocols for coordinating the outcome of complex transactions in a distributed system. The standards will enable Simple Object Access Protocol (SOAP) and its extensions to act as an internetworking protocol for messagebased and loosely coupled systems. This will allow organizations to extend the messaging paradigm throughout the enterprise and to business partners and customers. The transaction framework will also support existing transaction-processing workflows and enable other coordination systems to interoperate in heterogeneous environments while continuing to use proprietary protocols (Abrams & Sholler, 2005).

WS-TX is trying to refine and enable industry collaboration on three transaction specifications: WS-Coordination, WS-AtomicTransaction and WS-BusinessActivity.

1.7 Characteristics of Web services

A Web service is characterized by its flexibility to encapsulate discrete business functionalities and its interoperability to support universal application integration. Some other characteristics of Web services are: i. Self contained

An application enabled for Web services doesnt need extra run time environment and can perform predetermined tasks

ii.

Self describing Any program can access and use a Web service by using standard format

iii.

Modular

13

Components are reusable and it is possible to compose them into larger components.

iv.

Published, located and invoked across the web

Service descriptions are made available in a public repository where users can find the service and use the description to access the service.

1.8 Advantages of Web Services

Advantages created by web services can be manifested in 5 key points. i. Platform independence: Web services are designed to be platform and language independent. As a result, Web services can be developed using any language and deployed on any platform. Through new standards and protocols, applications can be developed which are able to communicate with each other so as to go beyond the confines of operating systems, programming languages and middleware systems. ii. Applied on existing infrastructure: Its current use is mainly in integrating existing systems with each other. This is consistent with the idea of managing and mastering heterogeneity. In its aim at realizing the full benefits of distributed computing, Web services allow new and existing components of logic to be brought together in different ways to support the evolving requirements of the business. iii. Standards based: Standard is of great importance since the promise of Web services lies in technology independence and the adoption of and adherence to standards. XML is a standard which makes it possible to automatically manipulate and process data, and where separation of content and presentation is one of the

14

core characteristics. SOAP in turn allows remote method invocation through the use of XML, providing flexibility and robustness. iv. Modularity: The emphasis on the reuse of components introduces the potential for great improvements in developer productivity and the subsequent ability for companies to respond very rapidly to new business needs. Web services are highly reusable, so each one can be used for several business processes or combined with other web services to support entire chain process. v. Loosely coupled: Any two applications that exchange information using SOAP protocol are not tightly bound to each other. The source application doesnt have to know anything about its target application. Thus, if any of the application is replaced or rebuilt, it will neither affect the integration nor cause any alterations to other applications. Web services aim to remove current IT constraints by breaking up the tight coupling between applications and application components, changing them to a more adaptable loose coupling.

1.9 Integration of Information Systems

Now more than ever, mergers, acquisitions, outsourcing, and business growth have driven the need to share information stored in companys enterprise systems. Today internet is more than just a physical network. It has become a computing execution network, processing commercial transaction and business applications (Wainewright, 2002). According to Sapient study, Creating a strategy for application integration is among the greatest challenges facing IT leadership today (Sapient, 2004). The study further states that it has become critical because competitive pressures are forcing

15

businesses to respond to changing demands quickly and cost-effectively. A simple business process of loan processing might involve interaction of more than one database systems before the process is finalized. In order to extract business intelligence from vast amount of data, present day industry needs to trade with wider group of partners. In light of this probing need, business as well as IT leaders are taking a hard look at how data from disparate systems can be seamlessly integrated. More and more organizations are now attempting to link their businesses and systems in support of new initiatives such as collaboration, partner relationship management, product life cycle management and other emerging business needs (Marks & Werrell, 2003). This section attempts to take a historical look at the progress of IT in terms of data integration. Analysts contend that the recent development of Web services technology delivers significant promise for application integration in the next interoperation paradigm. Web services can act to integrate data from heterogeneous databases, and across different operating platforms. True application integration requires tools that go one step beyond what conventional middleware and Enterprise Application Integration (EAI) platforms have achieved. Web services and the associated technology are being leveraged to take such a step (Gustavo Alonso, 2004).

16

Figure 3: Data Interaction Evolution (McCarthy, 2004)

Figure 3 shows how emergent technologies have paved way for newer possibilities for data interaction. During the 1960s and 1970s, centralized database systems were hosted on large servers and represented a monolithic and centralized architecture which were implemented on mainframe systems. These systems were inflexible to business changes and market dynamics. Data were opaque and inaccessible while the network was limited and closed. From the mid 1970s to early 1980s, distributed database

systems started to take hold. These distributed systems were connected via a shared network and the architecture was homogeneous and controlled. Databases were binary and proprietary in nature. A software infrastructure provided by a certain vendor then would be limited to a specific platform and contained proprietary communication protocols making it difficult to integrate with other systems. 1980s were the era of personal computing, where users would have the ability to hold chunks of data on their

17

desktop computer. Although popular, their lack of integration and inability to share information made them disconnected silos of data. The internet, which provided a global network for enterprises to communicate with each other worldwide, changed much of that in the mid 1990s. Internet and its network structure made it possible to send emails and share files. World Wide Web and Hyper Text Transfer Protocol (HTTP) together added a layer in the network for anybody to publish and access contents from anywhere. Now, Web services are further enriching the software layer with application functionality. In summary, the history of application integration included migrations from host systems to client/server computing, to integrated enterprise application suites, to Web applications, to n-tier architectures and distributed computing, to enterprise portals, and now to Web services and grid computing (Gardner, 2003). In addition to providing

literature reviews on Web services, this paper pays close attention to the application integration notion. Chapter 1 is therefore an impetus to our next chapter, which serves to validate the Web services integration concept by experimenting with Google Web Services.

18

2.0 Chapter 2: Web Services Implementation

2.1 Overview
A Web service can be the service itself or the client that accesses the service 3. In an effort to further understand Web services technical capabilities, I have developed two client applications to access Google API Web services provided by Google. This is an exploratory case study motivated by one particular observation. I have been fascinated by the current pace of progress and innovation of application developments that utilize Web API provided by Google, eBay, Yahoo and Amazon. For example, entities such as Amazon and eBay allow external partners and associates to plug into their own IT infrastructure through Web services. HousingMaps.com is yet another application that utilizes Google Maps API with Craigslist to generate real estate listings with an added functionality of Google maps. I wanted to experiment further into Google API with one question whether it is possible to test the service with two distinct programming languages and produce the same result. This experiment starts with the premise that Web services promote decoupling and language independence. Two successful implementations that produce the same result will confirm Google Web Services loose coupling and platform independence features. Author Denise M. Gosnell of Professional Development with Web APIs: Google, eBay, Amazon.com, MapPoint, FedEx describes Web APIs as application programming interfaces that are available over the Internet (Gosnell, 2005). In short, Web API can be regarded as a series of Web services -- each of which has one or more procedures that can be called using the Internet. By using the Simple Object Access Protocol (SOAP) and Web Services Definition Language (WSDL) specifications, Google lets developers
3

IBM WebSphere Information Center http://publib.boulder.ibm.com/infocenter/ws51help/index.jsp? topic=/com.ibm.websphere.base.doc/info/aes/ae/cwbs_wbs2.html

19

choose their favorite development environments and languages -- including (but not limited to) .NET, C/C++, Java, PHP, Perl, Python -- in which applications can be written to consume its online search engine functions. The first implementation of Google Client is applied in a J2EE environment and the second one is done in PHP. A successful experimentation done through the use of two different development environments (Java and PHP) will support the theory of loose coupling of Web services. A technology may be termed loosely coupled if it can be connected to other disparate applications interfaces relatively easily. Applications are typically integrated via interfaces an interface exposes the functionality and data contained within the application and is used by other systems to access that functionality (Sapient, 2004). As mentioned, Google Web services provide a mechanism for a client program, executing on a local host, to invoke a server functions such as Google Search, Google Spellings and Google Cached Page. The search result is gathered in XML format which allows us to present the result in myriad ways by transforming it into another format using standard tools such as XSLT.

Figure 44 shows how clients for Web Services can interact with Google Web API. Our client application initiates contact and sends appropriate parameters to the Google Web
4

Ahm Asaduzzaman, 2003 http://www.devarticles.com/index2.php? option=content&task=view&id=422&pop=1&page=0&hide_js=1

20

API. After which, the Google Web API validates all the parameters and, if correct, sends back the results to the client application. Otherwise, an error message will be generated.

doGoogleSearch Client result Client Client Index Servers, Repository Google Web API

Figure 4: Client interaction with Google Web services

Table 1 outlines three Google Web services functions that a client application can call.

Callable functions Search search for specified term in the Google database Cache - retrieve cache page from the Google cache

Corresponding methods in GoogleSearchProxy doGoogleSearch doGetCachedPage

Spelling - retrieve a spelling suggestion from doSpellingSuggestion Google

Table 1: Summary of functions that can be performed with Google API Web Services

2.2 Java Implementation

Synopsis:

21

In order to access Google Web service from a Java client, I used IBMs Web Sphere Studio as my development environment. Web Sphere studio is a development environment from IBM which can be used for designing, testing and deploying Web services and Java (J2EE) applications. It also helps integrate and re-use business applications by discovering and using existing Web services.
Components Utilized

Windows XP WebSphere Studio Application Developer, Version 5 Google developer kit : googleapi.zip The GoogleSearch.wsdl file

Assumption

There is a direct network connection to reach the Google server Some knowledge of J2EE technologies

Experimentation Progresses in following steps: 1. Preparation i. Install IBM Websphere Studio Get Google Software Development Kit Get Google Web API License Key

ii. iii.

2. Implementation

i. ii. iii. iv.

Create test client environment Import GoogleSearch.WSDL file Generate Java proxy classes Launch test client

22

With the help of WebSpheres Enterprise Application Project Creation wizard, we first create the test client environment for our development purposes (Wahli, 2001). Next, we utilize WSDL file to enable our test client to connect to a Web service. In our case, we will be using Google.WSDL file so that we can generate client side java proxy classes. The java proxy is used by our client code to access and consume Google Web services. Once Google.WSDL file is imported, our next step is to make WebSphere Studio process the Google.WSDL file and create conforming Java codes. At the end of this step, Java code for each of the functions that we want to request in our Web services will be created.

We are now ready to launch our test client. Figure 5 demonstrates that an instance of our test environment has started and a web browser within WebSphere Studio server perspective is shown. The test client has three main panes:

1. Methods Pane (left) Lists functions of Google Web services which are available for testing. The functions are: Search, Spell Check and Get Cached Page

2. Parameters Input Pane (Right-Top) Shows input form where a developer enters required parameters to call a particular Google Web services function

3. Result Pane (Right-Bottom) Displays the results of a requested function.

23

Figure 5: Client for Google Search

In Figure 5, we have selected GoogleSearch method (from Methods Pane) to test. In the Parameters Input Pane, we have entered SFSU College of Business as our search query and an alphanumeric number as our unique license key that authorizes use of Googles Web services. In addition, we have entered 1 in start field and 10 in maxResult field to display 10 results at once -- starting at 1 as our first desired result. The rest of the input fields are left blank to indicate default values.

All of the required parameters to invoke a doGoogleSearch service are listed in table 2. It lists all the valid name-value pairs that can be used in a search request and describes how these parameters will modify the search results.

24

Key Q Start maxResults filter restrict

Provided by Google, this is required for you to access the Google service. Google uses the key for authentication and logging. Search Query Zero-based index of the first desired result. Number of results desired per query. Activates or deactivates automatic results filtering, which hides very similar results and results that all come from the same Web host. Restricts the search to a subset of the Google Web index, such as a country like "Ukraine" or a topic like "Linux." A Boolean value which enables filtering of adult content in the search results. Language Restrict - Restricts the search to documents within one or more languages. Input Encoding - this parameter has been deprecated ignored. All requests to the APIs should be made with encoding. Output Encoding - this parameter has been deprecated ignored. All requests to the APIs should be made with encoding.
Table 2: Parameters required to call Google Search Service

safeSearch Lr Ie

and is UTF-8 and is UTF-8

Oe

When Invoke button is clicked, our test client invokes a doGoogleSearch service request to the Google API. Figure 6 represents a SOAP XML request message sent to Google Web services for our search request. The Google Web services SOAP server will try to execute doGoogleSearch method with those parameters and send a SOAP response back to our client application. The response is either the result of the execution or the appropriate error message.

25

<?xml version='1.0' encoding='UTF-8'?> <SOAP-ENV:Envelope xmlns:SOAPENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:xsd="http://www.w3.org/1999/XMLSchema"> <SOAP-ENV:Body> <ns1:doGoogleSearch xmlns:ns1="urn:GoogleSearch" SOAP ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <key xsi:type="xsd:string"> SAMPLEKEY </key> <q xsi:type="xsd:string">SFSU College of Business</q> <start xsi:type="xsd:int">1</start> <maxResults xsi:type="xsd:int">10</maxResults> <filter xsi:type="xsd:boolean"></filter> <restrict xsi:type="xsd:string"></restrict> <safeSearch xsi:type="xsd:boolean"></safeSearch> <lr xsi:type="xsd:string"></lr> <ie xsi:type="xsd:string"></ie> <oe xsi:type="xsd:string"></oe> </ns1:doGoogleSearch> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Figure 6: Snippet of doGoogleSearch.xml

To be more specific, Figure 6 represents messaging framework for transferring information specified between our client program and Google Web services in an XML form. Elements within <SOAP-ENV:Body> tag contain the primary content of the message and represent parameters which are required to call Google Search service. For e.g., <q xsi:type="xsd:string">SFSU College of Business</q> represents a SOAP element which signals Google Web services that the search term is SFSU College of Business. from first result and Similarly, <start xsi:type="xsd:int">1</start> implies start

<maxResults xsi:type="xsd:int">10</maxResults> indicates

that maximum result numbers has to be 10. Before any request is sent, at a minimum, a request must contain two parameters: the query term(s) and the developers license key. A detailed discussion of the means by which such messages are transferred is deferred to section 1.6.

26

When all of the required parameters are sent to Google Web services, a corresponding SOAP response message, as shown in Figure 7, will be generated.

HTTP/1.1 200 OK Date: Thu, 18 Nov 2005 12:46:08 GMT Content-Length: 1325 Content-Type: text/xml; charset=utf-8 <?xml version='1.0' encoding='UTF-8'?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:xsd="http://www.w3.org/1999/XMLSchema"> <SOAP-ENV:Body> <ns1:doGoogleSearchResponse xmlns:ns1="urn:GoogleSearch" SOAPENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <return xsi:type="ns1:GoogleSearchResult"> <documentFiltering xsi:type="xsd:boolean">false</documentFiltering> <estimatedTotalResultsCount xsi:type="xsd:int">12400</estimatedTotalResultsCount> <directoryCategories xmlns:ns2="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="ns2:Array" ns2:arrayType="ns1:DirectoryCategory[0]"> </directoryCategories> <searchTime xsi:type="xsd:double">0.440601</searchTime> <resultElements xmlns:ns3="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="ns3:Array" ns3:arrayType="ns1:ResultElement[0]"> </resultElements> <endIndex xsi:type="xsd:int">0</endIndex> <searchTips xsi:type="xsd:string"></searchTips> <searchComments xsi:type="xsd:string"></searchComments> <startIndex xsi:type="xsd:int">0</startIndex> <estimateIsExact xsi:type="xsd:boolean">false</estimateIsExact> <searchQuery xsi:type="xsd:string">SFSU College of Business</searchQuery> </return> </ns1:doGoogleSearchResponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Figure 7: doGoogleSearch.xml

27

The SOAP response/request is carried in the body of an HTTP request; thus, the HTTP header information appears above the SOAP request. As indicated before, <SOAPENV:Body> tag contains the primary content of the message. For example, <estimatedTotalResultsCount si:type="xsd:int">12400</estimatedTotalResultsCount>

indicates that the estimated result numbers for SFSU College of Business as our search query is 12400. Similarly, <searchTime xsi:type="xsd:double">0.440601</searchTime> indicates that it took about 0.440601 seconds to execute the results. The results are stored in ResultElement as an array. After Google Web services replies with the results, the final step is to create a client user interface that parses and displays those results in some useful fashion. Figure 8 shows matching results in the Result Pane. The figure shows results of our search term SFSU College of Business along with search time and total search results.

28

Figure 8: Google Search results

If we want to further dissect the elements of Google search result, we can refer to its WSDL file structure. The full Web Service Description Language for the service can be found at http://api.google.com/GoogleSearch.wsdl. Figure 9 and Figure 10 represent part of the Google web services WSDL structure.

When the doGoogleSearch method was called, Google Web services returns a GoogleSearchResult object. GoogleSearch.WSDL file defines how the structure of such GoogleSearchResult object looks like and what kind of data it should represent. As

29

shown in Figure 9, GoogleSearchResult contains an array of information about the result such as total results count, search time, directory category and ResultElement. The ResultElement further contains an array of information such as cachedSize, directoryCategory, directoryTitle, hostname, relatedInformationPresent, snippet,

summary, title, and URL (refer to Figure 10).

<xsd:complexType name="GoogleSearchResult"> <xsd:all> <xsd:element name="documentFiltering" type="xsd:boolean"/> <xsd:element name="searchComments" type="xsd:string"/> <xsd:element name="estimatedTotalResultsCount" type="xsd:int"/> <xsd:element name="estimateIsExact" type="xsd:boolean"/> <xsd:element name="resultElements" type="typens:ResultElementArray"/> <xsd:element name="searchQuery" type="xsd:string"/> <xsd:element name="startIndex" type="xsd:int"/> <xsd:element name="endIndex" type="xsd:int"/> <xsd:element name="searchTips" type="xsd:string"/> <xsd:element name="directoryCategories" type="typens:DirectoryCategoryArray"/> <xsd:element name="searchTime" type="xsd:double"/> </xsd:all> </xsd:complexType> Figure 9: GoogleSearchResult Schema

<xsd:complexType name="ResultElement"> <xsd:all> <xsd:element name="summary" type="xsd:string"/> <xsd:element name="URL" type="xsd:string"/> <xsd:element name="snippet" type="xsd:string"/> <xsd:element name="title" type="xsd:string"/> <xsd:element name="cachedSize" type="xsd:string"/> <xsd:element name="relatedInformationPresent" type="xsd:boolean"/> <xsd:element name="hostName" type="xsd:string"/> <xsd:element name="directoryCategory" type="typens:DirectoryCategory"/> <xsd:element name="directoryTitle" type="xsd:string"/> </xsd:all> </xsd:complexType> Figure 10: ResultElement Schema

30

Likewise, Figure 11 illustrates an instance of our test environment where web browser within WebSphere Studio server perspective is shown for Google Web services Spell Check function. The Parameters Input Pane shows two input fields names - key and phrase. Field name key captures our Google Web API license key and field name phrase takes in any word or phrase we would want to do a spell check on. The Result Pane displays result of a call to retrieve spelling suggestion from Google Web services doSpellingSuggestion function. In this example, when an incorrect word dictionari is entered into the phrase field along with my Google key, Google Web services responds back with a corrected spelling dictionary which is displayed in Result Pane (Figure 13).

Figure 11: Client for Google Spell Check

31

2.3 PHP Implementation:

2.3.1 Synopsis:

This section provides a summary of how I have used the PHP programming language to create an online interface for Google Web services. I chose PHP for my other client interface development because of its usefulness in rapid application development. In addition, it would expand my knowledge on PHP as well. A full demo can be tested at http://cob.sfsu.edu/temp/. The client is a web interface that can connect to Googles repository and search for specific terms. The scenario involves requesting Googles Web service from a URL using SOAP messages over a Hypertext Transport Protocol (HTTP). Googles Web service receives the request, processes it, and returns a response. At the end, the process allows us to display the search result on our Web site in a customized way. The client has following basic features: i. ii. iii. iv. v. Spell Check Find Related Pages Search within a particular site (e.g.: sfsu.edu) Find/View Cached Page Convert HTML file to PDF format Get Alexa Rank for a particular site (via Alexa Web Services) Get Google suggestion for search queries Get Site Information from (via Alexa Web Services)

vi.
vii. viii.

2.3.2 Components Utilized

o o o

Apache Web Server PHP 5 GoogleSearch.wsdl

32

o o

NuSOAP HTML, Cascading Style Sheet

2.3.3 Assumption o o There is a direct network connection to reach the Google server Some knowledge of PHP

Experimentation Progresses in following steps: 1. Preparation i. Install NuSOAP Get Google Web API License Key

ii.

2. Implementation

i. ii. iii.

Create a SOAP client Transmit the SOAP request Receive and extract data from the response

Creating a SOAP client in PHP To create the SOAP client, the program takes advantage of the built-in SOAP functionality of PHP. Following code generates a new client and stores the result in variable called soapclient.

$soapclient = new soapclient('http://api.google.com/GoogleSearch.wsdl', 'wsdl');

33

Now that the client has been created, SOAP parameters are initialized and call to one of the Google Service function doGoogleSearch is performed. $soapclient = new soapclient('http://api.google.com/GoogleSearch.wsdl', 'wsdl'); $parameters = array( 'key'=> $>key, 'q' => $query, 'start' => $start, 'maxResults' => $results, 'filter' => $filter, 'restrict' => '', 'safeSearch' => $safe, 'lr' => '', 'ie' => 'latin', 'oe' => 'latin' $results = $soapclient->call('doGoogleSearch',$parameters);

The above code sends a SOAP request to Google Web services. As a result, a Google SOAP response that contains relevant result will be transmitted back to the client.

Receiving and extracting data from the response Subsequent to SOAP response from Google Web services, it is now time to extract data from the response. Following PHP code captures the response. Once required information has been retrieved, it can be presented in any format that we want to demonstrate.

34

$amount = $results['estimatedTotalResultsCount']; $title = $result['title']; $snippet = $result['snippet']; $url = $result['URL'];

Figure 12: Front End Interface in PHP for Google Search as explained in 2.3

35

Figure 13: Front End Interface for Google Search with Search Results as discussed in 2.3

2.4 Conclusion
These small experiments illustrated that it is possible to have flexible connections among applications running on diverse platforms. This experimentation, therefore, validates the loose coupling premise for our example business scenarios. Without having any detailed information about Googles database systems or its platform, the experiment illustrates how an application can be built to connect with each other. The benefit of designing interfaces to reduce the interdependencies and to increase flexibility across modules or components can be strongly argued for adopting Web services. Our experimentations are but small examples of how Web services can be a valuable addition to many integration projects. To exploit the full business potential created by such loosely

36

coupled technology as Web services, IT managers and architects alike will need to creatively design new, more loosely coupled management approaches and take advantage of the flexibility provided by the technology.

Business leaders, however, need more than a good technology to be convinced of its benefits. It is a fundamental reality in todays IT management neither to spend lavishly on the latest state-of-the-art technology nor to fall far behind in technology adoption. IT executives therefore face challenge of accurately timing and managing technology investments as it relates to business value. This paper, therefore, ties in next chapter with a purpose of assessing Web services market dynamics. The chapter is designed to help business leaders educate themselves about Web services concept from a user standpoint.

37

3.0 Chapter 3: Business and Market Dissection

3.1 Market Overview
Web services facilitate applications to exchange and combine data in new ways, thus enabling on-the-fly business relations to a much greater extent than before. It is no surprise that many experts are counting on Web services to have a considerable impact on the future development of the Internet as a means for conducting business transactions (Vlachakis et al, 2003). This chapter aims at describing market trends, industry directions, and business applicability of Web services. It seeks to answer some of the elemental questions such as how can Web services be utilized to drive collaboration and the creation of business value. In an effort to present the competitive landscape of Web services, this section examines the logic behind adoption of this technology, the drivers and inhibitors, key players and adopters. We believe this chapter will help business leaders gain ample knowledge on Web services and on its business capabilities. Industry analysts and consulting firms expect Service Oriented Architecture (SOA) and Web services market to grow rapidly. Radicati Group's "Web Services Market 20042008" report foresees that the combined market for Web services solutions, management, integration and security will climb to $6.2 billion by 2008 (Radicati, 2004). IDCs Worldwide Web Services Software 2005-2009 Forecast reports that SOA market will go from $4.1B in 2005 to $14.9B in 2009 (Rogers, 2005). IDC predicts over 80% of I.T. projects will involve Web services by 2008, with a potential user base of over 500,000 professional developers.

38

In a study conducted by The Data Warehousing Institute that evaluates the progress of data integration strategies and the IT challenges associated with implementation, 69% of respondents said that data integration issues are a barrier to implementing new applications (White, 2005). The study surveyed 672 IT and business users across

multiple industries. Businesses, in turn, are looking into SOA for solving their data integration issues. As such, interest among vendors and businesses to move toward Service Oriented Architecture (SOA) market is very high.

According to the most recent Forrester Research data, about 89% of the surveyed enterprise will be moving towards service oriented architecture.

Who and what Large orgs Medium orgs Small orgs Internal Integration External Integration

Now 70% 28% 22% 37% 15%

End 2005 89% 61% 40% 74% 21%

Table 3: Who is moving towards SOA? (Heffner, 2005)

Business leader are hence invigorated by the possibility of cost-efficiently and easily integrating heterogeneous IT systems, which is very tempting, compared to traditional integration methods where such systems could be interconnected only with huge development efforts. The Forester Research survey included 116 North American corporate decision makers who came from large companies, with 20,000 or more employees; medium-sized companies, with 5,000 to 19,999 employees; smaller enterprises, with 1,000 to 4,999 employees; and small to midsized businesses with less than 1,000 employees (Heffner, 2005). The report concludes that the majority of small to midsized businesses that plan to use SOA intend to use it primarily for internal

39

integration, 74% expect to use SOA for internal integration, while 21% expect to use it for external integration (Bharti, 2005).

Capgemini U.S. LLC Pulse survey, which surveyed almost 200 participants attending the Oracle OpenWorld conference in San Francisco on September 2005, echoes familiar outlook. While only one-third (35%) of enterprises currently use SOA, more than eight in ten (82%) plan on utilizing these architectures in the near future (Blank, 2005). Respondents indicated that the top three IT benefits from SOA were 1 - Cost reductions on integration projects (40%), 2 - Greater flexibility to handle future change (37%) and 3 - An increased return on existing assets (18%). Nearly half of participant in the survey (48%) identified themselves were IT architects, while 22% were CIO/CTOs and another 22% were in sales and marketing. 41% of them came from companies with more than $1 billion in annual revenue (Blank, 2005).

3.2 Vendor Landscape

In order for us to evaluate the status of Web services, we need to take an in-depth look at major software vendors and their influence on emerging Web services platform standards. The sheer prospect of Web services usefulness and domination in areas such as data and application interaction are undoubtedly influencing the strategic orientation of vendors. According to Gartners Magic Quadrant for Web Services Platforms 2005 (Figure 14), IBM, Microsoft, Tibco, Oracle and SAP lead the market for the Web services platform in 2005. Gartner releases its Magic Quadrant each year so that IT managers can use it as a part of an overall IT strategy that ranges from business strategy to tactical product selection.

40

Figure 14: Gartner Magic Quadrant 2005

The Leaders, according to Gartner, are high-viability vendors with proven track records in Web services, as well as vision and business investment which indicate they are well positioned for the future. In addition, they provide solutions that offer relatively lower risk. As depicted in the Figure 14, IBM, Microsoft, Oracle, Tibco and SAP fall under the Leaders category of vendors. BEA Systems, a Challenger, is the kind of vendor that competes but does not offer strongly differentiated vision or commitment to Web services innovation. Among the Visionaries, Sun Microsystems, Novell, Progress Software, webMethods, Sonic and SeeBeyond are grouped together. These vendors are differentiated by innovation, but have not achieved the record of execution in Web services enabled software to give themselves the high visibility of Leaders. Gartner suggests that we expect state of the art technology from each of these companies but also monitor their commitment and business strategies to gauge the long term viability of their products.

41

3.2.1 The Vendors

Foreseeing a potentially big market, many vendors in the Web services market have made great efforts in tailoring their strategies to provide a platform capable of supporting different applications and systems, and have made massive investments in the necessary infrastructure for the new IT architecture to work. A brief note on some of the leaders in Web services below will help clarify the competitive landscape. 3.2.1.1 Microsoft: By way of its Microsoft platform, .NET technology and its heavy influence on the ongoing development of standards for Web Services, Microsoft continues to provide leadership in this area. It maintains that, .NET is the Microsoft Web services strategy to connect information, people, systems, and devices through software. However, .NET a part of the companys strategy, which includes Web Services remained confusingly positioned, and Microsoft had not fully articulated its business strategy for Web Services until its reorganization into three broad business divisions. By appointing Ray Ozzie as its Chief Technology Officer, Microsoft is significantly re-focusing its vision on Web services to counter threats from the likes of Google and Yahoo. Microsoft's announcement in November 2005 of two new Web services Windows Live and Office Live represents a shift in the company's strategy. 3.2.1.2 IBM: IBM claims that its proven portfolio offers the broadest support for enterprise-ready Web services in the industry today. There is no denying that IBM continues to be a leader in Web Services, primarily through its involvement in driving standards. IBM is the founding member of many Web services standards such as SOAP and UDDI.

42

IBMs good understanding of business issues and the business angle to Web services is providing much of the industry vision for how this technology will be adopted and how it will affect businesses. The company's strength in middleware such as WebSphere, Tivoli gives IBM opportunities to leverage its position in Web services through its major strategic offerings. Analysts consensus is that IBM's strategy targets businesses; and there is little articulated targeting of consumers. The companys focus on complex business and technology problems means IBM will often be the vendor of choice for projects that display those characteristics, rather than for many of the initial simpler Web services projects that enterprises are just beginning.

3.2.1.3 Sun Microsystems: Sun Microsystems the company that brought Java to the world faces high expectation or continued visionary leadership from the IT industry regarding Web services. However, its Web services strategy has been criticized for its Java-centric nature. In fact, Gartner analysis points out that Sun's major challenges are in part the result of the focus on Java development, in that its products are more programmer-centric than others. Jonathan Schwartz, President and Chief Operating Officer, in a Cnet News interview response to whether Sun is trying to get in front of the train in Web services (Shankland, 2002), remarks that They're all written to Java. Nonetheless, it has demonstrated stewardship in identity based Web services projects such as Liberty Alliance for identity management to establish a universal online authentication system. 3.2.1.4 Oracle: Given its acquisition of PeopleSoft Corp. and Siebel Systems, Oracle leverages its position of strength in business applications and infrastructure and extends it to Web services. It is second only to SAP in terms of business application software maker.

43

Gartner analysis points out that Oracle has shown slightly greater execution than vision in its Web services strategy. The company announced direct support for XML in its Oracle 9i Database in June 2001. Later, the company introduced new Web services

functionality for its application server and database. Gartner believes that Oracle also has another opportunity to display its vision: Thus far, most Web services vendors have focused on infrastructure. Because Oracle is also a large application provider, it could provide leadership by exposing its Oracle Applications suite of products as Web Services.

3.3 Web Services Adoption

Web services are maturing, and enterprises that were too risk-averse, conservative or otherwise uninterested in experimenting with the technology can now expect to engage Web services more strategically (Andrews & Hotle, 2003). There seems to be a general industry move towards the adoption of software-based service components in Web services (Wainewright, 2002). But how many of business users are actually weighing their options to adopt Web services? How many global executives have familiarity with Web services concept? An Accenture Web Services Global Survey (Accenture, 2003) gives us a summary of executives familiarity with Web services. 89 percent are either very or somewhat familiar with the concept of Web services. 79 percent are currently evaluating Web services. 76 percent ranked Web services as either a high or medium priority. The survey revealed that over half (52 percent) of 262 C-level (CIO, COO, CEO, CFO) executives surveyed in the US, the UK, France, Germany, Italy and Spain look at Web services as a realistic possibility todaysomething gaining acceptance within progressive IT departments. Commissioned by Accenture, the survey included 262

44

executives in the US, the UK, France, Germany, Italy and Spain. Most respondents (75 percent) were CIOs, though CEOs (7 percent), CFOs (9 percent) and COOs (9 percent). Accenture believes that the survey was fairly evenly distributed across industries, including utilities, chemicals, energy, government, banking, insurance, communications, media, retail and industrial products and transportation. However, every organization needs to assess its own readiness and the readiness of its strategic platforms and tools vendors, before it can fully commit to its implementation. Sandra Rogers, program director for SOA, Web Services, and Integration research at IDC, in a 2005 study opines, "The confluence of available technology, skills, and reference use cases is needed and will take time to evolve. Users and vendors alike must acknowledge and support an environment that allows for phased change versus 'big bang' or holistic architectural overhaul activities (Rogers, 2005). Therefore, realistic expectations are warranted regarding the adoption of Web services. Authors Eric Marks and Mark Werrell of Executive's Guide to Web Services argue that there are four phases of Web services adoption.

45

Figure 15: Phases of Web Service Adoption (Marks & Werell, 2003)

Marks and Werrell point out that first phase of Web services adoption will begin with internal system integration projects. The need for internal integration derives from the myriad of information silos created by proprietary enterprise applications implemented to support activities such as financial management (general ledger, accounts payable, accounts receivable), costing systems, order management, procurement, and production scheduling (Marks & Werell, 2003). The integration phase will prepare organizations for the next phase, collaboration. The lessons learned from applying Web services internally to systems integration and enterprise application integration problems will be leveraged for the benefit of external trading partners in the collaboration phase of Web services adoption. Maturation in the collaboration phase of Web services adoption will prepare organizations for the next phase, innovation. Firms will leverage what has been learned from internal integration projects and from collaboration projects with outside customers,

46

partners, and suppliers and be able to turn these lessons into new business processes and new sources of competitive advantage. They will use Web services as an innovation platform to drive new levels of business performance along multiple dimensions of their value chains. Citibank is a good example of how an enterprise can use Web services to spur new ways of doing business by exposing its existing capabilities and by making them available as enabling services. Citibank uses Web Services to expose its payment-processing engine that had previously only been accessible within the bank. The capabilities of this payment-processing engine are now available to other companies through a Web service interface (Hagel III & Brown, 2002). The domination phase will be the culmination of the previous three phases: integration, collaboration, and innovation. Dominance will be established by a few organizations in each industry that realized the potential of Web services, both in changing internally the ways in which organizations can operate and outperform their competition using their information technology capabilities (Marks & Werrell, 2003). In summary, the adoption of Web services will have to fit the stage and timing of the companys strategic goals. Eric Mark, in his article Other Voices: Tire Kicking and Web Services, said it best: Web services are a business decision first, followed by the technology decisions. (Marks, 2003)

3.4 Value Proposition of Web Services

Do Web services offer any business value? How about its potential return on the investment? In fact, Web services can potentially offer a significant value to business organizations by providing an opportunity to leverage existing technology investments, and to simplify their integration across the boundaries of the firm (Mooney & Kraemer, 2002). In its analysis titled IBM and the Strategic Potential of Web Services, IDC

47

concluded that On average, major benefits projected over three years include a reduction on costs of $39.7 million on an investment of $1.8 million, 22% faster time to deployment of key new applications, and increase of 47% in developer efficiency (Hailstone & Perry, 2002). The study was based on in-depth interviews with 7 IBM customers that have or are currently in the early adoption stage of Web Services.

Some of the business benefits of Web services are outlined below: o Business process automation

o The Business Process Execution Language for Web Services provides a

comprehensive business process automation framework that allows companies to leverage the power and benefits of the Web Services Architecture to create and automate business transactions.

o Flexibility in the integration o Due to its reliance on open standards, Web services make it easier to
dynamically integrate disparate systems. Easing the integration of the companies systems with the suppliers, partners, and customers systems, Web services make the relationships more flexible and agile, allowing them to strengthen the existing ones and create opportunities for the establishment of new ones (Vita, 2004).

o Faster response to shifting markets o Business requirements change, mergers and acquisitions occur
frequently, and partnerships change. In order to be agile, there is a need to react faster to those external business changes. With Web services, enterprises can reconfigure business processes in real time.

Manufacturing business, for example, can decrease time to market its

48

products if its business relation with one of its suppliers is terminated and a new supplier takes it role. o Economic value o Web services reduce the dependence on proprietary systems and the need for one-to-one integration. Thus, IT managers wont be burdened by relatively higher cost of integration by reducing cost of acquisitions, maintenance and development of solutions (Vita, 2004). o Reduced cost of change

o Because of its plug and play nature, Web services can help pull together
various services needed to complete a business process. As such, any cost related to change in a business process will be reduced.

Aforementioned business benefits of Web services, coupled with todays IT integration dilemma, produces high expectations of Web services among business executives.

Figure 16 shows the result of an Accenture survey of higher executives. These executives were asked about the benefits their companies might expect from the adoption of Web services. When unaided by any set responses, improved efficiency, cost reduction and improved customer service were among the top responses. When the respondents were presented with set of benefits by name, the numbers jump even higher. 86% of those who were surveyed agreed that improved efficiency and speed of business processes will be top reason for adopting Web services.

49

Figure 16: Perceived Value of Web Services (Accenture, 2003)

The figure is a glimpse of what executives will be expecting from Web services. It can be inferred from the figure that among other reasons for adopting Web services, efficiency, cost reduction and better customer service are the prime factors. Similarly, in another survey (Figure 17), when IDC asked 200 executives to choose business advantages to using Web Services, once again, efficiency and customer service were on the top.

50

Drives more efficient business processes Im prove our company's custom er service Address a specific business function Reduces costs Provide return on investment Create new revenue opportunities Free up resources for other projects Enable com pliance of industry/regulatory requirement

86.5 83 82 78 70.5 61.5 62 43.5 0 20 40 60 80 100

Percentage

Figure 17: Business advantage to using Web Services (IDC, 2004)

Both figures 16 and 17 confirm that executives need to derive efficiency in business processes and improve customer services through technology. We can deduce from the results of these figures that executives plan to leverage Web services technology to optimize their business processes and achieve greater business benefits.

It should be noted that in Figure 17, about 70.5% of respondents considered return on investment as business advantage to using Web services. Calculating return on investment for Web services can be overwhelming and we need to consider many factors in the calculation (Clark et. al, 2002). According to Gunjan Samtani, one should consider factors three key factors (Samtani, 2002):

costs and expenses such as hardware, software, training, and network bandwidth requirements,

51

technical benefits such as software development automation, usage of standards based integration, streamlining of middleware technologies

business benefits such as end user productivity, collaborative business activities, better customer service.

Despite potential benefits that can be gained from implementing Web services, there still are some challenges to be overcome.

3.5 Challenges
In this section we examine these challenges and look at open issues. Listed below are some of the barriers that need to be overcome.
3.5.1 Technical barrier to success

3.5.1.1 Standards: Development of Web services technology is still a work in progress. As a result, some standards are still new and not fully tested. Many vendors are trying to promote competing standards that are incompatible with each other. The multiple overlapping specifications, standards bodies, and vendor strategies tend to obscure the business needs. Such unfortunate events lead to the failure of delivering on the very promise Web service is trying to achieve interoperability. If the industry as a whole cannot move to a common set of standards and set aside their differences, the survival of Web services could be in great jeopardy. Over the past years, Gartner analysts have advised enterprises to approach Web services cautiously in general because Web services remain fairly nascent, and deployments should reflect the caution (Andrews, 2002).

52

3.5.1.2 Security: Aside from the issues inherent in an emerging technology, a general lack of experience and understanding in exactly how to deal with Web services security persists. It is a fact that, in Web services as well as in other areas in general, companies face the trade-off between flexibility and security and stability. Whenever financial and business data processing is concerned, security and privacy issues always remain top priorities. Meeting those security requirements for privacy, confidentiality, proof of origin and integrity is essential. However, smaller companies feel that many standards, such as WS-Security, aren't ready to address the security concerns associated with external integration (Bharti, 2005). According to the CIO magazine, Web services adds an extra dose of complexity to a company's IS strategy because there are no agreed-on standards for authenticating users controlling access to Web services applications that are accessed from outside the corporate firewall (Varon, 2003).

3.5.2 Market barrier to success

3.5.2.1 Rate of adoption: Another roadblock to its adoption is the tendency for companies to gravitate to familiar technologies (Bednarz, 2005). In a recent survey (Table 4) of almost 1,000 developers and managers representing a wide variety of business sizes and industries, only 9% have fully deployed Web services and more than half (55%) are still not certain about its deployment. It gives us a clear message that the rate of adoption of Web services is still lethargic at best.

53

In development Deployed, but not rigorously shared between business units Deployed and shared between business units Deployed, shared, managed, governed and align with business Other Table 4: Stages of Web Services and SOA strategy (Adam, 2005)

55% 20% 13% 9% 4%

3.5.2.2 Return on investment: Another reason that enterprises give for waiting is that it is difficult to measure ROI for any new technology. If no business value is created and if there is no competitive advantage in deploying Web services, the adoption of Web services will come to a halt. Because this technology is very nascent, we havent seen return on its investment that exceeds the cost of implementing it. Inherent with any technological investment,

enterprises are finding it harder to strategically align technology with business objectives. In so far as Web services goes, many are finding enterprise-level ROI largely theoretical.

54

4.0 Chapter 4: The End Is Only the Beginning

4.1 Limitation and Opportunities in research
Web services provide many research opportunities; therefore further research will be informative to those interested in deploying Web services and those who are trying to comprehend the strategic business value of this technology. Due to the scope of this paper, it may leave out many aspects of Web services that would be helpful to some readers.

4.2 Recommendation and Conclusion

The first chapter of this paper presented basic technological and conceptual elements that constitute Web services. Chapter 2 illustrated two parallel experimentations with Google Web services to demonstrate loose coupling and platform independence. Two client applications were developed using J2EE and PHP respectively. The results confirmed that both of the development environments are adequate for invoking Google Web services. Chapter 3 elaborated on the market dynamics and business value provided by Web services. We identified and discussed some of the challenges faced by the current state of Web services.

In this paper, we have presented the conceptual elements of Web services, demonstrated an instance of loose coupling of applications and provided an analytic study on current market trends and industry assessment of Web services.

What we have found is that it is important for business leaders to keep a close eye on this emerging technology and make decisions which support service oriented architecture. For example, any new IT related purchases can include products which embrace and extend standardized Web services capabilities.

55

IT decision makers should consider the decision to service-enable their business processes or to adopt SOA as an opportunity in order to further improve and align business needs and technology. However, before any decision on Web services or SOA is made, business leaders need to review internal business processes and seek an unbiased opinion of their own enterprise systems. Any justification to service enable applications requires a business rationale. A good business leader should therefore be able to ask tough questions on SOA and Web services and to outline strategic and long term business plans. Some of the questions to ask can be (Tomlinson, 2005):

Do you want to interact more with your business partners? Is there a requirement to link internal stovepipe applications/packages? Do you want to make legacy assets available for reuse? Are you looking for a more flexible IT architecture that can easily adapt to change? (agility / competitiveness / responsiveness)

Is your system environment heterogeneous?

A yes answer to any of those questions can signal that it is a time to consider Web services. To those who want to implement Web services in their enterprise systems, starting small will be the most effective way. Business and IT leaders should know that effective use of Web services requires experience and understanding of the trade-offs. By starting small and incrementally service enabling business processes, success can be achieved.

56

How to get started? Some companies would find it a strategically advantageous to initially implement Web services within its firewall for internal integration purposes. They focus on non-mission critical applications which dont require high level of security. By taking such an approach to Web services adoption, they can initially evaluate the impact of Web services on existing IT environment -- without committing too many resources. However, if a business leader can identify potential new business opportunities where Web services can generate new revenue streams, they should be the first ones to adopt it. John Hagel, who is a consultant and has published many IT strategy and management related articles in Harvard Business Review, McKinsey Quarterly, CIO and the Wall Street Journal5, shares some of his views with Wendy Guild in HBS Working Knowledge. He points out that the goal is to discover the business operations where significant inefficiencies occur and where Web services may be ideally suited to target those inefficiencies today (Guild, 2002). We agree with Johns point and believe that IT decision makers should use Web services as a tool to reduce those inefficiencies and satisfy greater business needs.

For some businesses, such as those in manufacturing, it is a good idea to start at the connecting points of business partners such as suppliers, distributors or customers. Enterprises business partners may have implemented their IT systems in environments such SAP, Oracle or Sybase. Such an amalgamation of systems can lead to integration problems. Thus, by service-enabling the edge of an enterprise system, where application integration occurs more frequently, business leaders can leverage the benefits of Web services (Hagel III, 2002).

www.johnhagel.com

57

Not all processes and applications, however, are suitable for Web service and SOA. A business leader should target the right projects and consider alternate ones whenever better solutions exist. Zeroing in on specific business needs can help companies make decisions about how much of their existing applications to service-enable. In addition, Web services need not be a replacement strategy, which substitute existing and legacy portfolios. There is a place for both to complement each other.

It is critical to note that any basis of adopting Web services is grounded on the idea that federated principals of corporate governance is in place and business leaders have good understanding of the business and IT infrastructure. While we should not underestimate the importance of Web services, which are fostering collaboration and boosting productivity, we should not overestimate their impact on the business world either (McAfee, 2005). Web services should not be taken as quick fix solution to enterprise integration problem, but a strategic investment to achieve competitive edge for process change. We believe that Web services promise a robust and reliable integration technology and the benefits of Web services can be substantial; however, its success depends on how effectively Web services are managed and handled.

58

References:
Abrams, Charles and Sholler, Daniel.Power Players Propose Web Services Transaction Standards, Gartner Research Note, September 2005 Adam, Collin. From Web Services to SOA and Everything in Between: The Journey Begins, http://81.29.72.192/ws/content/view/full/63405 (accessed on Oct 15th, 2005), May 2005 Andrews, Whit. Amazon Offers Free Web Services to Help Drive Site Traffic, Gartner Research Note, July 2002 Andrews, Whit. Users Follow Four Es to Web Services Benefits, Gartner Research Note, May 2003 Andrews, W. and Hotle, M. How Web Services Provide ROI, Gartner Research Note, May 2003 Asaduzzaman, Ahm. Create Your Own Search Engine with PHP and Google Web Services, http://www.devarticles.com/c/a/PHP/Create-Your-Own-Search-Engine-with-PHP-and-Google-Web-Services/, 2003 BPEL4WS, http://www-106.ibm.com/developerworks/webservices/library/ws-bpel/ Bednarz, Ann. SOA: Here's the real skinny, What works and why, Network World, November 28, 2005 Bharti, Nitin. Enthusiasm, caution guide SOA adoption, TechTarget Inc.,19 April 2005 Blank, Jonahan. SOA Number One Priority for IT Infrastructure Investment, Capgemini Pulse Survey, Capgemini U.S. LLC, September 2005 Chatterjee, S., and Webber, J. Developing Enterprise Web Services and Applications: An Architect's Guide, Prentice Hall, ISBN: 0-13-140160-2, 2004 Clark, M., Fletcher, P., Hanson, J., Irani, R., Waterhouse, M. and Thelin, J. Web Services Business Strategies and Architectures, Wrox Press, August, ISBN: 1904284132, 2002 Enterprise Data Integration - Challenges and Solutions in the Integration of Data in the Large Enterprise, Sapient Analysis, 2004 Evers, Joris. OASIS approves WS-Security Web services spec, IDG News, http://www.infoworld.com/article/04/04/08/HNoasisspec_1.html, accessed on Dec 5th, 2005, April 2004 Francisco Curbera et al., "Unraveling the Web Services Web," IEEE Internet Computing, ACM, 2002 Gosnell, Denise M. Professional Development with Web APIs: Google, eBay, Amazon.com, MapPoint, FedEx, Wrox Press, ISBN 0764584456, 2005 Guild, Wendy. Using Web Services to Tame Technology, HBS Working Knowledge, http://hbswk.hbs.edu/item.jhtml? id=3195&t=technology&noseek=one (accessed Oct 20th, 2005), 2002 Gustavo Alonso, Fabio Casati, Harumi Kuno, Vijay Machiraju, Web Services, Springer; 1 edition, ISBN 3540440089, 2003 Hagel III, J., 'Edging into Web Services', McKinsey Quarterly Reader on The Strategic Value of Web Services, Number 4, pp. 5-13., 2002 Hagel III, J. and Brown, J.S., Service Grids: The Missing Link in Web Services, pp 11, http://www.johnhagel.com/paper_servicegrid.pdf, 2002 Hailstone, R., and Perry, R. IBM and the Strategic Potential of Web Services Assessing the Customer Experience, White Paper, IBM, 2002 Hayward, S. "Positions 2005: Service-Oriented Architecture Adds Flexibility to Business Processes," Gartner, Inc., Feb. 2005 Heffner, Randy. Large Enterprises Pursue Strategic SOA Medium Enterprises Are Close Behind; Small Enterprises Are Coming On Strong, Document Excerpt, Forrester Research, April 2005 IBM, http://www.research.ibm.com, Johnston, D. Britton. An Introduction to Web Services Enabled with PHP, NuSphere Corporation White Paper, January 2002

59

Kim, J. B., Segev, A. Patankar, A., and Cho, M. G. Web Services and BPEL4WS for Dynamic eBusiness Negotiation Processes, International Conference on Web Services 03, Las Vegas, 2003 Kreger, Heather. Web Services Conceptual Architecture white paper (WSCA 1.0), IBM, May 2001 Lawler, et al (2005). A Study Of Web Services Strategy In The Financial Services industry, Information Systems Education Journal, 3 (3), http://isedj.org/3/3/ ISSN: 1545-679X. (Also appears in The Proceedings of ISECON 2004: 3443. ISSN: 1542-7382.) Lewin, Dan'l. PressPass Executive Q&A on WS-I, Microsoft PressPass, http://www.microsoft.com/presspass/features/2002/feb02/02-06ws-i.asp, Feb. 6, 2002 Magic Quadrant for Web Service Platforms, 2005, Gartner Research Analysis, 2005 Manes, Anne Thomas. Web Services: A Manager's Guide, Addison-Wesley Professional; 1st edition, ISBN 0321185773, 2003 Marks, Eric. Other Voices: Tire Kicking and Web Services, Information Week, http://www.informationweek.com/story/showArticle.jhtml?articleID=12803018 (accessed on Oct. 11, 2005) July 2003 Marks, Eric A. & Werrell, Mark J. Executive's Guide to Web Services, Wiley; 1 edition, ISBN 0471266523, 2003 McAfee, A. Will Web Services Really Transform Collaboration?, MIT Sloan Management Review, Vol. 46 #2, 2005 McCarthy, Deirdre. Web Services As a tool for Enterprise Application Integration, Mooney, John & Kraemer, Ken. The Promise and Peril of Web Services: Strategic and IT Flexibility through Loose Coupling?, A project proposal to the Industrial Advisory Board of the UCI NSF Industry/University Cooperative Research Center, Center for Research on IT and Organizations (CRITO) University of California Irvine Myerson, Judith M. Web Services Architectures, Tect Ltd. Radcliffe, J. "Integrate Your Data to Create a Single Customer View", Gartner Research Note, October 2, 2004 Radicati, Sara. An in-depth look at the emerging market for web services technology, The Radicati Group, Inc, September 2004. Rist, Oliver. Steps to SOA No. 7: Lay your security plans, InfoWorld, http://www.computerworld.com.au/index.php/id;339099954;fp;16;fpid;0, accessed on December 6th, 2005, September 2005 Rogers, Sandra. Worldwide Web Services Software 2005-2009 Forecast: Let the Races Begin, IDC Market Analysis Highlight. 2005. Samtani, Gunjan and Sadhwani, Dimple. Web Services and Application Frameworks, Tect Ltd., ISBN B0000666HL, 2002 Shankland, Stephen. Can software pull Sun out of its funk? Cnet News.com, http://news.com.com/2008-1082947510.html?tag=fd_lede, accessed on Sept. 21, 2005, August 1, 2002 Smith, D., Andrews, W., Abrams, C. "Predicts 2004: Advanced Web Services Gain Traction", Gartner Research Note, November 19, 2003. Spek, Alexander W. A., Designing Web Services in a Business Context: A Transformation from Conceptual Processes to Web Services, Masters Thesis, Universiteit van Tilburg. Thompson, Sam. Implementing WS-Security, IBM developerWorks, http://www128.ibm.com/developerworks/webservices/library/ws-security.html, accessed on Dec 5th, 2005, Dec 2003 Tomlinson, Mark, and Zimmermann, Olaf. Building Service-Oriented Architectures with Web Services, Tutorial, http://www.perspectivesonwebservices.de/download/t48-tomlinson-zimmermann-finalExt.ppt, IBM, 2005 UDDI, http://www.uddi.org Varon, Elana. The Early Adopters, CIO Magazine, Oct. 1, 2003 Vita, Paulo Guilherme. Challenges in the Adoption and Diffusion of Web Services in Financial Institutions, Working Paper, Alfred P. Sloan School of Management, Massachusetts Institute of Technology, June 2004. Vlachakis, J., Rex, S., Otto, B., Lebender, M. and Fleckstein, T. Web Services - A Look into Quality and Security Aspects, European Commission, 2003

60

Wahli, U., Tomlinson, M., Zimmermann, O., Deruyck, W., and Hendriks, D. Web Services Wizardry with WebSphere Studio Application Developer, IBM, 2001 Wainewright, Phil. Web Services Infrastructure The global utility for real-time business, First published February 2002, updated October 2002 White, Colin. 'Data Integration: Using ETL, EAI, and EII Tools to Create an Integrated Enterprise, The Data Warehousing Institute. 2005. Why is Everyone Talking about Web Services? Accenture Web Services Global Survey, Accenture, 2003. WSDL, http://www.w3.org/TR/wsdl.html

61