Personal Assistant: A Case Study on Web Service vs. Web Based Application

Transcription

1 Personal Assistant: A Case Study on Web Service vs. Web Based Application Guoliang Qian 1, Jing Zou, Bon Sy Computer Science Department, Graduate School and University Center of The City University of New York Computer Science Department, NAC 8-206, City College of New York, 138 th Street at Convent Avenue, New York, NY 10031, USA. Tel: Fax: guoliang@cs.ccny.cuny.edu Computer Science Department, The Graduate Center/CUNY, 365 Fifth Avenue, New York, NY 10016, USA. Tel: jzou@gc.cuny.edu. Computer Science Department, NSB A202, Queens College, Kissena Blvd, Flushing NY USA. Tel: Fax: bon@bunny.cs.qc.edu. 1 Abstract Non-blocking operation based on pre-determined schedule has many applications. We have created a Personal Assistant system that is able to send out notification according to requested schedule. Two techniques are explored in the implementation. One is based on asynchronous message passing and the other is based on request handling process in the background. Both of these two implementations are further exposed as a traditional web based application and as a web service. We also evaluate the benefit of running the application inside a homogeneous environment as well as the benefit of exposing existing functionality as web service with the help of the appropriate development tool. Key words: Non-blocking, asynchronous, web service, Oracle Job, JMS 2 Introduction Prescheduled operations are commonly required. For example, the parking lot may want to send an alert of an imminent expiration of a customer s parking meter. Press editors may want to send an news press, let s say, one day after it has been reviewed. System administrators are indeed performing such actions everyday. On the operating system level a job, such as periodic backup, disk integrity check, as well as virus definition update, could be scheduled by cron/acron facilities on Unix/Linux or the Schedule Service on Windows platform. If we employ such system utilities in our application for the purpose of realizing scheduled operations we would have to deal with heterogeneous hardware/os environments. This may greatly increase the complexity of the application as well as its maintainability in the future. Porting the application to a different platform may also make it necessary to redesign and recode at least part of the system. As a result some other efforts such as re-integration and re-testing become unavoidable. All these activities will increase the overall cost of building and maintaining the application which should be avoided from the perspective of software engineering. Thus it is more desirable to have a general solution that is accessible through multiple interfaces and runs in a homogeneous environment, and that can easily be migrated to a different hardware/os platform without much reengineering effort. We have built a Personal Assistant database application on top of Oracle DBMS version that accepts requests through different interfaces. It can send out notification at scheduled time. In such a system the client submitting a request should not be blocked till the request has been processed. It is because the actual action specified in the request may happen much later and may take a significant amount of time to execute. There are two possible approaches to realize the non-blocking behavior. In the first approach the process that submits the request forks a separate process. It s this separate process that will be blocked for a certain period of time until the request is processed. In this mode normal operation will resume without being blocked right after it starts the request handling process. A second approach is through asynchronous message passing. On one hand after the request is submitted, a message is passed to a destination and the normal operation resumes without being blocked. On the other hand a separate process is actively listening at the same destination for new messages. Upon the arrival of a new message the listener picks it up for further processing. In both of the approaches the underlying technique to schedule an message in advance is a Java sleep thread. Two possible designs for interfacing the underlying functionality of non-blocking request processing are also studied. One is a human oriented design as a traditional client-server web application. The other is designed as a web service based on Service Oriented Architecture (SOA). 1 This author will present the paper at the conference if accepted.

2 The rest of the paper is organized as the following. In section 3 related work and the technologies that enable the current design and implementation are discussed. In section 4 our design, implementation, as well as performance study are reported. The summary of the study and future work are presented in the conclusion section. 3 Related Work Both of the above mentioned non-blocking request processing approaches are implemented on top of Oracle DBMS. The first implementation is based on Java Messaging Service (JMS). In this approach the process that a client initiates to submit the request works as a publisher for publishing a message to a common message queue. The common message queue is known as a topic. At the same time a different process subscribes to the topic and consumes the message asynchronously for further processing. JMS is a component of a larger application framework known as Java 2 Enterprise Edition (J2EE). JMS is a set of Application Programming Interface (API) composed mainly of Java interfaces and a few of concrete Java classes. This set of APIs defines the general semantics of asynchronous messaging. Oracle provides a concrete implementation of the JMS standard in its DBMS. In this study the JMS provider implemented by Oracle allows us to implement all functionalities inside Oracle DBMS. The second implementation is based on Oracle PL/SQL and job scheduling facility, which we will refer to hereafter as Oracle Job approach. The basic idea of Oracle Job approach is to implement the scheduling as a PL/SQL stored procedure. The PL/SQL stored procedure can then be executed as an Oracle job in a different process for sending out notification s at a specific time in the future. In both implementations, the non-blocking request processing functionality can be invoked via a traditional web interface, or exposed as a web service. Various technologies are available for the implementation of a traditional web interface, such as JSP/Servlet, ASP, or as a PL/SQL stored procedure based on http packages supplied by Oracle. There are already extensive discussions on these standard web technologies [1] [2] [3] [9]. In web service implementation, it s the functionality itself that gets exposed, as opposed to the interface that accesses the functionality gets exposed. In brief, web services could be considered as a technology stack that defines a service-oriented architecture (SOA). This architecture has two facets. First, the functionality exposed as a web service is URL addressable. In other words, it uses standard web protocols such as HTTP as transport protocol and XML as a formatting language. Second, data and business logic are exposed through programmatic interface. There are basically four key components of web services: (1) XML, which is the data format for passing semantic information between applications. (2) Web Service Description Language (WSDL), which is a XML based language for describing a web service. (3) Simple Object Access Protocol (SOAP), which is a protocol by which data are transported between a service consumer and a service provider. (4) Universal Description, Discovery, and Integration (UDDI) which is a registry where available services are published for and searchable by consumers. Sandeep has provided an extensive discussion on web services in his book [4]. In this case study, one of our goals is to understand the Oracle Application Development Framework (ADF) [5] through the two specific implementations mentioned earlier and its potential for rapid prototyping web services from existing PL/SQL application. ADF is a complete standards-based framework based on the MVC (Model- View-Controller) design pattern (Figure 1 ) [6] to simplify the development of J2EE applications and web services. The motivation behind the study of ADF is to understand specifically the potential of code reusability and its flexibility so that we can recoup our investment in previous development effort. Two kinds of views are investigated in our study. One is created to consume the web service. The other is a traditional web interface. JMS message listener and Oracle Job both act as controllers. They respond to requests and create new threads to send the notifications upon due time. However given any other interfaces as views, after clicking submit, or through other request submission mechanisms, ADF controller will be triggered and access our previously built functionalities which are incorporated as ADF application module. Thus ADF accelerates development with ready-to-use design pattern implementations as reusable components that one has to code, test, and debug manually otherwise.

3 4 System Design and Implementation Figure 1 MVC design pattern and Oracle ADF Framework. As described in the previous section our Personal Assistant application is able to send notifications of upcoming events at pre-specified time without blocking the clients that submit the requests. The overall system design structure is shown in Figure 2. Two mechanisms for realizing such non-blocking behavior as well as two mechanisms to enable access to the underlying functionalities are further discussed in this section. Figure 2 Personal Assistant System Design. The request is initiated either from web based interface or through invocation of a web service. The request is dispatched to either a JMS system by publishing a message to the message queue or Oracle Job system by creating an Oracle job running in the background. In the JMS system, the message listener picks up a new message from the message queue and computes the schedule which can be computed by the Oracle Job from request parameter. After that a Java thread is created for each individual request. It is put into an inactive state for a time period determined by the schedule. After the thread is waken up, it directs the notification to be delivered through various channels which includes , short message to pager, voice mail, fax, as well as instant message.

4 4.1 JMS vs. Oracle Job The Java programming language has built-in support for multiple threads running inside the same process space. A process can create as many threads as necessary to perform computation concurrently. The Java Virtual Machine (JVM) coordinates the autonomous threads by the locking mechanism. In addition, each thread can put itself into an inactive state for a specific period of time by calling the sleep function and passing the number of milliseconds it wants to sleep as an argument. By employing this language facility, a designated Java thread is created for each submitted request. From the request parameter the length of the time period that must elapse before sending out the notification could be computed. This length is used as the argument to the sleep function. At due time, the thread is waken up by the JVM and continues its work to send the notification. Both JMS and Oracle Job implementations utilize sleeping threads to schedule the notification. However they differ from each other in the way these threads are created. In JMS implementation during system deployment a Message Topic was set up as the destination of the messages for each request. Once a request has been submitted a new message is created for it. The message has all necessary information describing the request which includes the time it is submitted and the time that the notification should be sent. Subsequently the message is published to the topic and the request submission process is completed. At the same time a message listener has been started as a different process by the system administrator also during system deployment. It listens at the message topic for new messages. Once such a message becomes available the listener will pick it up and will create a new thread to which the listener passes the message for further processing. The listener then goes back into listening mode. The new thread will unpack the message and compute the length of time and go into a sleeping state. Both the message publisher and subscriber are implemented as Java classes. Their member functions are wrapped as procedures in a PL/SQL package. In this way the Java procedures can run as an application in the Oracle DBMS which serves as the run time environment. Oracle DBMS comes with a PL/SQL package called DBMS_JOB that can let database user submit jobs to the DBMS for execution. The submitted jobs will then run in the background as different processes so that the job submission process won t be blocked and put in a stand-by mode till the jobs are completed. In the Oracle Job implementation the Java function that creates the new thread to handle the request is wrapped as a PL/SQL package procedure. Every time a request arrives for a scheduled operation, a new Oracle job is created and submitted to the DBMS to run in the background as a separate process. The newly submitted job will in turn call the PL/SQL procedure that actually runs the sleeping thread and sends the notification 4.2 Web Service vs. Web Based Application Both of the above implementations can be accessed through either web based interface or through web services. The web based interface is more oriented towards human consumer as an interactive scheduling tool. Thus a human friendly interface facilitating ease of programming and maintenance becomes important. Various standard technologies are available. For example, JSP/Servlet is part of the J2EE framework and ASP is part of Microsoft.Net framework. As we focus our current research on manageability and maintainability, we would like to see all layers of the application running in a common environment so that we don t have to deal with heterogeneous platforms. For this reason we choose to build the web interface using Oracle PL/SQL package called Web PL/SQL. This package has an extensive set of procedures that enable the production of PL/SQL program which runs inside the Oracle DBMS and generates dynamic information. Such information will then be delivered upon client request by Apache HTTP server that is embedded in the Oracle DBMS with the PL/SQL module installed. Two main advantages for generating dynamic information by a PL/SQL program running inside Oracle DBMS are 1) the database connections and memory are managed by the database internally and 2) the integrated system is easier to configure and maintain. The resulting web interface is shown in Figure 3 (left). A web form is presented to collect necessary information such as originator and recipient s name and , the nature of the notification content, as well as the desired schedule to send the notification. The information is delivered through HTTP to be processed by either one of the two scheduling mechanisms described in the previous section. Web Services technology is gaining more and more momentum as being platform and transport protocol independent framework of distributing functionalities and exchanging information. An economic and efficient way to create Web Services is to recoup existing functionalities implemented in varieties of languages by wrapping them into the common framework. Once the desired functionalities are exposed one needs to generate a description (WSDL) of the service for service consumers to invoke the service correctly. Subsequently the service

5 should be deployed into a runtime environment that provides an implementation of the functionalities required by the framework such as service transport protocol, security management, and so on. The service availability should finally be published into a UDDI registry for consumers to look up and to invoke. In our study creating a web service for our scheduling functionality is considered as a way to expose the existing functionality in a standard format that is readily accessible. On top of the web service a variety of interfaces could be built for specialized applications such as distributed information processing systems with high request volumes. With the help of JDeveloper IDE from Oracle we have been able to convert our PL/SQL program into a web service with a few of button clicks. The web service callable interface, WSDL, as well as deployment descriptor to deploy the resulting web service into an application server are all generated automatically. Even a web access end point shown in Figure 3 (right) was generated effortlessly by JDevelop to consume the service over the web. 4.3 Bench Mark Performance Study A preliminary performance study was conducted for the two implementations. HttpClient and Latka were used to simulate concurrent access to the web based application. HttpClient is a set of Java library that enables programmable access to HTTP resources. Latka is a test utility built on top of HttpClient that presents a higher level view of the HTTP resources with XML as the data delivery mechanism. A test program was created based on the above two facilities. Requests with randomly generated schedules along with other parameters are created and submitted to the two implementations. It was found that both of the two implementations can handle requests quite efficiently due to the fact that they are running inside Oracle DBMS with equal support from the database engine. However it was further discovered that the number of concurrent requests that can be handled by Oracle Job implementation is limited to maximum of 10. Beyond that limit new requests won t get immediate attention. Instead they are put in a job queue to be picked up until one of the 10 running job is completed. This is due to the fact that Oracle database has a configuration parameter that sets the limit on the number of concurrent jobs. Although the maximum limit for the Oracle Job implementation can be easily reset to a larger value, the impact on the performance has yet to be studied and understood better. On the other hand, the JMS version doesn t have such a constraint. We were able to generate 100 requests with different scheduling specifications and submitted them all at once to the service within 2 minutes. Each request received immediate attention without noticeable delay and the notification message was sent according to the schedule of each request. A complete test scheme for the web service version is still under development at the time of writing. Figure 3 Web Interface (left) and Web Service End Point (right) of the Personal Assistant System.

6 5 Conclusion In this case study we have focused on realizing non-blocking request processing through Oracle Job facility and JMS framework. A Java thread is created for each request in the two implementations. The thread is put into a sleeping state for a period of time that is specified by the request schedule. Upon waking up from sleep a notification is sent. The processing of an individual request is then completed. The two implementations are either presented through a traditional web interface as a human oriented service, or exposed as a web service end point for automatic machine consumption with a high request volume. We are planning to build different types of interfaces to consume the functionality exposed through the web service. The standard data presentation and functionality access mechanisms of a web service make it easy to integrate with other applications in a heterogeneous system environment. For example notification could be sent as a voice message or short text message to user s pager or cell phone through telephony API or VoIP gateway. An instant message (IM) is another alternative with the help of IM gateway. With the help of an appropriate development tool such as JDeveloper, exposing the functionalities of existing applications as web services becomes economic and efficient. Acknowledgement This work is supported in part by a NSF DUE CCLI grant # , and a PSC-CUNY Research Award. References [1] [2] Simple Object Access Protocol (SOAP) 1.1 World Wide Web Consortium (W3C), May 2000, [3] John Carnell, Bjarki Ho lm, et al, Oracle 8i Application Programming with Java, PL/SQL, and XML. Wrox ISBN [4] Sandeep Chatterjee, James Webber, Developing Enterprise Web Services: An Architect s Guide, Prentice-Hall PTR, ISBN , [5] Kelli Wiseth, Expect More Services, Oracle Magazine, Jan/Feb 2004, pp [6] [7] [8] [9] Andrew Odewabn, Oracle Web Applications PL/SQL Developer s Introduction, O Reilly 1999, ISBN