LOVE - Department of Computer Science, HKBU



Developing a Distributed e-Monitoring System for Enterprise Website and Web Services: An Experience Report with Free Libraries and Tools(

Frank K.W. Cheong1, Dickson K.W. Chiu2,4, S.C. Cheung1,4 and Patrick C. K. Hung3

1Department of Computer Science and Engineering, Hong Kong University of Science and Technology

2Dickson Computer Systems, 7A Victory Avenue, Kowloon, Hong Kong

3Faculty of Business and Information Technology, University of Ontario Institute of Technology, Canada

4Senior Member, IEEE,

email: kwcheong@ust.uk, dicksonchiu@, scc@cs.ust.hk, patrick.hung@uoit.ca

Abstract

Enterprises value monitoring as it provides dependable e-services, whether it is an interactive web site or programmatic Web service. However, this task becomes non-trivial when enterprises begin to require support from thousands of servers across geographical areas. How can the communications between a monitoring systems and remote servers be minimized? Could the task be achieved easily based on a readily available technology such as SNMP? How can we monitor thousands of servers powered by, say, Tomcat, which lacks SNMP support? How may a poorly responsive site be identified prior to being reported as a failure by SNMP? In this paper, we propose a unified e-monitoring system that enables system administrators to remotely monitor the health of distributed e-services in both the form of website and Web services. We further discuss our implementation experience based on a pragmatic prototype.

1. Introduction

Due to e-services over the Web, the annual transaction volume is expected to grow enormously within the next few years [1]. Major vendors of information technology like BEA, IBM, Microsoft, and SUN have been playing an active role in pushing new standards on Web computing (such as Java, JSP, Servlet, and EJB) and create timely products to synchronize with those standards. Due to the nature of Web applications and their relatively short product lifecycles, the level of testing prior to production is often inadequate. This is particularly the case for the handling of exceptions and irregular scenarios and may result in un-deterministic and poor performance of the corresponding e-services.

In an e-monitoring system, a number of remote monitoring agent(s) are deployed to closely monitor a list of pre-defined e-services (in both the form of websites and programmatic Web services) from various points of presence in different networks, subnets, or even different geographical regions. Although some products (like Load Runner from Mercury Interactive [2]) belong to these categories, they are priced higher and are limited to the few organizations that can afford it.

In this paper, we propose to implement such an e-monitoring system based on standard and extensible technologies. The rest of this paper is organized as follows: Section 2 reviews some background and related work. Section 3 presents the logical design of the e-monitoring system. Section 4 details our design and implementation choice. Section 5 discusses some of our experiences in before we conclude the paper with future research and development directions.

2. Background and Related Work

[pic]

Figure 1. Simplified network diagram

Figure 1 illustrates a simplified view of the possible components that exist between an end-user and a target e-service server. With the help of this diagram, we can imagine the possible list of partners and even equipment that exist in various locations.

The root cause of the irregularities (incomplete, corrupted, or delayed responses) may be caused by different components such as network problems with local network exchanges, network problems with upstream providers, network problems with co-location service providers, abnormal behavior of reverse proxy servers, abnormal firewalls or network switches in between, the server hardware or software, and so on. In order to accurately provide reports on the health of an e-service suffering from any problematic area mentioned above, more than one monitoring agent must be deployed in various network segments and even various geographical locations.

To reduce the cost of ownership in deploying new remote agents, the remote agent should work in a stand-alone mode (say, in a diskless station or even a small set-top-like box) and be able to communicate with central administration servers in an effective way. This allows for an updated list of targets to be sent to any remote monitoring agent easily. In addition, the performance statistics of the e-services collected during the health-check provides useful hints for trouble shooting or performance tuning. To achieve this, the remote agent should be able to send statistics information back to the central server in a timely manner so that the administrators can instantly acquire such information and make quick decisions as appropriate. For instance, the remote agent should allow for early identification of performance bottlenecks and faults by the administrator. With this information, the administrator can take corresponding actions or properly propagate the findings to the right party.

Apart from the free trace-route community [6] that provides network latency information, there are commercial services like Internet Seer [5], WebsitePulse [3], and Siteseer [4], which facilitate remote website monitoring from different points of presence in different geographical locations with added capabilities such as simulating end-users’ request and performance monitoring. These services are priced at the upper portion of the enterprise level, which simply means it is inaccessible by a large percentage of organizations. On the other hand, service providers offering moderately priced services only provide simple services like issuing a single HTTP request on a particular URL without checking on the content nor simulating user requests through a list of URLs. Therefore, these services cannot accurately detect when a website goes down.

To accurately obtain the health status of a website, we will need to simulate user interaction (e.g., putting item into shopping cart, proceed to checkout, and then cancel, etc.). Verifying the content returned for each (or at least some) HTTP request is equally important in order to ensure the website is replying the user in full. Similarly, the sequence of Web services defined by a BPEL specification should be traced accordingly for programmatic interactions. Along with the above checkpoints, we can also ensure there are no man-in-the-middle attack exerted between our e-service and the user located in different geographical location. Furthermore, checks can be completed to determine if if the target e-service is being tempered with or even being hijacked to avoid the content being replaced by hackers.

3. Conceptual Modeling

In this section, we highlight the conceptual model of the information sent from the administration server as well as that from the monitor agents. We also highlight the process that facilities the over e-monitoring system design and implementation.

1. Information sent from the administration server

[pic]

Figure 2. ER diagram of server-end information

Firstly, we have to clearly define what information the remote monitoring agents need to know in order to execute their tasks. At the top level, we need to define the entity “site” which consists of at least one “step”. Then, we need to specify what information needs to be communicated to the server and the ideal response. We also define the interval, on a global scale, that the remote monitoring agent should be performing during the health check. Moreover, we need to define the email address of the corresponding personnel that the remote monitoring agent should report to in case of problems or irregularities.

Further, each site is assigned a unique ID and a unique name for identification. Step is an entity to record the activities and results of each physical step that the monitor takes. Each step is identified by a unique ID and a name. The StepPosition records the position of the step in the e-monitoring process. For instance, step position 1 denotes login. A Step entity also contains the URL of the server at which the remote monitoring agent targets. The method (e.g., GET, POST, and HEAD) that the remote monitoring agent performs is specified at the RequestMethod. For websites, FormValue contains the form variable and value that the remote monitoring agent should be posting to the server (e.g., user id and password for a login request). ExpectedResponseCode states the expected HTTP Response Code by the remote monitoring agent. ExpectedMD5 holds the expected MD5 checksum of the response message so that the remote agent can verify the content integrity. For Web services, the service, port, operation, input / output parameters and their values are used instead.

2. Information sent from the remote agent

[pic]

Figure 3. ER Diagram of remote-agent information

Apart from what is mentioned above, the remote monitoring agents collect valuable information (cf. Figure 3) to be transmitted back to the central administration server. To help performance tuning, the roundtrip time for each of the steps (i.e., each HTTP request and response) is the most important information. In addition, the HTTP header for each response contains hints on whether there is a reverse proxy between the website and the client. The HTTP header can also help identify if the user is actually getting the reply from the target server or third parties who might have intentionally hijacked it. Note that each server adds in a HTTP header about the product (e.g., Weblogic, Websphere, or Tomcat) and its version in use. In addition, we can also tell if the content is being poisoned by cross checking against the MD5, calculated with the information sent from the central administration server. Moreover, we can send the response code, messages, and MD5 calculated back to the central server for recording purposes. Finally, we add the IP address of the remote monitoring agent so that we know which agent has sent back such information and in turn know the possible performance bottleneck in different network segments and even geographical locations.

The remote monitoring agent would need to make verbose (de-normalize) some of the information before sending back to the central server in order to avoid confusion caused by the discrepancy of information being stored in the central administration server and the remote monitoring agent(s). So, the central administration server only needs to store information that is retrieved from remote monitoring agent into one single entity. With such de-normalization we can also increase the speed by performance monitoring in the central administration where the need to join large tables is eliminated.

3. Processes

The e-monitoring system is subject to three main processes: monitoring, statistics updating, and site list refreshing, which are depicted by Figures 4 to 6, respectively.

4. System Design and Implementation

In this section, we will first illustrate the high level architecture of the overall design. Then we will discuss each of the components and layers of the system. Throughout this section, we evaluate different alternative technologies and explain why we selected it for the implementation.

[pic]

Figure 7. Deployment Diagram

1. Overall Design Criteria and System Architecture

In this project, we aim to select as many free components as possible in order to reduce the cost. We avoided coding as much as possible in order to reduce the time for development. The coding selected is publicly available libraries. However, we also avoid using libraries without open sources to reduce the overall complexity and hence interoperability problems or even the dependency on a specific Java Development Kit (JDK) version. Figure 7 is a deployment diagram depicting the distribution requirement of this system, which is helpful for the following sub-sections

2. Front End Monitoring Agent

The core function of a front end monitoring agent is to first obtain a list of targets to be monitored from the back-end central administration server. It then checks through the list of URLs obtained with the supplied information. Finally, the monitoring agent sends any statistical information collected back to the backend central administration server. We have chosen to delay the alert back to the central administration server in order to avoid false alarms. Normally, this will not cause information loss unless the central administration server also goes down simultaneously.

Language chosen - One of the core requirements of the monitoring agents is the ability to be deployed to as many platforms as possible without the need of rewriting any portion of code. Therefore, we have chosen Java, which is a platform independent language. Moreover, Java is increasing its popularity where more and more free components are available so that development time and effort can be reduced.

Multi-threaded design - Monitor agents must monitor multiple targets at the same time. If the HTTP requests are issued one by one in a single threaded serial mode, it would be difficult to promptly check each target in a pre-defined time interval. This is because the response time of each of the HTTP requests would affect many factors and it would in turn push back the start time of subsequent monitoring tasks. In addition, the statistics collected from different monitoring agents could not be used to compare and visualize the network latency at the particular time slot as they neither happened at the same, nor around the same timeslot. In order to collect statistics information for apple-to-apple comparison, we would need to issue various HTTP request at the same time, or at least try to reduce the start time between issuing the first HTTP request for different sites.

Since, the time required for creating and forking a new thread is quite significant, we still need to carefully design a proper thread pool or to select a freely available thread pool implementation in order to minimize the time delay between each HTTP request. A simple Google search of the keyword “free Java thread pool” returns more than 200,000 hits with many examples and even free Java multi-thread pooling library. However, many of them are either under maintenance [10], or are already outdated [9], or commercial products [8] which do not satisfy our requirement. Fortunately, there is a thread pool implementation available in JSDK 1.5 [11] where we can choose and it is free. In addition, it has all the required features for a multi threading system including thread pooling, atomic variable, locking and semaphore, etc.

Checking the targets - In order to accurately check the healthy status of as many targets as possible, the remote monitoring agent should have the following capabilities.

1. Issue HTTP/HTTPS GET and POST request

2. Send HTTP variable and value together with HTTP/HTTPS POST request

3. Simulate user request by issuing a list of predefined HTTP request together with HTTP variable and value

4. Memorize and handle HTTP session of various language (e.g., with sites written in Java, session information will be identified by a cookies named JSESSIONID)

5. As Web services invocations are just SOAP messages sent over HTTP protocol, the communications are also adequately supported. However, to increase the performance, the SOAP message translations and templates can be performed beforehand and stored for repeated transmission.

HTTPRequest layer - We have developed a prototype using the HTTPURLConnection from Java and found that the default HTTPURLConnection is not working very well with multi-threading environment. In addition, it lacks some sophisticated features with HTTP session management, cookies support, etc. Further, in comparison to Oakland software [12], we found that the anther free HTTPClient completed most of the tasks like the HTTPClient innovation [14]. Unfortunately, the library is a bit outdated (last modified in 2001). There are commercially available libraries like the one offered by Oakland software [13] with rich features and active support. But again, as we are trying to develop the system with minimal cost, we shall avoid any commercial library unless we have no other options. Luckily, the HttpClient from Apache Jakarta Common project [15] has come out on February 2005 with all the features that we needed and it is releasing RC2. Most importantly, it is free and being backed by the Apache Jakarta Project Common where support can be sought easily and the project quality is quite good. Thus, we have chosen to implement the HTTPRequest layer using this library.

User interface (UI) layer - In order to reduce the possible rate of change, we implemented the front end monitoring agent with Java GUI. There are two mainstream Java GUIs available, namely, Standard Widget Toolkit (SWT) [16] and Swing [21]. SWT is a sub-project of the Eclipse project initiated by IBM. Its main objective is to create a feature-rich GUI. In addition, its core design objective is a close binding with the underlying operating system native API [17]. With this, they attempt to boost the performance of the Java GUI and create an outlook as native in that platform as possible. Swing is the second generation of the Java GUI (Successor of AWT) of Sun Microsystems. The overall design has a clean separation between the GUI components and model objects according to the Model-View-Controller (MVC) design pattern. In addition, it tries to emulate different platform-specific components with lines, rectangles, and text. Thus, it runs a little bit slower than native APIs. It its early history, before JDK 1.4, it was quite slow, ugly, and buggy,. However, both the outlook and the speed have been greatly improved in JDK 1.5. Swing is chosen for the UI Layer because we found that SWT and Swing perform roughly the same. In addition, Swing seems to be the only alternative when we need to reduce the cost of ownership as it is bundled in the Java JDK 1.5 distribution.

Database Persistence Layer - The support of “container managed persistence” is common to Enterprise Java Been (EJB) applications whereby the EJB container can help in managing database persistence and dramatically reduce the amount of work required. Unfortunately, one of the core requirements of the monitoring agent is the ability to be run in a stand-alone mode and thus no container (neither J2EE nor web container) will be installed. There are some Java libraries which can provide similar functionality. The ideal case would be to reuse the same database persistent related code on both the server and client application to reduce the learning, development, and maintenance curve. We identified the following requirements for the data persistence layer and studied some free products: support transaction management; facilitate mappings between Java objects and relational data models (ORM); provide connection management; exempt the need to write low level Java Database Connect (JDBC) code; and allow code written for one application to be ported to another application under different environments.

Hibernate [24] is a project started since late 2001. It targets to provide an easy object relationship mapping and database level persistence. It is very mature and can work with most of the web development framework (e.g., Spring, Struts, etc.) and also be able to integrate with CMP when writing EJB.

SQLMaps [23] is a project started early in 2002 and is now renamed as Data Mapper; their objectives are similar to Hibernate’s. It however targets a low-level financial requirement in order to allow administrators to tune and rewrite the SQL with configuration files in XML. Java Data Object (JDO) [25] is a specification with its latest version of 2.0. There are also a few libraries that implement this standard. Having checked out the comparison by Oak [26] together with a Google search, we found that Hibernate is the most popular amongst other ORM Tools. In addition, the development time can be dramatically reduced by employing Hibernate, which can compile a database table definition into the corresponding XML and Java class with the relational mapping in just a very click and select. The only potential drawback of Hibernate is that it does not follow JDO nor other standards, which means it would be difficult to change the database persistence layer to other vendor’s product.

3. Communication between monitoring agents and the central administration server

The main purpose of the bridge between the central administration server and the remote monitoring agent is purely on transferring textual information. So, the design of this communication layer should be as simple as possible to increase the throughput. Moreover, the monitoring agents need to know if each of the information transmission is successful or not so that it can determine whether to retry the failed transmission in the next batch of conversation. In addition, each conversation already provides some value-added information for the central administrator to see if each monitoring agent is functioning properly.

However, as the communication has to pass through the Internet, hackers can easily trap any information that flows in between the two parties. We therefore would like a secure protocol. In addition, we also need to ensure that no viruses or hackers can gain control of either the central administration server or the remote monitoring node easily. Although we have chosen Java to implement the monitoring agent, we would like to support other languages as an option in the future so that they can be run on as many platforms as possible.

Evaluating Web Services - Based on the above requirements, we have chosen to use Web service as the communication layer between the central administration server and remote monitoring agents because of the following benefits. (1) It is light weighted and based on SOAP messages as compared with heavy weight protocol like JMS, etc. (2) The deployment is easy because the communication can go through standard firewall ports like HTTP or HTTPS. (3) Security is well supported by HTTPS as well as more sophisticated WS-security standards could be used; thus making it difficult for hackers to crack a message even if they managed to trap it. (4) Scalability and high availability can easily be archived by employing a clustering solution which is provided by most of the web containers like Tomcat, Websphere, and Weblogic, etc. (5) Web service is language-dependent and therefore interoperability is provided by default.

Choosing the right protocol - We choose the Web services protocols directly available under the JDK to reduce the cost of ownership. There are three options, namely Soap with Attachment API for Java (SAAJ) [21], Java API for XML Messaging (JAXM) [33], and Java API for XML-based RPC (JAX-RPC) [34]. SAAJ enables Java programs to communicate using Web services with any attachment supported. JAX-RPC and JAXR implementation goes on behind the scenes actually using SAAJ. The API allows XML messaging from the Java platforms to read or write SOAP-based XML messages directly. In short, it requires the application development to encode and decode the message and thus requires much more programming. JAXM enables applications to send and receive document-oriented XML messages in asynchronous mode when the application client resides in a Web container. Unfortunately, the monitoring agent actually is a stand- alone client. In addition, as the communication layer need to provide instance feedback to application client, JAXM is often not suitable. JAX-RPC allows applications to use remote procedure calls to communicate with Web services server based on XML messages. Programming with JAX-RPC is easy and suits our configuration. Therefore, its straight-forward approach was selected for our implementation.

Registry options - After completing the Web service application, we might want to publish the definitions for public access. As the scope of this application is right private, registry options like the UDDI do not fit well in this picture. Instead, we would like to reduce the effort in providing the communications. Thus, other techniques like Dynamic Invocation Interface, Dynamic proxy, and JNDI Context lookup are not employed either. Simply accessing the WSDL URL would be more than enough to minimize the complication of the application.

Accelerating Java Web service development - In order to reduce the effort in programming a Web services application, we have chosen to use Eclipse Web Tools Platform (WTP) as the IDE to develop the Web services related portion of the application. With Eclipse WTP, Web services related programming would be as easy as programming Java beans because it supports the required processing logic with the programmer’s answer to some simple questions amongst three screens [35].

Accelerating Hibernate development - Since Hibernate requires the developer to hand-code many Java classes and XML files, we choose Eclipse IDE (not WTP) with Hibernate Tools to generate these files based on the MySQL tables that we have created. This can be done in a few clicks and select and reduce the development effort needed and in turn reduce the overall development time needed. The reason why we do not use Eclipse WTP is because with Eclipse WTP, we can only create Web applications or enterprise applications but not stand-alone Java applications. In that case, we have to use separate development tools for the front-end and back-end.

Logging - It is very often that developers will not introduce any logging until they find it to be too difficult to debug, which is already too late. In this project, we introduce the logging sub-system at the initial design with the following requirements. (1) Logging can be turned on and off without changing any code. (2) Logs can be roll over according to date. (3) Logs can be put in various formats without changing any code. (4) Logs can be sent over to a central logging host without changing any code. Fortunately, there is an open source logging library called log4j that can fulfill the above requirements. Writing a log is as easy as writing the statement ‘log.error(“error”)’ in the program, and then the logging can be enabled or disabled by modifying a configuration file.

4. The Backend server

The backend server has the following main requirements:

• Consolidate statistics from remote monitoring agents.

• Dispatch the latest changes of targets to be monitored to remote monitoring agent.

• Analyze and fire alarms in case any monitored target goes down, delivers corrupted response, or is being hijacked

• Present the collected statistics in a way to facilitate easy performance tuning.

MVC Framework used - There are many different ways to develop a Web application. A multi-developer application cannot be integrated easily without proper guidelines. In addition, most application development frameworks can add some advantage on the development such as reducing the development effort, isolating the application logic with database access, and so on. Popular application frameworks include Tapestry, JSF, Structs, and Spring. Spring was chosen because it integrates well with many other libraries which can help tackle its weakness by introducing other libraries to solve the problem. In addition, there are many examples on how to deploy Spring with Hibernate, which can smooth out the learning curve. Most importantly, the trial (a domain driven development framework) version has a good integration example with Spring and Hibernate, which can dramatically reduce the development time and effort on all back-end Create, Read, Update, and Delete (CRUD) applications.

Code Generation - To accelerate the development, we also employ a Code Generation Framework so that we can reduce the effort needed in creating the backend application. We looked into two alternatives: AndroMDA and Trail. AndroMDA [29] is a well-known code generation tool based on the Model Driven Architecture framework, which takes a UML model as an input and generates a set of workable Java programs. It has good integration with well-known UML tools. There are similar projects like the OpenMDX [30] which is also an open source code generator based on the Model Driven Architecture. Unlike the MDA framework, Trail [31] is based on the Domain Driven Framework, with its main objective on to boost the speed of development of database-driven web applications. With AndroMDA, it is advised to reflect any changes to the UML and then regenerate the whole application again. While with the Trail framework, its main objective is to generate the first set of Database driven web application. After that, developers are free and rather advised to modify the code directly. Our back-end application is mainly a CRUD web application where Trail fits in the picture very well. We choose this because it also solves some of the common problems like the inability to design the HTML layout conveniently using UML.

Logging - Although most web containers provide a central place for storing application log, we found that the functionality provided is inadequate and thus we choose to use the same library “log4j” in both back-end and front-end.

5. Configuration

In summary, the e-monitoring system was developed with the following front-end and back-end configurations and tools. Due to spacing limitations, we have eliminated the discussion regarding database components; the components are not within the scope of our research.

Front-end System - Language: Java, Library: Hibernate, IDE: Eclipse with Hibernate Tools, Database: MySQL, Database Modeller: FabFORCE DBDesigner.

Back-end System - Language: Java, Container: Tomcat, Library: Hibernate, Spring, Trail, IDE: Eclipse WTP, DB: MySQL, DB Modeller: FabFORCE DBDesigner

5. Development experiences and future plan

There are many pitfalls in software development, especially for those projects which try to reduce the development time and cost by employing free library and tools. Very often problems may be caused by incompatibility between different tools or library version.

In order to spot such problems at the beginning stage of the project, we have to work out many small prototypes with those libraries and record down any incompatibilities discovered. To solve them, examination of mailing lists or forums to see if others have encountered the same problems and their resolutions is necessary. However, if there is no information available, we may need to try different versions of each of the libraries and see how incompatibilities can be solved. We have to redo the tests for all other prototypes that use such libraries and see if there are any other incompatibilities. This process has to be repeated until all incompatibilities are gone. Finally, we would better contribute back to the community by posting the problems encountered with resolutions to relevant public mailing lists and forums. Here are some examples.

FabFORCE DBDesigner has a reserve engineer function and a database sync function for creating the database model from the existing database and vice versa. This function is found to only work with MySQL version 4.0.xx because the development of this FabFORCE project has been stopped for more than one year and diverted to another project called MySQL WorkBench. However, the WorkBench Project has not come out for some reasons eventually and MySQL is at version 4.0.xx at the time the project FabFORCE DBDesigner has stopped.

Unfortunately, the XML files generated by the configuration generation wizard of Hibernate Tools cannot capture the relationship between tables stored in MySQL version 4.0.xx. MySQL 4.1.11 is the only version that the Hibernate Tools can work properly. Owing to the criticality of the Hibernate related XML files, we choose to use MySQL 4.1.11. We will export the DB Model as SQL scripts and then execute those scripts manually using MySQL CLI to solve this problem.

As many Web services tools are still at their early stage of development, they are not yet a stable release and are subject to a lot of bugs. For example, Eclipse WTP has a Web Services Generation Wizard that generates all required Java classes and WDSL for both the Web services provider and the client after defining the detailed logic (cf. the “Bottom up Web Services Tutorial” [27]). However, we cannot even complete the working tutorial under a working environment, even after days of reinstallation of every library, the Eclipse WTP, and even the JDK. With such, around two weeks were wasted. Fortunately, Eclipse WTP version 1.0M4 allows for a smooth compilation.

Apart from this problem, we also found that the primary focus of the Eclipse WTP is developing web applications. Therefore, we cannot continue our work on the monitoring agent with this WTP. Instead, we have to use Eclipse 3.1M6 as the IDE of developing the standalone application and switch to WTP 1.0M4 on the Web services and the back-end server.

As for the future plan, we can redesign the front-end monitoring agent to increase its mobility, by using pure text files. For the list of sites to be monitored, it can actually retrieve resource bundles or properties files from the central administration server. With such changes, a database engine will no longer be necessary in the front-end system. There are other alternatives to deploy Hypersonic SQL instead where the whole database engine just resides in a single JAR, which makes deployment easy.

As for the back-end Web container, we have chosen Tomcat, which it is quite buggy and unstable (often crash without notice) as there are few free alternatives at the time we designed this system. Fortunately, the apache group has another new project called “Geronimo” which is a new J2EE web container. We will keep a close eye on this project and may swap the Tomcat with this Geronimo when it becomes popular and stable.

6. Conclusions

In this paper, we have presented a pragmatic architecture for the distributed monitoring of e-services, including traditional websites as well as programmatic Web services. This is a key task for enterprises to provide dependable e-services. However, most existing software, which only provides part of the functions, are proprietary, and often not extensible to new service protocols. Our initial plan is to monitor websites only. But we have found that the extension to monitor Web services is rather straightforward with our design, by simply extending the definition of a “step” in the monitoring process.

We have also illustrated how well Web services can fit into the picture of a distributed application. By programming with Dynamic Invocation Interface, we can further customize the use of Web services as the communication layer between centralized server and remote application clients for different distributed application like Point of Sales (POS).

In addition, we also detailed our design choice and development experiences. We illustrate how we can improve the development efficiency by employing different public available libraries and tools, although a considerable effort is required for the initial screening against incompatibilities. Afterwards, with these libraries and tools, we can reduce the chance of introducing new bugs throughout the design and development of a subsystem. As discussed, there are many free software libraries available on the Internet to dramatically reduce the development effort and time needed.

For future research, we are looking into the use of a script language [36] for the monitoring of complex sites. We are also interested in the reliability of the e-monitoring system itself. We are also adapting this approach for another project for monitoring of stock trading systems [37].

References

1] Gary P.Schneider, “Electronic Commerce 3rd edition”, Thomson Course Technology, 2002, p3

2] Load Running from Mercury Interactive,

3] WebsitePulse,

4] Site Seer from Mercury Interactive,

5] Internet Seer,

6] Free online traceroute website,

7] Broken online traceroute provider,

8] Commercial JThreadKit,

9] Thomas W. Christopher and George K. Thiruvathukal, “High Performance Java Platform Computing Book”, published 2000 by Prentice Hall PTR and Sun Microsystems Press,

10] Free Util.concurrent,

11] Overview of the new concurrency library from SUN Microsystems, Inc,

12] Comparison between different HTTPClient implementation,

13] Commercial HTTP Client by Oakland Software Incorporated,

14] Free HTTP Client by Innovation,

15] The Apache Jakarta common project – HTTPClient,

16] Home of the SWT project,

17] Implementation strategy of the SWT project,

18] Web Blog about SWT from Kevin,

19] Andrei Cioroianu, OnJava’s arcticle about Java Desktop Development,

20] In-depth comparison between Swing and SWT,

21] Project Home of Java/Swing,

22] Desktop Client Demo from SUN for Java/Swing,

23] SQLMaps, iBATIS,

24] Hibernate,

25] JDO, Sun Microsystems Inc,

26] How to decide which persistence technology to use? JDBC / CMP Entity Beans / Hibernate / JDO ?,

27] Kathy Chan, Bottom Up Web Services Tutorial,

28] Project Home of Jasper Report,

29] Project Home of AndroMDA,

30] Project Home of OpenMDX,

31] Project Home of Trail,

32] Eric Armstrong, Jennifer Ball, Stephanie Bodoff, Debbie Bode Carson, Ian Evans, Dale Green, Kim Haase, Eric Jendrock, “The J2EE ™1.4 Tutorial” , Sun microsystem inc, 2004, p345

33] Sun JAXM resources website,

34] Eric Armstrong, Jennifer Ball, Stephanie Bodoff, Debbie Bode Carson, Ian Evans, Dale Green, Kim Haase, Eric Jendrock, “The J2EE ™1.4 Tutorial” , Sun microsystem inc, 2004, p319

35] Eclipse community web site re “Bottom Up Web Service Supporting Flexible Projects”,

36] D.K.W. Chiu, Danny Kok, Alex Lee, and S.C. Cheung. “Integrating Legacy Sites into Web Services with WebXcript,” International Journal of Cooperative Information Systems (IJCIS), 14(1):25-44, 2005.

37] Edward W.Y. Ho, D.K.W. Chiu, and P.C.K. Hung. Alert Based Monitoring of Stock Trading Systems, 30th IEEE Annual International Computer Software and Applications Conference, pp. 77-86, Chicago, USA, Sept 2006.

( This research was partially supported by a NSFC grant from China (Project No. 60673112) and an RGC/CERG grant from Hong Kong (Project No.612306).

-----------------------

|[pic] |[pic] |[pic] |

|Figure 4. Monitor process |Figure 5. |Figure 6. Obtain fresh site-list process |

| |hGDŸhsC?:?CJPJaJnHo([pic]tH1hGDŸhsC?:?CJH*[pic]OJPJQJaJn| |

| |Ho([pic]tH"hGDŸhsC?:?CJaJnHo([pic]tHh(P | |

| |h(PaJo([pic]" | |

| |j[pic]+ðh>eEhÔG@0J-5?B*[pic]phhSS5?B*[pic]oUpdate | |

| |statistics process | |

[pic]

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download