You are on page 1of 4

A.S. Chaudhary, M.A. Saleem, H.Z.

Bukhari: Web Services in Distributed Applications

Web Services in Distributed Applications Advantages and Problems


A. S. Chaudhary1, M. A. Saleem2, H. Z. Bukhari3 Ghulam Ishaq Khan Institute of Engineering Sciences and Technology, Topi, District Swabi, NWFP, Pakistan 1 u990015@giki.edu.pk 2 u990071@giki.edu.pk 3 u990053@giki.edu.pk
Abstract: A Web Service is a programmable entity that provides a particular element of functionality, such as application logic, and is accessible to any number of potentially disparate systems through the use of Internet standards, such as XML and HTTP. Web services provide a viable solution for enabling data and system interoperability. They utilize XML-based messaging as a fundamental means of data communication to help bridge the differences that exist between systems that use incongruent component models, operating systems, and programming languages. The aim of this paper is to explore what web services are, how they are shaping distributed application development, and the advantages they offer over existing technologies. The paper also looks at the problems currently being faced by the web service developers and investigates the various methods being tried to address these problems. These problems include transaction management, security, and web service discovery problems. Key words: Web Service, Distributed Computing, Service-Oriented Architecture, SOAP, XML

1. Introduction
1.1. Problems with Traditional Distributed Architectures Traditional distributed architectures incorporate relatively brittle coupling between various components in the system. Such systems are quite sensitive to change. As the scale, demand, volume, and rate of business change increase, any significant change in any of these aspects will cause the brittleness of these systems to become a crisis: unavailable or unresponsive Web sites, lack of speed to market, inability to rapidly shift to new business opportunities or competitive threats. Such systems will not be able to cope with changes because of the high coupling; dynamics of the Web makes management of these brittle architectures untenable. Hence there is a growing realization to replace the current models of application design with a more flexible architecture, yielding systems that are more amenable to change. 1.2. Definition and Overview of Web Services Web Services are that new breed of Web applications envisioned to create the next generation of distributed applications. A Web Service is programmable application logic accessible using standard Internet protocols, having a collection of functions that are packaged as a single entity and published to the network for use by other programs. Web Services can be accessed by any language, using any component model, running on any operating system. They

utilize the Hypertext Transfer Protocol (HTTP) as the underlying transport, which allows function requests to pass through firewalls. Extensible Markup Language (XML) is used to format the input and output parameters of the request, so the request is not tied to any particular component technology or object calling convention. Web Services are building blocks for creating open distributed systems, and allow companies and individuals to quickly and cheaply make their digital assets available worldwide. Web Services perform functions that can be anything from simple requests to complicated business processes. A sample Web Service might provide stock quotes or process credit card transactions. One early example is Microsoft Passport, a convenient authentication Service hosted by Microsoft. 1.3. How a Web Service Works? The most fundamental principle underlying Web Services is the service-oriented architecture (SOA). An SOA focuses on how service components are described and organized to support dynamic, automated discovery and use [1]. Several essential activities need to happen in any serviceoriented environment: a. A Web Service needs to be created, and its interfaces and invocation methods must be defined.

A.S. Chaudhary, M.A. Saleem, H.Z. Bukhari: Web Services in Distributed Applications b. c. d. e. A Web Service needs to be published to one or more intranet or Internet repositories for potential users to locate. A Web Service needs to be located in order to be invoked by potential users. A Web Service needs to be invoked to be of any benefit. A Web Service needs to be unpublished when it is no longer available or needed. fundamental concepts in Web Services are encapsulation, message passing, dynamic binding, and service description and discovery. Fundamental to Web Services is the notion that everything is a Service, publishing an API for use by other services on the network and encapsulating implementation details. Applications of the future will be built from Web Services that are dynamically selected at runtime based on their cost, quality and availability.

Components in an SOA fill one or more of three roles [2]. A service provider publishes the availability of its services and responds to requests to use its services. A service broker registers and categorizes published service providers and offers search services. A service requester uses service brokers to find a needed service and then employs that service. This is shown in Figure 1. Service Provider
Bind Publish

2. Discussion
2.1. Advantages Web Services are pretty much guaranteed to be at the heart of the next generation of distributed systems for reasons highlighted below: 2.1.1. Interoperability Unlike current component technologies, Web Services are not accessed via object-model-specific protocols, such as the distributed Component Object Model (DCOM), Remote Method Invocation (RMI), or Internet Inter-ORB Protocol (IIOP). Instead, Web Services are accessed via ubiquitous Web protocols and data formats, such as HTTP and XML. The Simple Object Access Protocol (SOAP), based on XML, defines a lightweight protocol for information exchange in Web Services. Any Web Service can interact with any other Web Service using SOAP. A Web Service interface is defined strictly in terms of the messages the Web Service accepts and generates. Consumers of the Web Service can be implemented on any platform in any programming language, as long as they can create and consume the messages defined for the Web Service interface. Due to this developers do not need to change their development environments in order to produce or use Web Services. 2.1.2. Ubiquity Web Services communicate using HTTP and XML. Therefore any device which supports these technologies can both host and access Web Services. It is only a matter of time before these become available in our phones, cars, toasters, fridges and even coke machines. If the coke supply is getting low, the wireless-networked coke machine can contact the suppliers Web Service and order more. 2.1.3. Just-In-Time Integration Collaborations in Web Services are bound dynamically at runtime. Dynamic Service discovery, invocation (publish, find and bind) and message-oriented collaboration yield applications with looser coupling, enabling just-in-time integration of new applications and services. This in turn yields systems that are self-configuring, adaptive and robust with fewer single points of failures [4].

Service Broker
Find

Service Requester

Figure 1. Service-Oriented Architecture Three basic operations are used among the three roles. The publish operation allows a service provider to register its abilities and interface requirements with a service broker. The find operation allows a service requester to find services of a particular classification published via a service broker. The bind operation allows a service requester to actually use a service provider. 1.4. Significance of Web Services The Web Services technology promises to be both an evolutionary and revolutionary step forward in the domain of distributed computing; evolutionary because Web Services are the next step in abstraction beyond object-oriented technology, and revolutionary because they will catalyze a shift from the traditional client-server architectures to peer-topeer architectures [3]. Web Services combine the best aspects of component-based development and object oriented approach, geared towards the architecture, design, implementation and deployment of e-business solutions. Like components, Web Services represent black-box functionality that can be reused without worrying about how the Service is implemented. Like object-oriented systems, some of the

A.S. Chaudhary, M.A. Saleem, H.Z. Bukhari: Web Services in Distributed Applications messages being sent by service requesters and service providers. Reliability of Web Services is hampered by the fact that they use HTTP. HTTP is a best effort delivery service [1]. There is no guarantee of packets being delivered to the destination nor of the order of the arriving packets. To overcome this, newly designed protocols like Reliable HTTP (HTTPR), Blocks Extensible Exchange Protocol (BEEP) and Direct Internet Message Encapsulation (DIME) can be used. However, wide spread adoption of these protocols will take some time. Reliability can also be improved by using message queuing but at the cost of response time. 2.2.3. Security Some Web Services will be publicly available and unsecured, but most business-related Services will use encrypted communications with authentication. How does a Web Service authenticate users? The user authentication can be accomplished by requiring that web services to be invoked over the HTTPS protocol using Secure Socket Layer (SSL). Digital signatures can also be used to provide authentication. 2.2.4. Transactions Traditional transaction systems use a two-phase commit approach all of the participating resources are gathered and locked until the entire transaction can take place, at which point, the resources are finally released. This approach works fine in a closed environment where transactions are shortlived, but does not work well in an open environment where transactions can span hours or even days. Should this kind of transaction be integrated into Web Services? Even though it is possible to use two-phase commit transactions in web services, care should be taken to make sure that resources are not locked for long periods of time. There are other less than optimal solutions to the problem of transactions. For example, the OASIS Business Transaction technical committee has released the Business Transaction Protocol (BTP) which extends the two-phase commit method to address the needs of web services. BTP allows both Atomic, Consistent, Isolated and Durable (ACID) transactions and non-ACID transactions (termed as cohesions) for long lasting transactions that span multiple enterprises [5]. Another alternative to two-phase commit is called compensation. It is based on the idea that a transaction is always allowed to commit, but its effect and actions can be cancelled after it has committed [6]. For example, it may be possible to order a shipment, and then later cancel the shipment if the required shipment process has not yet started. Canceling the shipment is an example of a compensating transaction; it compensates for the initial transaction that

2.1.4. Extension of Legacy Applications It is relatively straightforward to take a legacy application, generate a SOAP wrapper and cast the application as a Web Service. By allowing legacy applications to be exposed as Web Services, a new level of interoperability between these applications can be achieved. This would allow these dying legacy applications to be used in interesting new ways. 2.1.5. Easy Learning Curve The concepts behind Web Services are easy to understand. Web Services reduce complexity through encapsulation. Service requesters and providers concern themselves with the interfaces necessary to interact with each other. As a result, a service requester has no idea how a service provider implements its service, and a service provider has no idea how a service requester uses its service. Those details are encapsulated inside the requesters and providers. The encapsulation provides a means for reducing complexity. 2.1.6. Industry Support Free toolkits from vendors like IBM, Microsoft and Sun Microsystems allow developers to quickly create and deploy Web Services. In addition existing COM components and JavaBeans can be easily exposed as Web Services. 2.2. Challenges and Problems For Web Services to succeed there are many technical challenges that have to be met, many of which are related to the open, hostile environment in which they must operate. Given below are some of the problems being faced by people in the Web Service industry and different ways in which they are trying to overcome them: 2.2.1. Discovery A Web Service must have a mechanism to advertise itself for discovery by other Web Services. What happens if the Service changes or moves after it has been advertised? This is no longer a problem since the industry has agreed upon a standard called Universal Description, Discovery and Integration (UDDI). UDDI is a repository of Web Services where Web Service publishers publish their Web Services along with the locations where these are present. If the location of a Web Service changes, it will be reflected in the UDDI repository. If a Web Service is changed in such a way that new functionality is added to the Web Service leaving the previous functionality unchanged, the existing applications relying on the Web Service will continue to operate normally. 2.2.2. Reliability The number of failures per month or year represents the measure of reliability of a Web Service. In another sense, reliability refers to the assured and ordered delivery of

A.S. Chaudhary, M.A. Saleem, H.Z. Bukhari: Web Services in Distributed Applications ordered the transaction. In compensating transaction, each real transaction has an associated compensating transaction. This compensating transaction element describes a way to revert changes done by the real transaction and return to a previous consistent state. If any transaction aborts the caller executes the corresponding compensating transaction for all the transactions that have previously committed. Problems associated with compensating transactions are: a) b) They may not satisfy all four ACID properties at all times i.e. there is always probability for a failure. Traditionally designed two-phase commit transactions have to be re-designed to provide way for compensation. (SAX) based SOAP implementations can be used to increase throughput and reduce memory overhead. 2.2.7. Pricing Model Commercial Web Services would require a charging model, defining how long a user can access and execute a Web Service and how the user will be charged. One approach towards solving this problem would be to introduce an intermediate metering and accounting service between the requestor and the provider of the service [8]. The requestor and the provider first make an arrangement via electronically signed contracts and certificates. The contract provides details concerning the duration of use, time model to be used: i.e. everyday, weekly or monthly etc and security: signatures for encryption and authentication. The intermediate service can record all this information. This service now acts as a resource counter for the web service. It records the amount of time the requestor uses the service and calculates the bill according to the terms in the contract.

2.2.5. Scalability Scalability is the capability to increase resources to yield a linear (ideally) increase in service capacity. The key characteristic of a scalable application is that additional load only requires additional resources rather than extensive modification of the application itself. Since it is possible to expose existing component systems like Enterprise JavaBeans as Web Services, it should be possible to leverage the load-balancing and other scalability mechanisms that already exist. 2.2.6. Performance Performance of a Web Service is measured in terms of throughput and latency. Throughout represents the number of Web Service requests served in a given time period. Latency is the round-trip time between sending a request and receiving the response. SOAP is the de facto protocol for Web Services and SOAP performance is degraded because of the following [7]: a. b. c. d. e. SOAP uses XML instead of binary data which makes the size of the data almost 400% larger. Extracting the SOAP envelop from the SOAP packet is time-expensive. Parsing the XML information in the SOAP envelop is time-expensive. Encoding binary data in a form acceptable to XML is time-expensive. XML parsers support a number of features which makes them resource intensive. Not all of these features may be used by SOAP.

2.

Web Services is the next stage of evolution for distributed applications. They offer numerous advantages over traditional technologies but like any other new technology they bring a few problems of their own. In spite of this the future seems promising as these problems are slowly but steadily being overcome.

Conclusion

3.
1.

References
Greg Flurry. January 2001. Applying web services to the Application service provider environment: An example of web services applied to e-business. IBM DeveloperWorks. Ibid. Karl Gottschalk. September 2000. Web Services Architecture Overview: The next stage of evolution for ebusiness. IBM DeveloperWorks. Graham Glass. November 2000. The Web Services (r)evolution: Applying Web Services to applications. IBM DeveloperWorks. Anbazhagan Mani and Arun Nagarajan. January 2002. Understanding Quality of service for Web Services. IBM DeveloperWorks. Ibid. Ibid. Dietmar Kuebler and Wolfgang Eibach. July 2001. Metering and accounting for Web Services. IBM DeveloperWorks.

2. 3. 4. 5. 6. 7. 8.

Some applications can consider compressing XML when CPU overhead required for compression is less than the network latency. They can also consider using stripped-down versions of XML parsers which have a small code size and memory footprint. Most of the current SOAP implementations are Document Object Model (DOM) based. DOM parsers are inherently slow to parse the messages. Simple API for XML

You might also like