Developing Enterprise Solution with Web Services ...

5 downloads 3720 Views 448KB Size Report
nature of application. Web service based enterprise application development and integration approach resolves these issues. In addition, it also reduces cost, ...
International Journal of Web Services Practices, Vol. 4, No.1 (2009), pp. 11-17

11

Developing Enterprise Solution with Web Services Integration Vipul K. Dabhi, Harshad B. Prajapati, Varshil Doshi and Kadam Chokshi  Abstract— In developing enterprise solution, integration of inter-enterprise and intra-enterprise applications is a great challenge. Traditional approach of enterprise application integration (EAI) has drawbacks of: (i) scalability (ii) portability (iii) interoperability (iv) vendor dependency and (v) dynamic nature of application. Web service based enterprise application development and integration approach resolves these issues. In addition, it also reduces cost, efforts and time in comparison of other middleware technologies like RMI, CORBA, etc…. This paper presents the internals of Web services execution and involved components running on heterogeneous platforms. We present Web service based integration algorithm for integrating different subsystems. We identified university rechecking/reassessment procedure at our university as an application facing problems of integrating two subsystems existing on diverse platforms. For validation of our algorithm, we have demonstrated the implementation of this procedure using Web service based development and integration approach. The work presented in the paper would help in designing, implementing and integrating solutions for enterprise applications. Index Terms— Web service, WSDL, Enterprise Application Integration.

I. INTRODUCTION

A

pplication integration can be of three types: (i) Business-to-Business (B2B) application integration (ii) Enterprise Application Integration and (iii) Portal oriented integration. Business-to-business integration is combination of two or more application logic to share the information flow and application functionalities between partners. Enterprise application integration tries to integrate different applications to build a cooperating application structure. These applications can be developed in different programming languages and running on different platforms. Portal oriented integration concentrates on aggregating information from diverse enterprise applications to a single user interface. The fundamental challenge in developing an enterprise solution is integrating inter-enterprise and intra-enterprise Manuscript received January 21, 2009; revised April 1, 2009; accepted April 29, 2009. V. K. Dabhi is with the Dharmsinh Desai University, Nadiad 387001, GUJARAT, INDIA (phone: 91-268-2520502; fax: 91-268-2520501; e-mail: [email protected]). H. B. Prajapati is with the Dharmsinh Desai University, Nadiad 387001, GUJARAT, INDIA (e-mail: harshad.b.prajapati@ gmail.com). T. C. Author is with the Electrical Engineering Department, University of Colorado, Boulder, CO 80309 USA, on leave from the National Research Institute for Metals, Tsukuba, Japan (e-mail: [email protected]).

applications. The availability of diverse application development platforms makes the integrity problem more complex and difficult. The traditional approach of EAI focuses on solving of problems related to: (i) wire protocol conversion (ii) data format transformation (iii) routing messages between applications/systems. But this approach has drawbacks of: (i) expensive integration (ii) externalization of business rules and business logic from applications involved in integration (iii) single point of failure. Web service approach of integrating enterprise applications solves these problems. With the growing demand in development of enterprise applications, number of issues have evolved, major among them are: (i) scalability (ii) portability (iii) application integration (iv) interoperability (v) high availability (vi) reusability (vii) dynamic nature of application (viii) vendor dependency and (ix) fault tolerance. With Web service based application development it is possible to address these issues. Web service is an XML [6] based technology introduced by World Wide Web Consortium (W3C) for service based application development. A Web service is a software application that exposes its functionality using open and standard based web protocols to other applications or users. Web service allows applications to interoperate in loosely coupled environment. It also allows discovery and connection to services dynamically. Enterprise application development using Web services gives cost saving, time saving, vendor independency, and interoperability compared to middleware technologies like CORBA [10] and RMI [9]. Web service provide systematic and extensible framework for application-to-application interaction and integration. Web services use transport protocol to transfer data from one service to another. Different transport protocols can be used like HTTP, SMTP and FTP. Common understanding of data format is required for transferring and interpreting data between communicating parties over Internet. XML is the base format used by Web services for representing data. Simple Object Access Protocol (SOAP) [12] is a protocol specification that tells service consumer and service provider how to form, transmit and read a formatted XML message. Web services use the Web Service Description Language (WSDL) [11] to specify a service description. It provides information about (i) operations the service has made available (ii) messages the service will accept and (iii) the protocol to which consumer must bind to access the service. Universal Description, Discovery and Integration (UDDI) [15] is a specification of service interfaces to dynamically

ISSN 1738-6535 © Web Services Research Foundation

International Journal of Web Services Practices, Vol. 4, No.1 (2009), pp. 11-17 publish, discover and locate the description of Web services. WSDL description of services does not provide information about sequencing or relation between services. Business Process Execution Language (BPEL) is an XML grammar to describe business processes that are a result of composing two or more Web services. Two main technologies for Web service based applications development are: (i) Sun Microsystems’ Java Enterprise Edition (JEE) [7] and (ii) Microsoft’s .NET Framework [8] .NET framework is a product by Microsoft where as JEE provides set of standards which are implemented by different vendors. Table 1 gives the comparison of JEE and .NET technologies for developing Web service based enterprise application. An introduction to and role of SOAP, WSDL and UDDI in Web service based enterprise application development is given in [4]. Role and functionalities of SOAP toolkit in Web service based application development and comparison of different SOAP toolkits are given in [3]. The work in [5] discusses the requirements for service specification, categorization of service specification and tool to support automatic flow of information among architects, software designers, software developers and client. The design of small scale web application using Web service on java platform is discussed in [2]. The detailed comparison on two main technologies (e.g. .NET and JEE) for development of Web services and enterprise applications can be found in [1]. Details on enterprise application architecture, designing of Web service and application integration on java platform are given in [16]. This paper is structured as follows. Section II presents the internals of Web service calling mechanism and involved components. Section III presents steps for integrating business processes based on Web service approach. Section IV gives the introduction to rechecking/reassessment procedure and designing details of solution developed using Web service based approach. Section V presents implementation and integration details of Web services for rechecking/reassessment procedure. Section VI includes conclusion and future work.

TABLE I COMPARISON OF JEE AND .NET TECHNOLOGIES FOR WEB SERVICE DEVELOPMENT Criteria JEE .NET Portability Yes Only for Windows

MVC design pattern Scalability Maintainability Language Support Cost

Fully supported Low High Java Economic (As some freeware are available)

12 platform Partially supported High Low VB, C#, C++, Jscript High

II. INTERNALS OF WEB SERVICE EXECUTION AND INVOLVED COMPONENTS In this section, we explain internal working and execution of Web service. As shown in Fig. 1 Web service client is based on .NET platform whereas Web service implementation is on JEE platform. The figure clearly demonstrates involved components and interaction among them in Web service based solution. Steps for interaction between Web service client and Web service are as follows: Web service client processing: (1) Client code makes a service call by invoking the appropriate method. (2) The SOAP serializer of transformation layer converts this invocation into a SOAP request and forwards it to HTTP encoder. (3) The HTTP encoder of transformation layer wraps the SOAP message into HTTP request and sends it to server process. Web service server processing: (4) The HTTP request is handled by HTTP request handler of server process. (5) HTTP request handler forwards the HTTP request to SOAP servlet, which is provided by Web service container. (6) SOAP servlet uses HTTP decoding functionality of transformation layer to decode the HTTP request. (7) SOAP deserializer extracts the SOAP-XML and maps it to service (method) call. (8) SOAP servlet then makes a request to run service (method) call. (9) The Web service method is executed. (10) The result is forwarded to SOAP serializer of transformation layer to convert result into a SOAP message. (11) The HTTP encoder of transformation layer wraps the SOAP message in to HTTP request. (12) - (13) – (14) The HTTP response is forwarded to client. Web service client processing: (15) – (16) - (17) The HTTP decoder receives a HTTP response containing SOAP message. Then SOAP deserializer transforms the SOAP content to native language format and gives it to client code.

ISSN 1738-6535 © Web Services Research Foundation

International Journal of Web Services Practices, Vol. 4, No.1 (2009), pp. 11-17

13

Figure 1 Internal components and interaction steps in Web service invocation

The Web service description is separated from its implementation using transformation layer. The transformation layer is responsible for accepting the method call, transforming the method call into SOAP-XML format, encoding SOAP-XML message into HTTP request format. It is also responsible for decoding SOAP-XML data from HTTP response and transforming SOAP-XML data to native format. There are many SOAP transformation packages available for different platforms. For example (i) Microsoft SOAP toolkit (ii) Apache SOAP for Java (iii) SOAP Lite for perl. The selection of SOAP transformation package depends on language and platform used for developing Web service and Web service client. Different SOAP transformation package can be used by Web service client and Web service implementation. Thus using SOAP transformation package, Web service based interaction becomes interoperable among diverse platforms. III. ALGORITHM FOR INTEGRATING BUSINESS PROCESSES USING WEB SERVICE BASED APPROACH In this section we present an algorithm for integrating business processes using Web service based approach. Integrating enterprise business processes using Web service based approach are divided into five steps. The same methodology can be used for integrating inter-enterprise and intra-enterprise applications. The details of these steps are discussed below. 1) Identify business processes Identify business processes that can be transformed into services. To identify the business processes use the following criteria: (a) Number of input and output parameters should not be very high because the conversion of parameters to and from native format takes valuable time. (b) Business process should be doing a single function. It should be fine grained which makes it more reusable in different scenario. (c) Choose a business process with high business value. We also need to identify or locate the legacy code of business process. It may be the case that a business process can be found scattered across blocks of code in several modules. 2) Plan common data models

Algorithm 1: Integrating business processes using Web service based approach 1) Identify business processes Identify business processes that can be transformed into a service 2) Plan common data models (a) Prepare common data models and process data models (b) Design common and process schema using common data models and process data models. 3) Design interfaces (a) Design internal interfaces (b) Design sub-system specific interfaces (c) Design interconnecting interfaces 4) Wrapping of legacy business process code Generate a WSDL interface for legacy business process 5) Integrate business processes using Web services Integrate business processes by interconnecting common interface through Web service end points Figure 2 Algorithm for integrating business processes using Web service based approach

Identify all data models that are commonly used in different business processes. We define these data models as common data models. Find out common denominator (highest size and data type) of all the fields from common data models. Common data models will be used in integration interfaces while process data models will be used internally by process. Design common and process schema using common and process data models. 3) Design interfaces Three types of interfaces are required to be designed. (a) Internal interfaces: will expose core functionalities of particular sub-system or process. These interfaces are fine grained and highly coupled in nature. (b) Sub-system specific interfaces: will expose functionalities to end users through coarse grained interfaces. These coarse grained interfaces internally use fine grained interfaces. (c) Interconnecting interfaces: Interfaces using which one sub-system interact with other sub-system. These interfaces expose functionalities to other subsystems. These interfaces are cohesive in nature. 4) Wrapping of legacy business process code

ISSN 1738-6535 © Web Services Research Foundation, Seoul, Korea

International Journal of Web Services Practices, Vol. 4, No.1 (2009), pp. 11-17 The objective of wrapping process is to generate a WSDL interface for legacy code extracted in step 1. Two additional modules are required for (a) parsing incoming messages and extracting data from it. The extracted values are then used by wrapped component (legacy code module). (b) creating return message from result produced by wrapped component. 5) Integrate business processes using Web services Integration of two business processes is achieved by interconnecting common interface through Web service end points. As interfaces are well planned in planning step, integration of business processes will be easy and involves just configuration of endpoints. IV. DESIGN AND IMPLEMENTATION OF UNIVERSITY RECHECKING/REASSESSMENT PROCEDURE We developed the application for rechecking and reassessment of student’s exam marks at university level. The complete rechecking/reassessment procedure involves three main processes: (i) Student pays the fees and fills up the form for rechecking/reassessment by providing required information in it. (ii) The student submits the filled form to course faculty (iii) The course faculty will perform the rechecking/reassessment and provides the status or result of rechecking/reassessment to the student. At present, in this procedure, student pays fees at account department and gets blank application form for rechecking/ reassessment request. The account department records student’s roll no., semester and branch name only. Account department has acquired ms-sql database for the records storage. After doing rechecking/reassessment procedure, the faculty directly returns the status to the student. Here no records are maintained by faculty.

14

To solve this manual/paper work procedure we designed Web service for each process and integrated these Web services to provide online and automatic handling of rechecking/reassessment procedure. This application made rechecking/reassessment procedure effective, efficient, remotely accessible and helps in record maintenance. In order to separate the user interface features from the core application processing logic, we have used Model-View-Controller (MVC) design pattern in development of application. In JEE platform, Java Server Page (JSP) is used to create view, which uses Hyper Text Transfer Protocol (HTTP) to send or receive data. The servlet is used as a controller that handles the requests from views and invokes methods of model. JavaBeans or Java class can be used to represent the model, which encapsulates core functionality of accessing Web service and database activity. Active Server Page (ASP) is used to create views in .NET, platform, while functionalities of model and controller are combined in C# classes. The application uses three Web services: one service is related to student and other two are related to faculty. The student Web service deals with putting rechecking requests and retrieving reassessment status. Both these processes involve verification of student. The student Web service is developed on JEE platform and uses ms-sql database. Two Web services for faculty are: (i) downloading rechecking/reassessment requests of students (ii) updating rechecking/reassessment status. The first is developed on JEE platform, whereas second is developed on .NET platform.

TABLE II DETAILS OF INVOLVED ACTORS, WEB SERVICES AND DATA STORAGE IN UNIVERSITY RECHECKING/REASSESSMENT PROCEDURE Scenario Actor Client Web Service Web Service Description Database No. Software Development Platform Platform 1 Student JEE based JEE based Main (ms-sql)  Authentication of student  Submit rechecking/reassessment request  Check status of requests 2 Faculty .NET based JEE based Main (ms-sql)  Authentication of faculty  Fetch Rechecking/reassessment requests from main database and delegating it to .NET service for further processing. .NET based  Stores downloaded rechecking/ Temporary reassessment requests in temporary (ms-access) database 3 Faculty .NET based .NET based  Fetch rechecking/reassessment Temporary (ms-access) requests from temporary database JEE based  Update rechecking/reassessment Main (ms-sql) status (marks) in main database

The faculty Web service developed on the JEE platform deals with authentication of faculty, retrieving rechecking requests and sending these requests to .NET service and updating rechecking requests by modifying old marks. The faculty Web service developed on the .NET platform deals with the obtaining the requests from the JEE service and displaying these requests to the faculty and deleting entries

from the temporary database residing on the .NET server. Application uses two databases: (i) Main database, which stores information related to students, faculties, rechecking requests submitted by the students, and status or result of rechecking requests. (ii) Temporary database is used to show the number of pending rechecking/reassessment requests for faculty. When the status or result is updated by faculty for a

ISSN 1738-6535 © Web Services Research Foundation, Seoul, Korea

International Journal of Web Services Practices, Vol. 4, No.1 (2009), pp. 11-17 particular rechecking/reassessment request, that request details will be removed from temporary database and updated in main database. The two databases are located on different nodes. Fig.3 shows the configuration and protocols used by involved components in developing solution for rechecking/reassessment procedure.

Figure 3 Configuration and protocols used by involved components

15

V. RESULT AND DISCUSSION Scenarios: (i)

Scenario 1: Interaction and processing for submitting rechecking/reassessment request by student. Student has to pass the information like studentid, rollno, branch, semester and receiptno from the view. In turn this information will pass on to concerned model via controller. Model invokes verifystudent Web method of StudentJEE Web service for verification. After successful authentication, student makes new request for rechecking/reassessment by providing required information: semester no., branch, subject and type of exam. (i) Scenario 2: Interaction and processing for downloading rechecking/reassessment requests in temporary database by faculty. Faculty need to authenticate himself before downloading rechecking/reassessment requests submitted by students. For authentication, faculty provides the necessary details: loginid, password and the branch. After successful authentication, faculty can invoke FacultyJEE Web service to fetch rechecking/reassessment requests related to faculty from main database (my-sql). These requests are delegated to Faculty.NET Web service for further processing. Faculty.NET Web service stores these requests into temporary database (ms-access).

Figure 4 Scenario 1: Interaction and processing for submitting rechecking/reassessment request by student.

ISSN 1738-6535 © Web Services Research Foundation, Seoul, Korea

International Journal of Web Services Practices, Vol. 4, No.1 (2009), pp. 11-17

16

Figure 5 Scenario 2: Interaction and processing for downloading rechecking/reassessment requests in temporary database by faculty

(ii)

Scenario 3: Interaction and processing for updating status of rechecking/ reassessment requests into main database by faculty. After the rechecking requests are passed between Web services running on heterogeneous platform, Faculty.NET Web service retrieves the rechecking/reassessment requests

from temporary database and passes it to the .NET client for display purpose. The faculty rechecks the student exam paper. If marks get changed, faculty updates the marks by calling the JEE Web service from .NET client. After the marks have been updated, the rechecking request is deleted from the temporary database to keep only pending requests.

Figure 6 Scenario 3: Interaction and processing for updating status of rechecking/reassessment requests into main database by faculty.

ISSN 1738-6535 © Web Services Research Foundation, Seoul, Korea

International Journal of Web Services Practices, Vol. 4, No.1 (2009), pp. 11-17 VI. CONCLUSION AND FUTURE WORK We identified and discussed issues involved in integration of applications towards realization of enterprise application. Major issues are scalability, interoperability and portability. We also discussed how an open, standard based, Web service based solution resolves these issues. We identified university rechecking/reassessment procedure at our university as an application facing problems of integrating two subsystems existing on diverse platforms. We have demonstrated the implementation of this procedure using Web service based approach which would help in designing, implementing and integrating solution for enterprise applications. We are automating different procedures involved at department and university level. Important features which we would like to incorporate in automated handling of procedures/activities are: (i) scalability of enterprise application (ii) security of data and communication over Web service protocols (iii) automation of long living business activity using Web orchestration and choreography. We are analyzing and modeling solution using UDDI [15], WS-Security standards [16] and BPEL for complete automation of activities with the emphasis on above stated features. REFERENCES [1]

[2]

[3] [4]

[5] [6] [7] [8] [9]

[10] [11] [12] [13] [14]

Ahuja, S.P. and Clark, R. “Comparison of Web services technologies from a developer’s perspective” In Proceedings of the International Conference on Information Technology: Coding and Computing (ITCC’05)- Vol. II, pp 791-792 April 4-6, 2005. Dezhgosha, K. and Angara, S. “Web services for designing small-scale Web applications” IEEE International Conference on Electro Information Technology, May 22-25 2005. Panagiotis Louridas, “SOAP and Web Services”, IEEE Software, vol. 23, no. 6 pp. 62-67, November 2006. Curbera, F., Duftler, M., Khalaf, R., Nagy, W., Mukhi, N., and Weerawarana, S. “Unraveling the Web services web: an introduction to SOAP, WSDL, and UDDI”, IEEE Internet Computing, vol. 6, Issue 2, pp.86-93, March-April 2002. Jones, S. “Toward an Acceptable Definition of Service” IEEE Software, vol. 22, Issue 3, pp.87-93, May-June 2005. Roy J. and Ramanujan A. “XML: Data’s Universal Language” IT Professional, pp.32-36, May-June 2000. Java EE, http://java.sun.com/javaee .NET, http://www.microsoft.com/NET RMI Wire Protocol, Java Remote Method Invocation Specification, Sun Microsystems, 1999; http://www.javasoft.com/docs/rmi/spec/rmiTOCdoc.html OMG, “The Common Object Request Broker Architecture and Specification”, Object Management Group, Framingham, MA, 1998. WSDL Specification, http://www.w3.org/TR/wsdl SOAP specification http://www.w3.org/TR/soap Microsoft’s Web services site, http://msdn.microsoft.com/webservices UDDI Specification, http://www.uddi.org/pubs/ WS-Security Specification http://docs.oasis-open.org/ wss/2004 McGovern, J., Tyagi, S., Stevens, M., and Mathew, S. Java Web Services Architecture, Elsevier, 2005.

ISSN 1738-6535 © Web Services Research Foundation, Seoul, Korea

17