GWIF: A Generic Web Application Integration Framework

GWIF: A Generic Web Application Integration Framework Fábio Rodrigues Costa 1, Zair Abdelouahab 2 1 Sarah Network of Hospitals, Av. Luis Rocha, Monte Castelo, São Luís/MA, 65035-270, Brazil fcosta@sarah.br 2 Federal University of Maranhão, CCET/DEE/UFMA, São Luís/MA, 65080-040, Brazil zair@dee.ufma.br Abstract The success in many businesses today depends on how easy the applications distributed in the Web are adapted and integrated. Considering this, the electronic commerce is far from being the limit, as a result the necessity of establishing some integrated and intelligent channels with suppliers and customers has become a number one priority. Since a lot of Web applications with their own solutions have come up in the market, it was detected the necessity of developing a Framework able to develop their integration through generic and adaptive form, without the need of rewriting their code or modifying their original structure. This article focuses on the creation of the GWIF, a generic and adaptable Framework for integration of Web applications. example, we can name a few ones: Struts [4], Expresso [9], Echo [7], WebWork, Spring [12], and Tapestry. Some other applications in the Web are constructed with the use of the page-based applications platform. Basically, script languages are used, for example: Asp, Perl and Cgi. So, once all these facts are checked, one question has been frequently asked: How to integrate all the existing applications without changing their original code? The GWIF, considered in this article, suggests a form of integration of applications by offering services to some other new applications. The GWIF is adaptable; therefore the objective is "connecting" the Web servers with the supplier s services applications. Figure 1 illustrates the integration proposal for the GWIF, which will be able to "talk" to any other application developed in different Frameworks. 1. Introduction To compete in an efficient way, the companies need to reduce costs and increase the satisfaction of their customers and suppliers. This demands an integration of the existing applications. The integration of processes and systems has not been considered just a necessary item, in fact, it has been pointed out as an essential tool to the survival of the organizations in the future. The development of applications for the Web has modified some concepts that we are accustomed to dealing daily. A Web application is executed in distributed environment, and each part that composes the program can be located in one different machine. Currently, there are many Frameworks able to supply the development of Web applications from the Internet. These applications use different concepts, and they are developed by all kinds of manufacturers. For Figure 1: Illustration of the GWIF integration 2. Background and Related Work Web Frameworks are special Frameworks used to develop some Web applications. Currently, the use of Web Frameworks allows the creation of applications that have the main characteristics below: elaborated 1

graphic interfaces, high interactivity level, safety of data, execution efficiency, portability and extensibility. Applications based on Web Frameworks are characterized by their efficiency in the communication between the client and the server and HTTP protocol is generally used to make this process easy. The client just needs a simple browser able to "understand" it. The "decisions" that a Web application can take are accomplished in the server. A client of an application sends the requisitions to the server that processes them, and decides if it will be necessary to send an answer to the client. Generally, a problem observed in Web Framework s architecture is the weak support to the integration (EAI) with external applications or with legacy systems. Most popular Frameworks use the MVC model (Model View Controller) as a construction paradigm, and they are characterized by the easiness in the development of projects, implementation and maintenance, and by the efficiency of the generated applications [2]. Examples of Web Frameworks: NextApp Echo [7], Apache Struts [4], Jcorporate Expresso [9]. Other group of Web applications is based on the transmission of whole Web pages (Web Page Based Applications). This model of creation of applications is not updated, mainly because its implementation and maintenance are very difficult plus, the performance is not so good. In these applications, all the answers of the server to the client's requisitions happen by sending whole Web pages, Examples of these technologies: ASP, CGI, PHP and others. Large systems based on Web pages tend to be complex. The applications developed in Java Applets have limitations too. When invoked, an Applet must be totally discharged in the client's machine that must be capable to receive it, as well as making the Applet execution possible. As Applets just run on the client's side, there s no persistence of native memory in the client/server communication. The Spring Framework [12] considers the integration of its applications with the WebWork Framework and with some other Frameworks. However, the integration using Spring demands the addition of classes inside the source code of the classes of the WebWork to support this integration. The point is, to modify all the existing modules of an application has a very high cost. The GWIF does not demand the necessity of modifying the code of the providing applications of services. In 2002, new standards were introduced to address the problem of the integration and synchronization of Web Applications and their subset (sequence of) calls. BPEL [10] and WS-Coordination [11] are examples of these standards. BPEL (Business Process Execution Language for Web Services) [10] is an XML-based language designed to enable task-sharing for a distributed computing or grid computing environment - even across multiple organizations - using a combination of Web Services. Written by developers from BEA Systems, IBM, and Microsoft, BPEL combines and replaces IBM's Web Services Flow Language (WSFL) and Microsoft's XLANG specification. BPEL is also sometimes identified as BPELWS or BPEL4WS. Web Services can be combined to hold long-lasting business processes. BPEL could become a key standard for application integration and B2B processing, and it will likely be the basis of Microsoft and IBM's future application integration products. WS-Coordination (Web Services Coordination) [11] is a proposed IT industry standard of how individual Web Services [8] can interact in order to accomplish an application task. The WS-Coordination interface defines a context in which coordination is supposed to take place and the specific items of data to be exchanged so the transaction may be completed successfully as part of an overall business process defined in a Business Process Execution Language (BPEL) program. WS-Transaction is a great specification of what will be considered the completion of a transaction. Both, BPEL and WS-Coordination require changes in all applications. The code of all applications needs to be re-written to accomplish BPEL Language and to talk with Web Services. In GWIF, it will not be necessary to make changes in services that are already running. An adapter module will be joined to the Web servers to promote this integration. Web Services are also integration standard between some Web applications; but Web Services are based in the direct integration between the applications mentioned above and a Web Service, or even more, between two Web Services. GWIF, on the other hand, aims to integrate any Web applications, by deviating the calls, without changing their codes or using different applications and that is what is going to be shown in the following chapters. 3. Generic Web Application Integration Framework In Web applications, the elements are organized in the following structure: at one side, there is the Web client, normally a browser, that requests the data from a Web server, receives the answers, formats the 2

information and presents to the user. At the other side there is the Web server that receives the requisitions, reads the data from the hard disk and returns them to the user. This simple communication way is illustrated in Figure 2. Generally, the information is always recorded in the server side. The Integration level not only makes the communication with Web application level, but also with Web servers that give support to these applications. This detail is also shown in Figure 4. Figure 2: Direct communication between the user A and the Web server A. The GWIF considers the creation of an adapting module that will "intercept" and individually filter" the requisitions of the Web clients before their reaching the Server. The proposal presented is the "coupling" of an adapting module, called "GWIF Adapter", in the communications of the client with the server, without changing the application. Figure 3 illustrates this idea. Figure 3: Communication between the user A and the Web server A, with the GWIF adapter. With the addition of GWIF adapter module, the communication between the client and the server must happen normally, as if an intermediate element did not exist. The GWIF adapter is located at Web Server side. The process that implements it always starts at the same time the Web Server does. The architecture of GWIF Framework is presented in Figure 4. It is divided in 3 levels: The Web applications are located on the Web Application Level; The Integration level is composed by GWIF integration. This Level is responsible for the integration of Web applications of the previous level. The Final Application Level is formed by the final application, which is a result of the integration. Figure 4: The architecture of the GWIF. The transport protocol used in GWIF integration level is the HTTP. The GWIF Adapter communicates with the Web Server and with the client user interface through HTTP calls. In the current version, the GWIF makes no HTTPS calls. A GWIF adapter is a process connected to a specific integration. There is an individual relation between a Web Server, a GWIF adapter and a sort of clients application. In other words, for each kind of clients application, there is a unique implemented GWIF adapter to a specific Web Server. The GWIF creations as well as an adapter deploy happens with the intention of integrating one or more functions (or external access methods) of a Web application with another one. A GWIF adapter is specific, for this reason, in order to create it, it is necessary to inform which applications it will integrate, like the URLs from each Web Server and which functions will be integrated. This way, some deviation rules are created in the GWIF adapter nucleus. All these rules are created by the person responsible for the integration, through the specific GWIF adapter deploy at the moment of the integration. Some examples of deviation rules: If Client_App_A Call Function_X Deviate_To URL_Server_B. If Server_B Answer_Funcion_X_Client_A Deviate To URL_Server_A. If Client_App_B Call Function_Y Deviate_To URL_Server_C. If Server_C Answer_Funcion_Y_Client_B Deviate To URL_Server_B. From now on, we will call the services providing application of PA (Provider Application). PA is the application that will provide the service that will be used by the client application of the service, witch will be called CA (Client Application). In the illustrative example of Figure 5 there are three users (user A, user B and user C). These users have access to three servers (Web server A, Web server B and Web server C). 3

In Figure 5, the user A desires to make a request of service to Web server A; however the GWIF adapter that is connected to the Web server A "deviated" the request for the GWIF that is connected to Web server B, making the call to Web server B. There is a deviation rule in the GWIF adapters connected to Web Servers A and B that implement this deviation. This sequence of operations is detached in the red lines. In the example, user A is the CA of Web server B, and Web server B is PA of the user A. GWIF adapters connected to the PAs on the destination servers. 4. Implementation In this section it will be presented a test that uses the GWIF integration. The Apache Tomcat 5.0.25 Web server with Servlet version 2.4, Microsoft Web Server (with ASP) and Echo Framework version 1.0 were used for this implementation. Java was the programming language used to codify the GWIF Adapter Module. Figure 6 illustrates the schema of this implementation. Figure 6: Implementation example of ASP and Echo integration using GWIF. Figure 5: A generic example of integration among the users A, B and C; Web Servers A, B and C, and respective GWIF adapters. The user B desires to make a request of service to Web server B; however the GWIF adapter that is connected to the Web server B "deviated" the request for the GWIF that is connected to Web server C, making the call to Web server C. There is a deviation rule in the GWIF adapters connected to Web Servers B and C that implement this deviation. This sequence of operations is detached in the blue lines. In the example, user B is the CA of Web server C, and Web server C is PA of the user B. User C makes a request of service to its own Web server (Web server C). It is noticed that the GWIF adapter, connected to Web server C, just sends the request of the service to the server, this way there is no need to call another GWIF adapter from another external server. In this case, no deviation rules were used. This generic example shows the possibility of sharing services among the applications without having the necessity of rewriting its codes. The simple coupling of the GWIF adapter to Web servers results in the monitoring of all the requests of the users and, if necessary, they will be sent to other corresponding The integration of an application in ASP with another application in Echo Framework was made. The blue lines show the sequence of the use of a service by the user of ASP application in a Web server of the Echo application. There is a deviation rule in the implementation of both GWIF adapters, which play the role of guiders to this deviation. The GWIF adapter connected to ASP application deviates the request of ASP user for GWIF module of the Echo application that returns the reply to the requester. Figure 7: ASP Application: data entry screen and result of the query. The example of ASP application is of a financial one. ASP user wants to validate the credit of a person; however this service is not implemented in ASP server; but in fact, in the server of the Echo application. The ASP user fills the data on the screen, as shown in Figure 7, and submits to GWIF module that deviates the request for the Echo Web server. The Echo Web server uses the service that validates the 4

credit of the person, and in the case of the example, it answers with the negative reply (credit restriction). The credit was not approved because of not paid taxes in 2001. 5. Conclusions and Future Researches Currently, Web applications request a client with high level of interactivity. They have been developed on Web Frameworks that, among other advantages, simplify the tasks of processing the clients' requisitions and send the answers to the server. This paper proposes the GWIF Framework, generic Web application integration architecture to promote integration to any Web application. GWIF suggests the creation of an Adapter Module with deviation rules, whose objective is to intercept the clients' requisitions and provide the possibility of accomplishing calls in an external service without the need of rewriting the application code of this service. Any service from any Web application can be integrated with another application. This way, the increase of the flexibility of these applications incorporating the execution of functions that can be implemented externally from their domain was achieved. We were also successful in creating some new applications with GWIF in the integration of several Web Frameworks and with applications that use scripts: Echo, Struts, Asp, Jscript and others. About the future, we think about extending the use of the GWIF to allow the creation of automatic functions like locating services. The goal is to give the adapter the capacity to automatically locate a version of a service in Web that corresponds to the request of the clients service. The control of versions is also a problem to be investigated in future researches. Applications with the Leading Java Framework. Manning Publications Company. November 2002. [5] Avila, J.: Server-Side Java Programming for Web Developers. Scott/Jones Inc. El Granada, CA. 2001. [6] Burd, B. A.: JSP: Javaserver Pages. John Wiley & Sons, Inc. New York, NY. 2001. [7] NextApp Echo Framework White Paper.: Echo: The next-generation in Web application development. NextApp, Inc. 2003. http://www.nextapp.com. [8] Cerami, E., Web Services Essentials - Distributed Applications with XML-RPC, SOAP, UDDI & WSDL,O Reilly, February 2002. [9] Jcoporate Expresso Framework project. http://www.jcorporate.com. [10] Andrews, T., at all: Business Process Execution Language for Web Services Version 1..1 http://www- 106.ibm.com/developerworks/webservices/library/ws-bpel/, May 2003. [11] Cabrera, F., Web Services Coordination (WS- Coordination) http://msdn.microsoft.com/, 2002 [12] Spring Framework, http://www.springframework.org. 6. References [1] Hunter, J., and Crawford, W.: Java Servlet Programming. O Reilly, 1999. [2] Leff, A., and Rayfield, J. T.: Web-Application Development Using the Model / View / Controller Design Pattern, Fifth IEEE International Enterprise Distributed Object Computing Conference, September, 2001. [3] Sun Microsystems Java Servlet White Paper.: The Java Servlet API White Paper, Sun Microsystems, July 2004. http://java.sun.com. [4] Husted, T. N., Dumoulin, C., Franciscus, G., Winterfeldt, D., and McClanahan, C. R.: Struts in Action: Building Web 5