A Web Services Status Monitoring Technology for ... - IEEE Xplore

2 downloads 58433 Views 389KB Size Report
A Web Services Status Monitoring Technology ... good solution for enterprise integration. ... interfaces needs to understand server Web service standards. It.
2010 International Conference on Cyber-Enabled Distributed Computing and Knowledge Discovery

A Web Services Status Monitoring Technology for Distributed System Management in the Cloud Chia-Feng,Lin1, Ruey-Shyang Wu1, Shyan-Ming Yuan1,2 , Ching-Tsorng Tsai3 Department of computer science, National Chiao Tung University, Hsinchu, Taiwan 2 College of Computing and Informatics, Providence University, Taichung, Taiwan 3 Department of Computer Science, Tunghai University, Taichung Taiwan [email protected], [email protected], [email protected], [email protected]

1

Abstract—Web services define standard interfaces those provide good solution for enterprise integration. Recently, many researches focus on creating management standards to manage Web services. Web Services Distributed Management (WSDM) is one of the industry standards. However, to implement the WSDM interfaces needs to understand server Web service standards. It increases the complexity and difficulty to build the management system. In this research, we had simplified the Web service management effort between services using hook technology. Our management systems provide message flow oriented management atomically without modifying service code. Enterprise can control all flows and review them at any time. Finally, we evaluate the overhead for our proposed technology. Enterprise can build a quickly, efficient and extensible management system in the Web services environment.

behalf of their owners. The attractiveness of SOA is its open architecture. By defining standard invoking methods, different services with different implementation on heterogeneous platforms can be integrated together smoothly. Web Services is a representative of SOA. It is based on XML and defines three fundamentals standards. SOAP [2] (Simple Object Access Protocol) can invoke other services; WSDL (Web Service Definition Language) can describe the interfaces of a service; UDDI (Universal Description, Discovery and Integration) can be used to find the location of the service that is needed. Web Services can also support several transportation protocols, such as HTTP and MOM (Message-Oriented Middleware). Because Web Services have those characteristics, it can be rapidly deployed on many different platforms and let them to work together. For management standards, there are many standards defines the communication protocol and what agent should have, such as SNMP (Simple Network Management Protocol) [3] DMI (Desktop Management Interface) [3] , WBEM (WebBased Enterprise Management) [5] and WSDM (Web Services Distributed Management) [6]. All of them provide communication protocols and programming interface so that they can be used for most applications. Q Yu et.al [7] point out that while Managing web services, some condition should be considered, including Monitoring web services, Transactional support and Change management and Optimization. But most web services management implementation lack the support for monitoring issue, such as WebDG[8], AgFlow[9], WSMX [10]. Some research support management interface under each web service, but need to implement individual management interface for each web service [11]. It wastes time and need to modify original web services source code.

Web Service;Distubted system;Hook

I.

INTRODUCTION

Since web service/service-oriented computing had been used for many years to communicate between different web sites and enterprises. It becomes a common and useful protocol for cross sites communication. In service-oriented computing environments, qualities of services are an important factor to be considered when selecting and composing services [12] [13]. Due to there are many uncertain events, exceptions and faults in this environment, it’s not easy to manage enterprise web service environment. Therefore, service level agreements are important topic while mange web service applications [14] [15]. For example, once an error happened, the system administrator should identify where the problem is and find out the solution quickly. However, it usually takes a long time to realize where error had happened and identify problems. To control all service status in an enterprise, every service in enterprise should be monitored [1] [16]. System administrators have to make sure that every application were executing well because one may affect another. In this paper, we proposed a web service status monitoring technology to deal with management issue for distributed web services environment. II.

B. Problem description Many standards are defined for system management. Web services distributed management (WSDM) is one of them. It has Web services management interfaces and defines management operations and message parameters. Different management applications and services can exchange information easily because it relies on Web services,. However, those standards focus on management protocols and functions. It means that both system designers and developers have to pay extra efforts for those management protocols and functions. Because management functions cannot solve business problems directly, some corporations may feel that developing those functions waste many resources. At the meantime, it is not enough to

RELATED WORK

A. Related standard Service Oriented Architecture (SOA) is an architectural style whose goal is to achieve loose coupling among interacting software agents. A service is a unit of work done by a service provider to achieve desired results for a service consumer. Both provider and consumer are roles played by software agents on 978-0-7695-4235-5/10 $26.00 © 2010 IEEE DOI 10.1109/CyberC.2010.97

502

control and monitor single server. There are many interactions between Web services. Without proper handling those interactions, it is not easy to guarantee that the services can process all requests.

B. Hook API In the enterprise, a business requirement usually involves several services. Those services have to interoperation or exchange information so that the whole the requirement can be satisfied. It is common that one Web service invoke another service when it processes request. In enterprise environment, linking invocation chain helps to manage services. To monitor the activity of the service, all requests and invocation will be recorded for future query, showed as Figure 2.

In order to provide flexible and extendable management architecture in the enterprise web services environment, the agent-based architecture is proposed. Agent can collect manageable resources information. However, those resources still have to implement the management functions. It will affect the existed services program code. To solve the problem, hook technology is used. It can inject the manage code into the existed services without any code modification. The program logics include service information collection and WSDM end-point implementation. Therefore, it can reduce the effort to modify the program code. After the agent gets the information, it will provide the information to the management applications using the predefined protocols. Then, system administrator can monitor and control the whole system. III.

METHNOLODY

Figure 2. Request and Invocation Handler for Web Services



Request Handler: the handler will process request/response message to/from the service. When a message arrives, it will intercept and process the message. If a message id is in the message, the handler will insert the message id in the Message ID Mapping Table. Otherwise, a new message id is generated and inserted into that table. Then, the message will be forwarded to the corresponding Web services implementation program. After the service completes the request, it will return result to the caller. The handler will intercept the message again and find the corresponding message id in the table. It will remove it from the Message ID Mapping Table. Finally, the response message will be returned to the caller.



Invocation Handler: when the service invokes another Web services, the Invocation Handler will intercept the messages. The handler will do two things: (1) it will add Message ID into the message. The Invocation Handler will look up Message ID Mapping Table to find out message id. If there is existed ID, it will use the ID directly. Otherwise, it will create a new one. Invocation handler will put Message ID into the SOAP message that is sent to the target service. At the same time, it will also append the Web services Port data of the destined Web services to that ID in the table. (2) If necessary, it will redirect the message destination to another one. For example, when the destination service is down for maintenance, the request should be handled by another service.



Message ID Mapping Table: the table provides insert, query and remove functions. Besides, the table will keep all operations and time for query services invocation status. The table can not only provide the response time of the service, but also present the

Figure 1. Management System Architecture

A. Management Architecture The proposed management system architecture is showed as Figure1. For each service, it will integrate Management API and Hook API. They are responsible for monitoring Web services status and provide necessary information to agent. The APIs can monitor the whole process from invoking service to returning result. When a request is sent to the services, the APIs captures the request first. They will process the request and record information. Part of the content in the request message has identification added by another Management API/Hook API in the management system. The content is useful to monitor and control each service. Those APIs will also process the content in a request message. For the reason, if a service issues requests to another service, the APIs will capture the request first and add monitor information into the message. Therefore, all service information in the management system can be captured.

503

correct time of message arrived and returned. Besides, several messages can be linked together with the message ID. It is useful to monitor the business activities in the Web service environment.

handling message flows, the flows will startup to deal with problems. Exception and error handling flows in the management architecture are treated as special service selection cases. The different is that the flows for exception or error start when error occurred, but flows for service selection is used when the destination service PortType is match with one entry in PotyType mapping table. Invocation Handler will invoke the service at the first of exception or error handling flow and the mark the message as error in Message ID.

Under this architecture, if service A invokes service B and then service B invokes service C, they will all have the same message ID. From management perspective, the invocation flow is displayed and the relationship of those services can be known. C. Message Flow Tracking Due to service composition are usually executed dynamically, it is necessary to trace message flow to prevent lost or queued. At the same time, the tracing mechanism should not impact overall system performance and cause many design as well as implementation efforts. For this reason, an automatic message flow tracing mechanism with few performance influenced is required. The message flow tracing in the management system is shortly illustrated as three steps: •

Message logging



Information collection



Message flow analysis

IV.

D. Dynamically Service Selection With the completeness of Web services environment in a corporation, the service requestor will have the chance to choose suitable service. A service is unavailable for many reasons, like maintenance, server loading high, hardware error, and software fault. Under such cases, service requestor has to issue request to another service. In current enterprise Web services architecture, it is not usually to look up UDDI before invocation for performance issues. For the reason, an adjustable solution for service selection can improve service quality.

EVALUATION

Figure3. injection Overhead comparison

In this research, we had evaluated the hook API overhead and do some performance test experiments. When invoking business services, those components are not involved, besides Hook API. However, the logic of Hook API is quite simple. It only does two things:

Invocation Handler of Hook API can help to change service from one to another and redirect message to that service. Because the handler intercept the process that service requestor sent message to the service, it can rearrange the message destination. Invocation Handler accepts administrator’s configuration to create a Web services PortType mapping table with XSLT translation document. When an invocation message is sent to the original PortType field, it will redirect the message to the new Port type. At the same time, the message will be transformed based on XSLT if necessary.



Record and lookup SOAP message ID.



Log request process time and response time.

Although the two actions are taken every services invocation, their operations are quite simple and the program code size is small. Hook API program only does

E. Exception and Error Handling If there is an exception or error during service invocation, the exception or error handling procedure will handle the exception or error. Usually, the procedure will record the problems and notify related people to eliminate it. It is the same in the Web service environment. The procedure will log the error and send a notification to the management architecture. Besides, if there are exceptions or error



Request handler -- Extracts & records id, time_sent, time_resp from SOAP message header.



Invocation handler -- Gets Message ID from local memory and storage. And inserts id, source, time_sent, time resp into SOAP message header.

The experiment steps are listed below:

504



Install Hook API into Web services.



Run receiver and sender program code 1000 times.



Repeat 20 times, and calculate the average. Hook API program only does two hander:

ACKNOWLEDGMENT

The performance test recorded the total time from sending request to receiving response. Several parts of the invocation time are recorded. They are the time from client sending request to Web server getting it, Web server process time, Web service engine process time and services implementation process time. The general case is the service with injection; on the other hand, the experiment case is the service with Hook API(injection). Figure 3 shows the result.

This work is supported in part by the National Science Council of TAIWAN, R. O. C. under Contract NSC 98-2221E-009-074-MY2 REFERENCES [1]

Papazoglou, M. P., Traverso, P., Dustdar, S., & Leymann, F. ServiceOriented Computing: State of the Art and Research Challenges, Computer , Vol.40, No 11,2007, pp. 38-45.

[2]

World-Wide Web Consortium (W3C), Simple Object Access Protocol (SOAP), http://www.w3.org/2000/xp/Group/

[3]

Distributed Management Task Force (DMTF), Desktop Management Interface (DMI) Standards, http://www.dmtf.org/standards/standard_dmi.php

[4]

Distributed Management Task Force (DMTF), Common Information Model (CIM) Standards, http://www.dmtf.org/standards/standard_cim.php

[5]

Distributed Management Task Force(DMTF), Web-Based Enterprise Management (WBEM), http://www.dmtf.org/standards/wbem/

[6]

Organization for the Advancement of Structured Information Systems (OSAIS), Web Services Distributed Management (WSDM), http://www.oasis-open.org/specs/index.php#wsdmv1.1

[7]

Q Yu, X Liu, A Bouguettaya, B edjahed ,. Deploying and managing Web services: issues, solutions, and directions, The VLDB Journal, Volume 17 , Issue 3, 2008, pp. 537-572

Although service with injection takes more time, the different is very limited. It only needs extra 20ms to call injection program and process message flow ID. While a simple Web services program takes around 100ms. If the business function becomes more complex, it will take more time. 20ms will be small and not influence overall system performance.

[8]

Medjahed, B., Rezgui, A., Bouguettaya, A., Ouzzani, M.: Infrastructure for E-government Web services.. IEEE Internet Computing. 7(1), 2003, pp. 58–65

[9]

Zeng, L., Benatallah, B., Ngu, A., Dumas, M.,Kalagnanam, J., Chang, H.. Qos-aware middleware for web services composition. IEEE Trans. Softw. Eng. 30(5), 2004, pp. 311– 327

For system run-time, the overhead is small and adjustable. Although Hook API is involved in every service invocation, the overhead is quite small. Although many components are added, their executing priority can be adjustable. Therefore, the business operations have priority to complete request on time.

[10]

W3C: Web Service Execution Environment (WSMX):http://www.w3.org/Submission/WSMX/

[11]

Benatallah, B., Sheng, Q.Z., Dumas, M.. The self-serv environment for Web services composition. IEEE Internet Computing. 7(1), 2003, pp. 40–48

[12]

N. B. Mabrouk, S. Beauche, E. Kuznetsova, et.al., QoS-aware service composition in dynamic service oriented environments, Proceedings of the ACM/IFIP/USENIX 10th international conference on Middleware, 2009, pp. 123-142

[13]

M. Alrifai, T. Risse, , P. Dolog, , W. Nejdl,: A Scalable Approach for QoS-based Web Service Selection, 1st International Workshop on Quality-of-Service Concerns in Service Oriented Architectures 2008

[14]

V. Stantchev , C. Schropfer., Techniques for service level enforcement in web-services based systems, Proceedings of the 10th International Conference on Information Integration and Web-based Applications & Services, 2008, pp. 24-26

[15]

V. Stantchev , C. Schropfer,, Service-level enforcement in webservices-based systems, International Journal of Web and Grid Services, v.5 n.2, 2009, pp.130-154

[16]

R. S. Wu, F. Lin, A. Liang, S.M. Yuan , A reference model for building enterprise computing platform and its based integration framework , International Journal of Technology Management, Vol. 38 , No. 4,2007 pp. 439 - 462

In the experiment, service with injection spends more time than without injection. During service requesting, with injection service needs more 7 ms to call the injection program and process the message flow ID from SOAP API. Request Handler is called and extra message flow ID from SOAP header as well as insert it into local message flow ID Mapping Table. Then, it will remove message flow ID from SOAP header. SOAP message at this phase is processed and create object models in memory. For the reason, removing message flow ID from SOAP header will be very quickly. During service responding, with injection service needs more 8 ms to call the injection program and insert message flow ID into SOAP header. Invocation Handler is used. It will lookup message flow ID from Message Flow ID Mapping Table and insert into SOAP header. The insertion needs more time than deletion because insertion has to create a new XML object and its hierarchy.

V.

CONCLUSION

The proposed system in this research creates run-time architecture to manage web services. This system follows WSDM standards so that WSDM applications can manage them directly. Developing those management functions does not have to understand all WSDM specifications. Programmers only write the management code. The management system will expose them as Web services automatically. Based on the architecture, the message flow in the services environment can be monitored. Managers can know status for every message so that they can adjust business process or improve system performance to enhance business operations. With the management system, the enterprise Web services environment will have a complete management mechanism. Not only single Web service is managed, but also all message flow is under controlled. The environment will give corporate better support.

505