Enhancing Web Services with Message-Oriented Middleware

Enhancing Web Services with Message-Oriented Middleware Piyush Maheshwari University of New South Wales and National ICT Australia Ltd., Sydney NSW 2052, Australia e-mail: piyush@cse.unsw.edu.au Hua Tang Coin Software Pty. Ltd. Level 10, 9 Castlereagh Street, Sydney, NSW 2000, Australia e-mail: htang@coinsoftware.com.au Roger Liang CSC Australia 26 Talavera Road, Macquarie Park, NSW 2113, Australia e-mail: rliang@csc.com.au Abstract This paper outlines the design and implementation of WSMQ, which is a message-oriented middleware specifically designed to enhance the reliability of Web services. Highlights of this application feature fault tolerance of Web services communication, Quality of Services including authentication and prioritization, security enhancement and performance improvements in Web services over the existing architecture. The implementation of these features aims to address the existing issues surrounding Web services, and further its advancement towards a new standard for distributed application development. 1. Introduction A Web service is a collection of functions that are packaged as a single entity and published to the network for use by other programs. Web services are building blocks for creating open distributed systems, and allow companies and individuals to quickly and cheaply make their online services available worldwide. In a nutshell, "Web Services are self-contained, modular applications that can be described, published, located, and invoked over a network, generally, the Web [1]." Web services allow the implementation of a loosely coupled distributed computing environment. It involves various functions or 'services' to be published to a directory, accessible by others. This directory is then consulted and reference to the needed program is obtained. The required service is then executed remotely and any results passed back to the originator of the request. The concept of distributed computing was not started with Web services. Indeed there were prior attempts to succeed in this area, with such technologies as CORBA, Distributed SmallTalk, and Java RMI. However, these systems required too much tight coupling with an overhead not suitable for Business-to-Business communications [1]. In detail, the following series of steps are necessary for the use of a Web service: A service or program is made to be accessible over the Web. The nature of this service is published to a registry. This includes a summary of the services offered by the program. Another peer which is in request of the Web service consults the registry and discovers the Web service. A request is formed by the peer and sent directly to the Web service. When the request has been satisfied by the Web service, a response if any is returned to the peer who sent the request. Web services can have impact on all kinds of distributed applications, including Internet-based grid, and peer-to-peer (P2P) computing [2, 3]. The advantages to using Web services can be summarised as follows: Allows platform and software independence Runtime integration Encapsulation Many speculate that Web services will standardize distributed computing. However there are still some weaknesses that exist in their design that is preventing them from being widely deployed. Some of the main areas of weakness in Web Services are reliability, scalability, security and performance. The main objective of our research is to specify, design, and implement a customized message-oriented middleware (MOM) to enhance the value of Web services. This MOM application directly addresses some of the most critical issues surrounding the commercial deployment of Web services. In addition, it adds value to Web services by providing services that are not found in general purpose MOM applications. The rest of the paper is organized as follows. Section 2 gives a short overview of message-oriented middleware and builds the motivation for designing a message queuing system, called WSMQ, for Web services. Sections 3 and 4 present the functionality and important design decisions for WSMQ. Section 5 evaluates reliability and performance aspects of this system. Section 6 concludes the paper with discussion on further research in this area.

2. Message-Oriented Middleware For integrating distributed applications, messageoriented middleware is often seen as a solution for facilitating communication among applications [4]. MOM generally adds extra flexibility to the client/server architecture. It provides the reliable data delivery mechanisms, yet let the systems be loosely coupled not always operating at the same speed, sometimes disconnected, and not having the recipient synchronously locked until the communication was completed. MOM coordinates message traffic between distributed applications, handling all network communications so that application developers need not be concerned with the underlying transport. Hence it assists the development by providing platform and implementation independence. This is so the client and the server can have a common communications medium. There are quite a number of different MOM products available, based on different technologies (e.g., IBM MQSeries, SonicMQ, TIBCO/Rendezvous, etc.). 2.1. Message Sending Asynchronous versus Synchronous MOM is most commonly associated with asynchronous message transfer [5, 6]. Messages are held in a queue and fed through to the server at such a rate so as not to overwhelm it. The purpose of the MOM in this situation is to buffer the messages and ensure the rate of arrival does not exceed a pre-determined limit. Whilst the request is being handled, the client process is free to continue execution. MOM based on synchronous messaging is less common, as it involves blocking the sender until the response is received. This may end up being very inefficient, as the time for a request to be processed is variable and may be unpredictable. Whilst the request is being serviced, the client is in a state of inactivity. 2.2. Point-to-Point / Publish & Subscribe Point-to-Point messaging ensures that there is a unique copy of the message, and this is passed to a single recipient. Publish & Subscribe messaging is a sort of multicast, where every subscriber to a particular service will receive the same message. Point-to-Point example: Sending a request to a server for a quote. Publish & Subscribe example: Sending out stock prices to all those interested (the subscribers). 2.3. MOM and Web Services Given the nature of Web services, it seems that MOM is definitely a solution for addressing some of their issues. Under the current architecture, Web service client applications communicate with service providers directly across the Internet. Using the protocols such as SOAP, WSDL and UDDI, applications can easily communicate with each other over the Internet protocols [7]. However, this implies that in order for a service invocation to complete successfully, both the client and the server need to be online at the same time. An enterprise message queue application would relax constraint with its very typical guaranteed delivery mechanism. A popular Web service should expect to receive thousands of service requests per second. There is definitely no guarantee that a server would able to handle all the messages without losing any. A message queue application has the capability of reliably storing these messages until each of them have been processed. The fact that the Internet itself is an unreliable medium of communication further advocates the need for a reliable communication mechanism in a distributed computing environment. In this paper, we show that a MOM plays serious role in addressing these needs. 2.4. Motivation for WSMQ Although using a general-purpose message queue application for Web services communication solves some of the problems, it has its disadvantages: Web service clients and servers send SOAP messages. Therefore, the message queue application must have the mechanism to read SOAP messages and extract destination information. This could have serious impact on Web services performance. Web services need to be aware of the existence and location of the message queue application and may need to explicitly send the messages to its location. This contradicts the idea of Web service, which aims to promote loosely coupled distributed computing. Most messaging applications do not provide robust security mechanisms for messages. WS-Reliability specification [8] addresses Web services messaging issues such as delivery guarantee, duplicate message elimination, and message ordering. These features are based on extensions to SOAP, rather than being tied to the underlying transport protocol. The specification is designed to let systems interoperate reliably independent of platform and vendor. Our design of Web Services Message Queue (WSMQ), a message queue application, is based on the concept of message-oriented middleware. WSMQ aims to enhance the reliability of Web service messaging, improve the scalability of its service provision, and maintain the security of all communication, all whilst preserving the natural strength of Web services. WSMQ adds further value by providing QoS features such as prioritization of user under different schemes and Web services statistics gathering. 3. Web Services Message Queue Functionality and Features Built using pure Java, WSMQ includes a number of components which are described below. These include a simulation of Web services invocation library, messaging service component which includes a custom-made message queue implementation, a data store using PostgreSQL as well as an administration tool to configure and maintain the messaging service status.

This section focuses on the fundamental functionality of the WSMQ to improve the overall quality of Web services. This includes a break down of the system into functional components and the interaction among these components. A detailed description of the features is provided in Section 4. 3.1. Scenario Point to Point Asynchronous with Response Before digging deep into WSMQ, we identify the operational scenario that WSMQ works in. We make the assumption that each Web service request message results in a response which holds the result of the execution of Web service. We further assume that the client who issues service requests will block until the result of execution is received. Figure 1 gives a good outline of the scenario. invocation as well as information required by WSMQ queue server such as username, password, client connection details, etc. Simulation library sends message object to WSMQ queue server. At the heart of WSMQ, there exists message queues that can be statically created by system administrators, a persistent data store and a message processing unit. Whenever a Web service message enters WSMQ, it will undergo several processing phases until a valid response can be sent back to the client. These processing phases include message decryption, message backup, message classification and prioritization, message queuing, message status control, message relay and message completion. Figure 3 gives a good illustration of messaging service component of the system. Figure 1. WSMQ Event Scenario 3.2. System Functionality The overall objective of WSMQ is to improve the reliability of Web services, and at the same time improve the operation of Web services in such a way that priorities can be given to Web services under several schemes. The level of security can be chosen, performance can improve under certain circumstances and some sort of intermediate management can be exerted using some administrative tools. Of these objectives, reliability and prioritization of Web services have been given the most attention. As briefly mentioned above, WSMQ consists of several components. We examine the role of the simulation of Web service invocation library first. Figure 3. WSMQ A Functional View 1. Messages enter WSMQ through the Listener, incoming messages comes in as Java objects. 2. Message Decryption: If the message is encrypted, the message would first be decrypted by the Decryptor. 3. Message Backup: Messages are then saved to the database under a fixed scheme which includes the communication detail of the client. All incoming messages would initially be assigned a status. Figure 2. Web Services Invocation Simulation Figure 2 gives a good illustration of the role of the simulation library. Its purpose is to delay the invocation of target Web services after the message has received various messaging services from WSMQ. Instead of giving the client the responsibility of invoking the service, WSMQ has now tasks of sending and receiving SOAP messages to and from target Web services. The tasks of Web service invocation simulation library are described below: Client invokes services using the simulation library. Simulation library creates message object which contains the necessary information for real Web service Figure 4. A Functional View of the Classifier Component 4. Message Classification and Prioritization: Figure 4 shows the functions of the Classifier component. The owner of the message can be authenticated upon entry the Classifier. Once authentication is completed, the status of the message would change. Then relevant information (e.g., details of the clients) would be retrieved from the message. Finally, the message would

be prioritized under certain scheme specified at the configuration of the system. 5. Message Queuing: After being assigned a priority in the Classifier, message is forwarded to a message queue that has the corresponding priority. Each internal message queue is associated with a priority. For example, a message with priority 5 would be queued in internal queue number 5. An algorithm is in place such that messages in higher prioritized message queues are fetched more frequently than those with lower priority. 6. Message Relay: When messages leave their queue, they are ready to be sent to the target Web services. The Message Relay component executes the Web service invocation procedure for each service request message. If the target Web service is offline or unavailable somehow, then it will look up the database and attempt to find a backup Web service that provide the same service. If found, Message Relay will transfer the message to the corresponding WSMQ that manages the link to that Web service. The corresponding WSMQ could be itself or another remote WSMQ. Either way, the status of the message will be updated, and the message will have to go through the entire process again. If no backup Web services are found, the status of the message will be updated and the message itself will be suspended. Periodically, such messages are processed again until target becomes available again or the client timeout expires. 7. Message Completion: When an appropriate result is obtained from the target Web service, the status of the message will be updated for the final time. WSMQ then retrieves the communication details of the client from the database and send back the exact result from target Web service to the client application. Although, result is sent through TCP/IP, the client will not notice it and will treat it as a typical SOAP response. 4. Design Decisions Several key design decision were made throughout the development of WSMQ, which are described next. 4.1. Communication between Client and WSMQ Clients communicate with WSMQ via TCP/IP while WSMQ communicate with target Web services via SOAP. The clients however are not aware of this; in fact, the clients do not know the existence of WSMQ. Whenever a client wishes to invoke a Web service, it would invoke the relevant Web service invocation call from a given library; it assumes the library function will construct the SOAP message, send it to target Web service, wait for response from target and output the results. However, instead of constructing the SOAP service request message, the simulation library will simply create a message object that contains the Web service message as well as TCP/IP details of the client, and send it to WSMQ. When sending the result back to the client, the client s TCP/IP details would be retrieved from the database, and the response message object would be sent back to the client via TCP/IP. There are several reasons why we took this approach as using the SOAP to communicate among all parties seem to be the better alternative since it allows greater interoperability. These include: Additional information for WSMQ: TCP/IP allows the transfer of objects, this means additional information such as authentication and encryption details, and message priority can be sent from the clients to WSMQ. This information is essential for services such as security and QoS. Performance: Although one would expect the performance of Web services to deteriorate since message services incur overheads, we have in fact discovered significant improvement in performance with the addition of WSMQ to the existing architecture. This improvement is due to the substantial reduction in the creation and removal of connection threads for Web services invocation by the WSMQ. It requires WSMQ to be responsible for setting up the connection for Web service invocation, and again specific information needs encapsulated in the message object sent from the client. Simplicity: Developing a simulation of any Web service invocation library is trivial. The main purpose is to deliver the exact same message to WSMQ while adding some extra information for various purposes. In our implementation, we developed a simulation for Apache Axis library. WSMQ invokes the real Apache Axis library for the actual invocation of Web services. 4.2. Message Status A messages is assigned different status throughout its lifecycle in WSMQ to support reliability features such as guaranteed delivery, restart mechanism and clustered service. WSMQ has five different message statuses: 1. Processing: Upon entering WSMQ (from client), messages are assigned the processing status. Such messages will be decrypted, if required first, then stored in the database. Message retains this status until the actual Web service invocation is made. 2. Completed: When a response is obtained from the target Web service and successfully sent back to the client, the corresponding service request message is assigned the completed status. 3. Clustered: Whenever a Web service invocation is unsuccessful (that is, target Web service unavailable), WSMQ would attempt find an alternative (equivalent) Web service. If such a service provider is found, the exact same message would be sent to the destination queue for that Web service. At the same time, the status of message would be updated to clustered. 4. Zombie: Whenever a Web service invocation is unsuccessful and no alternative service can be found, the message would be labelled as a zombie and temporarily suspended from any processing. Periodically such messages would be collected by WSMQ, and Web service invocation reattempted.

5. Dead: Web service invocation results in receiving a valid response from the Web service, however sometimes response could not be sent back to the client (e.g., timeout or erroneous connection). Such messages are called dead. When messages obtain the status of completed, clustered or dead, no further messaging services is performed on such messages. 4.3. Web Service Status In order to avoid repeated attempts of service invocation on unavailable Web services, each Web service is assigned a status regarding its availability. Only two status available and unavailable are used, and all services are initialized to be available upon their registration to WSMQ. Upon an unsuccessful Web service invocation, the corresponding service is deemed to be unavailable. Periodically, the status of the unavailable Web services are reset to available. During this period, any attempt to invoke such service will be suspended. 4.4. Queue and Web Service Target For Web services wishing to use the messaging service of WSMQ, they must register with one or more queues. The queue in this case does not represent internal message queues running in each WSMQ, it refers to an instance of WSMQ running at any location. In order for a message to reach its target Web service, it must go through the corresponding queue for the Web service. This decision does not come without cost. In the case where a target Web service is unavailable and an alternative is found, it would probably be more efficient to invoke the alternative Web service directly. However under this scheme, the message would have to be sent to the corresponding queue of the alternative Web service, the queue would treat it as a new message and repeat the process. There are reasons why this decision is made: Consistency: Each service invocation can be tracked through its request message in the corresponding queue. Fair: Does not allow single message to consume large amount of resources by repeated invocation. This reduces the probability of starvation particularly in a system where prioritization of messages exists. Efficiency: Allow implementation of load balancing. 4.5. Message Acknowledgement All message acknowledgements in WSMQ are done implicitly through TCP/IP and SOAP communication. From the client side, if a TCP/IP connection to WSMQ is failed, a TCP error would be obtained indicating that the WSMQ is unavailable. In this case, the client has to explicitly invoke the service at a later time to complete the service. At the WSMQ, should an invocation of Web service fails, a SOAP error would be obtained, indicating that the target Web service is unavailable. WSMQ handles this situation by suspending the processing of the current message and reattempt the service invocation at a later date. This is transparent to the client. The only difference may be a slightly longer execution period. 4.6. Quality of Service (QoS) In general, different services have different time constraints. Particularly in today s commercial world, most business application has time limits on tasks. Not only is this important for efficiency purposes, but the delay of the completion of certain tasks can result in great financial loss. For example, a stock price inquiry requires the result to be delivered within a fair short period of time, otherwise investors might miss out on valuable opportunities for buying or selling shares. WSMQ implements two schemes of prioritizing Web service execution: User prioritization: A user may wish to pay more to complete its usage of a service before other users; WSMQ allows this by assigning the service request message of that user with a higher priority. Messages with higher priorities are executed more frequently. Web service prioritization: Upon registration, each Web service is assigned a priority. Under this scheme, as each service request message enters the queue server, it is prioritized according to its target Web service. Highly prioritized messages are executed more frequently. The two approaches for prioritization cannot guarantee the timely completion of certain service requests. There are many reasons for this that are beyond the control of WSMQ, for example, the unavailability of Web services, overwhelming requests for certain services, etc. The prioritization mechanism does, however, greatly improve the probability of completing highly prioritized messages within a short time. Logically, the cost of this is longer processing time for messages with lower priority. In most cases, this is not an issue as long as we can avoid starvation. 4.7. Fault Tolerance To improve the reliability of Web services, we address the possible causes for failure under the existing architecture, for example, Web service unreachable (possibly offline), overwhelming service requests causing dropped service request messages, etc. WSMQ provides fault tolerance using three different mechanisms. These include guaranteed delivery of messages, restart mechanism and clustered Web service. Guaranteed Delivery An important feature of any messaging system is the ability to guarantee delivery of messages. If a message is not delivered, the system must be able to identify the error, and try to recover from the error and redeliver the message; otherwise error notification needs to be reported to the user. To achieve guaranteed delivery in WSMQ, the implementation of message status plays an important. When a message obtains the processed status, this implies the Web service has been successfully invoked and results sent back to the client application, hence this is the optimal

status. Guaranteed delivery mechanism comes into play when a message obtains the zombie status. This usually implies that the invocation of target Web services has been unsuccessful. In this case, the following steps will be taken: 1. Processing of the message suspended temporarily. 2. Periodically, zombie messages are retrieved from the database and re-queued. 3. Messages are pulled from the message queue according to priority. 4. Web service invocations are made for each message. If valid results are obtained, send result back to the client. If the client successfully receives result, message obtains processed status, otherwise messages obtains dead status. If valid results were not obtain (indicating Web service still not available), the message retains its zombie status. 5. If message retains the zombie status over a certain period of time, it also becomes a dead message. 6. The above steps are repeated. Dead messages will not be processed any further. The causes for dead messages include timeout from client application or target Web service remain unavailable for excessive amount of time. Client application has the flexibility of choosing the timeout period for its Web service invocation, obviously the longer the timeout, the greater the probability that the service will be completed. While the traditional Web service architecture requires both the Web service requester and Web service provider to be online at the same time in order for a successfully invocation of service, the guarantee delivery mechanism in WSMQ removes this constraint by persistent storage and execution of messages. Restart Mechanism In case of failure, WSMQ has the ability to recover from error and continue processing unprocessed messages without affecting the clients. Again this capability relies heavily on the altering of message status of a message throughout its lifecycle in WSMQ. The restart mechanism combined with guaranteed delivery aims to provide a robust messaging system. We now examine how they handle faults occurring at different points of error: 1. Listener: The Listener handles the connection between client and WSMQ. Since communication between client and WSMQ is implemented using TCP/IP, delivery of message is guaranteed. However, if the Listener component is down, then clients would not be able to connect to WSMQ. In this case, no messages would be received from the clients until the clients explicit reattempt connection at a later stage. 2. Classifier: The Classifier has the responsibility of authenticating user and prioritizing messages. If Classifier is down, new incoming messages would be stored to database without processing. When the Classifier is back online again, unprocessed messages would be retrieved from the database and put through the Classifier. 3. Internal Message Queue: Similar to Classifier, Internal Message Queue does not cause any loss of data in case of failure. Messages that were waiting to be processed in the queues will simply be re-queued upon reconfiguration of internal message queues. 4. Message Relay: Similar to the Classifier, failure of the Message Relay component only causes some delay completing message processing. While Message Relay is down, no messages would be retrieved from the internal message queue. 5. Web service: If a target Web service is down, Message Relay will be unable to deliver messages to the target Web services. As a result, WSMQ will suspend delivery of messages to this service for a configured amount of time. After a specified time interval has passed, the WSMQ will attempt to redeliver the message. This cycle will continue for as long as the delivery of the message is unsuccessful and the timeout has not expired. In most cases, the failure of one component of WSMQ implies that the entire system is down. Upon restarting, the restart mechanism will ensure all unprocessed messages will be reprocessed without any data loss. The only negative effect is that Web service clients would not be able to send service requests to this particular queue. Clustered Web Services Clustered service improves the probability of Web service completion by allowing equivalent Web services to form a cluster. Hence this feature requires the collaboration of Web services which are outside the control of WSMQ. What WSMQ provides is a mechanism to prevent the failure of target Web service by replacing with a backup Web service in its cluster. When registering with WSMQ, similar Web services are assigned in a same group. The following steps are taken when a target Web service is found to be unavailable: 1. Upon receiving SOAP error message for a Web service invocation, the status of that Web service is updated to be unavailable. 2. WSMQ attempts to find a backup Web service within its group/cluster. 3. If no such Web service is found, message status is updated to be zombie, and temporarily suspended. 4. If found, the queue server of that Web service is retrieved from the database. The exact same message is sent to that queue server. In its local database, the message status is updated to clustered ; Clustered messages will not be processed any further. 5. The queue server treats this message as a new message.

5. Evaluation and Results 5.1. Reliability Evaluation To test guaranteed delivery and the general ability of WSMQ to recover from failures, we introduce faults at the common points of failures in four different scenarios, as described below. Scenario 1 - Web services down In this scenario, we disable the target Web service so that no service can be received from it by any Web service. A Web service client then invokes the Web service as normal. Without WSMQ, the Web service invocation would simply result in a SOAP error. The client would receive this error almost immediately. With WSMQ, service request is sent to the queue server first. The queue will eventually attempt to make the actual invocation. At that point, a SOAP error would be received indicating that the target Web service is unavailable. However, WSMQ will not give up this service request at that point. It will update the state of the message and reattempt the invocation at a later time. This process will continue until a successful invocation is made or the user has timed out. This test showed that with the presence of WSMQ, the Web service client and provider do not need to be online at the same time in order for a successful invocation to occur. This adds a lot of flexibility to Web service provision particularly for those services that are not time critical. Scenario 2 - WSMQ queue server down In this scenario, we shut down WSMQ queue server after it has received the client request. The Web service provider itself is available throughout the whole time. Upon restart, the queue server continues processing the unprocessed messages and try to complete all the requests. This scenario does not affect the clients if the clients invoke target Web services directly. With WSMQ, service request is sent to a queue server first. The queue server shuts down before the actual invocation is made. After some time, the queue server will be restarted. Unprocessed message from the database will be retrieved. These messages would be re-queued. Upon the actual invocation of target Web service, a valid result should be returned and sent back to the client. This test showed the ability of WSMQ to recover from error. The only weakness of WSMQ is that during the period that the queue servers are down, no service requests can be received from client. This weakness can be addressed by adding a persistent request sending mechanism in the WSMQ Web service invocation simulation library. Scenario 3 - Client timeout In this scenario, we disable Web service provider until the client timeout has expired, which means even when a successful invocation is made by the WSMQ queue server, the client will not be able to receive the result. Without WSMQ, the Web service invocation would simply result in a SOAP error. The client would receive this error almost immediately. With WSMQ, service request is sent to a queue server first. The queue will eventually attempt to make the actual invocation. At that point, a SOAP error would be received indicating that the target Web service is unavailable. However, WSMQ will not give up this service request at that point. It will update the state of the message and reattempt the invocation at a later time. This process will continue until a successful invocation is made. However by this time, the client timeout would have expired, the attempt to send result back to client will fail. This test successfully demonstrated the timeout function of WSMQ Web service invocation simulation library. Scenario 4 - WSMQ queue server and Web service provider down In this scenario, we shut down WSMQ queue server after it has received the client request. The Web service provider itself is also kept unavailable throughout the whole time. Upon restart, the queue server is to continue process unprocessed messages, however since Web service is still unavailable, it will not be able to complete each service request until target Web services starts up again. Without WSMQ, the Web service invocation would simply result in a SOAP error since target Web service is unavailable initially. The client would receive this error almost immediately. With WSMQ, service request is sent to a queue server first. The queue server will shut down before the actual invocation is made. After some time, the queue server will be restarted. Unprocessed message from the database will be retrieved. These messages would be re-queued. Upon the actual invocation of target Web service, a SOAP error would be received; message processing will be suspended and reprocessed after a fixed time period. When target Web service starts up again, a valid result will be returned upon invocation. The result will then be sent back to the client. This test showed the WSMQ's ability of handling faults at multiple points of failure. In this case, the processing of the message was suspended at several points. However, it was able to recover and complete execution. 5.2. Performance Evaluation We also evaluated how the integration of WSMQ into the existing Web service architecture affected the performance of Web services invocations. In general, messaging service applications adds overhead to message delivery due to the variety of services they provide. Similarly, WSMQ adds overhead to Web service calls no matter how efficient WSMQ may be. However, this new architecture has proven to derive performance benefits under certain scenarios. We look at one such case below.

Testing scenario The set of results in Figure 5 was obtained by having a single Web service receiving service requests from an increasing number of clients. The vertical axis indicates the average amount of time that each client takes to invoke and receive results for 50 service calls. On the horizontal axis, we increased the number of clients sending services requests. Please note that each client sends service requests to one Web service only, therefore the Web service would not be receiving requests from all clients until the number of clients is increased to ten. For example, when we set 5 clients each sending 50 services requests to the target Web service (without using any message queues), the average amount of time that each client completes its services calls was approximately 100 seconds. Original: Direct Web services invocation Message Queuer: Web services invocation through WSMQ Response Time (50 requests) 200 150 100 50 0 1 2 3 4 5 6 7 8 9 10 No. of Clients Original Via WSMQ Figure 5. Performance Evaluation Single Web service, Multiple clients Analysis The original (no message queuing) curve displays the worse performance. This is due to the multiple creations of service session threads by the target Web service in order to serve multiple clients simultaneously. When Web services are invoked through WSMQ, service requests are completed one at a time. This implies that only one service session thread is created by the target Web service at any given time. Surprisingly, the greater the number of session threads, the worse the performance of Web services. We need to clarify the fact that the above example is a special case in which the performance difference is magnified. In real life, services requests could be directed to thousands of Web services, in which case WSMQ may pose as a performance bottleneck. Although some smart load balancing mechanism can reduce the severity of this impact, it is still an open issue for the future developers. 6. Conclusions The final product WSMQ is a message queue application that is specifically designed to address some of the major issues relating to Web services, namely reliability, scalability, performance and security. We recognize that dealing with each of the above issues conclusively is worth a research project of its own, therefore trying to achieve all of the above in one attempt cannot be done without compromises and inconclusive features. WSMQ adds value to Web services in many respects. The reliability of Web services communication is greatly improved with features such as guaranteed delivery and recovery mechanism. Users can obtain better service (faster service completion) if they are willing to pay more. Service providers can also prioritize their services to attract users. The results so far has confirmed the merit of our system. We would like to emphasize that this work was done with a big picture in mind that is pushing Web services towards the new standard for distributed computing. Rather than attempting to develop each part of the system to perfection, we aimed to develop a complete system that could serve as a framework for future developments. Some of the possible enhancements on the existing application may include support for greater client interoperability, industry standard queue implementation, multiple threads for Web services invocation and improving the message scheduling algorithm. 7. References [1] IBM Web Services Architecture team. "Web Services architecture overview" http://www- 106.ibm.com/developerworks/library/w-ovr/ (accessed April 2004). [2] Foster, C. Kesselman and S. Tuecke. The Anatomy of the Grid: Enabling Scalable Virtual Organizations, International Journal of Supercomputer Applications, 15(3), 2001. [3] W. Hoschek. Peer-to-Peer Grid Databases for Web Service Discovery, Concurrency Practice and Experience 2002, 00:1-7, pp. 1-48. [4] P. Maheshwari and M. Pang, Benchmarking messageoriented middleware TIB/RV versus SonicMQ, Concurrency and Computation: Practice and Experience, to be published in 2004. [5] S. Tai, T. Mikalsen, I. Rouvellou, S.M. Sutton Jr., Conditional Messaging: Extending Reliable Messaging with Applications Conditions, Proc. 22 nd IEEE International Conference on Distributed Computing Systems, Vienna, Austria, July 2002, pp. 123-132. [6] S. Ramesh, H.G. Perros, A Multilayer Client-Server Queuing Network Model with Synchronous and Asynchronous Messages, IEEE Transactions on Software Engineering, Vol. 26, No. 11, Nov. 2000. [7] J. Snell and L. MacLeaod. Programming Web Applications with SOAP, O Reilly, 2001. [8] Specification: Web Services Reliable Messaging Protocol (WS-ReliableMessaging), http://www- 106.ibm.com/developerworks/library/ws-rm/ (accessed April 2004)