Measuring Overhead for Distributed Web Service HandlerI. IntroductionII. Distrıbutıng handlersIII. Measurements And AnalysısA. Methodology B. MeasurementsIV. ConclusionReferencesMeasuring Overhead for Distributed Web Service Handler Beytullah YILDIZ Department of Computer Engineering TOBB University Economics and Technology Ankara, Turkey E-mail: [email protected] Geoffrey C. Fox Department of Computer Science Indiana University Indiana, USA E-mail: [email protected] Abstract—Service Oriented Architecture perfectly manifests itself in Web services, which create seamless and loosely-coupled interactions. Web service utilizes supportive functionalities such as security, reliability and so on. These functionalities are called as handlers, which incrementally add new capabilities. However, adding new handlers into the execution path may cause performance and scalability problems. Distribution of handlers solves these problems by providing abundant computing resources. However, pulling a handler out of its native place and positioning it away from Web service endpoint brings additional costs. Hence, we will investigate the overhead of handler distribution for various environments. Keywords-Web Service, Distributed Computing, Handler Structure, Multi-core I. INTRODUCTION Web service is defined by World Wide Web Consortium (W3C) as a software system that provides a standard means of interoperating software applications, running in variety of platforms[1]. It utilizes Web Service Description Language (WSDL) to provide a standard way to define services [2]. A Web service can be published to a Universal Description Discovery and Integration (UDDI) registry to be discovered and defined how to be interacted over Internet [3]. In addition, Web service framework uses Simple Object Access Protocol (SOAP) as de-facto standard to exchange structured information [4]. Requests and responses travel within SOAP messages. Hence, Web services strongly employ SOAP processing engines and transport helpers to contribute the interactions. These functionalities are combined in middleware system called Web service container, which essentially hides the complexity of SOAP processing and details of message transportation. Web service employs additional functionalities, which are called handlers, by utilizing the extensibility feature of SOAP. Depending on the service container, these functionalities can be called as filters too. Generally, a Web service container provides a handler processing pipeline so that many handlers can contribute to a service interaction. In other words, many capabilities can be incrementally added to a service interaction. Even though handlers improve service capabilities, they may complicate a service interaction because of having too many handlers in a single processing chain. This may be inevitable in some situation to offer necessary qualities. On the other hand, handlers can become autonomous processing nodes. Hence, they can be separated away from the service endpoint with the intention of creating more powerful, efficient, scalable and modular service environment. Web service architecture supports this separation without harming correctness of the execution. When handlers are deployed away from a service endpoint, they become individual applications running without knowing each other. Hence, the detached and distributed handlers are needed to be orchestrated and managed so that they can achieve the execution, which was successfully happening before. There are several reasons to separate a handler from the service endpoint. We may need to benefit from additional resources such as processor, memory and storage space. We may want to have a powerful architecture by offering a more modular and scalable structure. We may need to increase usability. Finally, we may successfully introduce concurrency to the handler execution. However, all these advantages do not come for free. The additional requirements for the orchestration and management of the message execution bring extra burden to the services. Hence, we will investigate overhead for Web service handler distribution. II. DISTRIBUTING HANDLERS Handlers are very necessary architectural components of Web service framework. Distribution of the handlers to the individual physical and/or virtual machines provides many advantages and opens doors to the immense computing resources. The computing power of machines almost doubles every year following the projection of Moore’s law[5], the network speed also catches up with the same pace. Hence, the obtainable computing power increases steadily. Moreover, many other resources also became accessible such as application software, storage, and sensor and so on. We may hit barrier if we insist to utilize single machine for Web services while we can access many computing resources in the remote places. Therefore, we build architecture to distribute handlers, shown in Figure 1.Figure 1 : Distributing Handlers In general, conventional handler structures does not benefit from handler distribution. JAX-RPC [6], Apache Axis [7] and Web Service Enhancement (WSE) [8] deploy handlers into the computer where the service endpoint resides. On the other hand, there exists a work whose intention is to distribute the handlers. DEN/XSUL targets directly to the Web Service security processing steps without touching the service logic at all [9, 10]. It tears and granulates the security processing node and deploys the sub-tasks as individual services. This approach sets an example to distribute the handlers as Web services. Utilizing Web service approach for the handlers provides several benefits. The first benefit is to be able to remove bottlenecks from the SOAP processing pipeline with a very well-known style. Additionally, service based-approach improves the interoperability of the deployment. Moreover, this approach is able to utilize the tools that have been already implemented for the Web services. On the other hand, we follow a different approach. We have created an architecture, Distributed Handler Architecture (DHArch), to provide a scalable, efficient and modular environment for the handlers. It is basically a distributed Web service handler container, a specialized middleware system. It basically removes the bottlenecks from SOAP processing pipeline by using additional resources and providing an environment for the distributed execution. DHArch efficiently distributes