Developing Java Web Services to Expose the WorkTrak RMI Server to the Web and XML-Based Clients

Developing Ja Web Services to Expose the WorkTrak RMI Server to the Web and XML-Based Clients Roochi Sahni Abstract-- One development on the Internet involves a group of open standard technologies referred to as Web services. They give functionality to the Internet by providing Webbased applications that are accessible by any computer that is connected. The main platform for Web services is Extensible Markup language (XML); it provides a way for the different operating systems, or programming languages to be able to communicate. The application developed in this project made it possible to optimize distributed work-group cooperative activities using a workflow system by developing and publishing Web services with Axis using Ja. Creating a test client to test against web methods. The WorkTrak application is made up of three major components: Remote Method Invocation (RMI) server, Web application for the workflow clients, and Ja Web services to expose the WorkTrak RMI server to the Web and XML-Based clients. Apache Axis provides for automated deployment of Ja programs as Web services by generating Web Services Description Language (WSDL) from Ja code directly. A client program sends a request to the Web service. The Web service makes remote procedure calls to a distributed Ja (RMI) application and forwards the response encoded in the Simple Object Access Protocol (SOAP) to the client. A. Background I. INTRODUCTION A Web service is a related collection of methods exposed to clients via standardized communication protocols and data formats, namely HTTP and XML. These services allow programs to make Remote Procedure Calls (RPC) against an object over the Internet or a network using platformneutral standards to hide the implementation details from the client. The messages sent between the client and server is encoded in an XML called Simple Object Access Protocol (SOAP). SOAP defines a standardized way of accessing functionality on remote machines. Web services adapt the traditional Web-programming model for distributed application development. Web programming models are loosely coupled and remarkably interoperable. They provide a simple Application Programming Interface (API) for Web services based on mapping SOAP messages to method invocations. The fundamental concept driving Web services is that clients and the servers can use any technology, any language, and any device. The way they access a Web service is the same: SOAP over HTTP. The other category of programming model, known as the component object-programming model, is distributed application logic; examples include Microsoft s Distributed Component Object Model (DCOM), Object Management Group s Common Object Request Broker Architecture (CORBA), and Sun s Remote Method Invocation (RMI). Although these component-based models work very well in an intranet environment, attempting to use them over the Internet presents two significant problems. First, the models do not interoperate. Second, their focus on RPC style communication typically led to tightly coupled systems built around the explicit invocations of object methods. For this reason, Ja API for XML-Based RPC (JAX-RPC), which makes it possible to write an application in the Ja programming language that uses SOAP to make an RPC, will be implemented in the workflow system. Thus, interoperability across clients and servers in WorkTrak will be demonstrated [10]. B. Problem The purpose of this project is to optimize distributed workgroup cooperative activities using a workflow system by developing and publishing Web services and their clients with Axis using Ja. The study will demonstrate the fundamentals of building, running and invoking Web service interfaces using Web Services Description Language (WSDL) as well as Ja RMI. Each of the Web services is analyzed in detail in the "Methodology" section. To expose WorkTrak server to Web and XML-Based clients request/response, the application was tested against Sujatha Sundaram s Worklist handler for WorkTrak for Workflow Management System and Krithiga Priyadarshini s Process Management Console for WorkTrak Workflow Manangement System. C. Scope This project demonstrates a way of designing and implementing a WorkTrak, a workflow system that uses

Web services. The system is built on Ja RMI and allows defining activities, identifying their interactions, products and performers. The WorkTrak to be designed is made up of the three major components: RMI server, Web application for workflow clients, and Ja Web services to expose the WorkTrak RMI server to the Web and XML- Based clients. In this application, Ja bindings or classes are generated from a WSDL description and the JAX-RPC runtime for the remote access to the service. By using JAX- RPC and SOAP, XML processing details are shielded and show a way of writing the whole application entirely using Ja technology. As a result, this provides extensive support for accessing Web services. D. Assumption Several criteria are to be met before undertaking this study. First, the application to be presented must consist of the following pieces: 1. Apache Axis, an open source SOAP server & client which provides the functionality to install, access and maintain Ja Web services through JAX-RPC API, 2. Apache Tomcat Servlet Container for running Axis. 3. A distributed (RMI) application, an API for making RPC. 4. WSDL, a schema that generates a service description for the deployed service. 5. Set of compilers to convert WSDL to Ja RMI and vice versa and to generate client and server SOAP stubs/skeletons. and deployed on the Ja platform. Conversely, a client written in a Ja programming language can communicate with the project s Web service. G. Approach This project was started with collecting all the materials and installing all the necessary tools for the project. This included searching the Internet, reading relent reference books, and downloading the necessary sources for this project. On gaining a fairly good understanding regarding the application, the following approach was used: 1. Conducted detailed analysis of workflow to help an organization adnce its process capability maturity. 2. Installed the binary distribution of the WorkTrak Ja activity tracker application that allowed participant access to the RMI WorkTrak server. 3. Installed the current versions of Tomcat and Axis. 4. Designed the Web services including all the Web methods, and then debugged and ran them first, with Ja. 5. Created the build file that the Ant tool used to build and deploy the Web services. 6. Used the deployment descriptor to dispatch SOAP messages to appropriate Ja class. 7. Created a test client to test against all the Web methods. H. Materials and Equipment E. Limitations In this project, components of distributed applications would not be allowed to communicate at the object level. The SOAP protocol begins with the business logic of application learning methods and parameters to call from a WSDL document. This whole process is time-consuming, which requires rious levels of XML parsing and XML lidation and hence harbors many of performance and scalability problems. Also there are issues related to session management since SOAP is a stateless messaging protocol. As a consequently, Apache Axis, a third party product, needs to be implemented to maintain the state. Due to these limitations, the results of this study may not be applicable beyond the scope defined herein. F. Standards The following are criteria for this project. It must ensure that Web service would be interoperable across clients and servers. A client written in a language other than the Ja programming language can access a Web service developed The following system requirements are necessary in order to implement the WorkTrak system: 1. Windows 2000/Windows XP. 2. Ja version 1.4 or greater for Web services. 3. Apache Tomcat Servlet Container for running SOAP Engine. 4. Apache Axis for constructing SOAP processors such as clients, servers, and gateways. 5. ANT, a free build tool for Ja. 6. WorkTrak RMI server. 7. Parsers that convert WSDL to Ja and vice versa. 8. System support of XML language. 9. Microsoft Visual Studio.NET to create test client using C#. II. REVIEW OF LITERATURE A. The concept of Web services In essence, a Web service can be considered as Application logic accessible to programs via standard Web protocols in a platform-independent way [6]. Web services

are self-contained modular business applications that have open, Internet-oriented, standards-based interfaces. Web services are a set of standards and technologies that enable distributed applications. This standard-based communication allows Web services to be accessed by customers, suppliers, and trading partners independent of hardware, operating system or even programming environment. platform-neutral syntax for communicating data and a means of defining and verifying the structure of the data being communicated [4]. XML is not tied to any platform and language, so any Web-enabled device can exchange XML messages with another such device. To make sure that a client makes the right request and a server provides the right response, both client and a server need to share technology and design. B. Motition The Web services paradigm has the potential to deliver many benefits for both internal interaction and interaction over the Internet [4]. These include: 1. Business agility --- Developers will be able to respond quicker with the demanding business needs to link up partners or to provide access to existing business assets within the firewall. 2. Interoperability --- Functionality from heterogeneous development platforms (NET, CORBA, J2EE) can be quickly integrated into business applications. 3. Platform-agnostic --- The Web services paradigm, being platform agnostic, solves the basic Enterprise Application Integration (EAI) problem of having uniform interfaces to business applications. In the future, packaged software applications will expose service-oriented interfaces based on Web service standards. 4. Leverage --- Investments made in Internet infrastructure can be leveraged to provide new channels for providing service to customers. 5. Ubiquity --- Current applications that have developed in any language can be quickly exposed as Web services using Web services tools. Web services tools will be ailable on all development platforms. 6. Investment protection --- The service-oriented paradigm that Web services build on promotes the use of clean interfaces that allow a business asset being wrapped by an interface to be replaced, changed, or outsourced as business needs require without affecting customers or business processes that depend on the asset. 7. Component reuse --- Developers will be able to use a large number of Web services provided by third parties to deliver more powerful and integrated business solutions. C. Realizing Web services with XML The Web service paradigm is about interoperability and platform-neutral communications as opposed to a specific development language, component model, and platform issues. XML is the key to providing a standardized, D. Standards for Web services The Web service standardization effort begins with a common wire format (SOAP), a standardization means of describing access and interaction with Web services (WSDL), and a registry (UDDI). These include: 1. SOAP (Simple Object Access Protocol) defines a simple way for information exchange within a distributed environment. It is a simple model to envelope request and response messages encoded in XML that consists of three parts: an envelope describing what is in a message and how to process it, encoding rules for transporting userdefined data types, and a convention for describing remote procedure calls and returns [3]. See: http://www.w3.org/tr/soap 2. WSDL (Web Services Description Language) is an XML format schema for describing abstract service interfaces, service endpoints, and protocol bindings for accessing services. It enables the Web service s methods in any system to be interpreted and understood by one another through the Internet [4]. Seven major elements are used to define services: Types --- Data type definitions container with some type system. Message --- Abstract type definitions of communication data. Operation --- Abstract description of one message flow of the endpoint. Port Type --- Abstract set of operations expected by a particular endpoint type. Binding --- Transport and Encoding for a particular port type. Port --- Network address of an endpoint and its binding. Service --- Collection of related endpoint [8]. See: http://www.w3.org/tr/wsdl 3. UDDI (Universal Description, Discovery and Integration) is a specification that defines a service registry of ailable Web services, serving as global electronic yellow pages. UDDI enables a company to publish a description of ailable services to the registry, announcing itself as a service provider. Service users can send requests

conforming to the UDDI schema as SOAP messages to the service registry to discover a provider for services [8]. See: http://www.uddi.org E. Web services building blocks The following graphic shows the core building blocks needed to facilitate remote communication between two applications. Discovery UDDI, DISCO Description WSDL, XML, Docs Sujatha Sundaram s Worklist handler for WorkTrak for Workflow Management System and Krithiga Priyadarshini s Process Management Console for WorkTrak Workflow Manangement System. The Binary Distribution of WorkTrak server and Process Manager client used in this project was written & developed by Lindquist [1 ]. Calling the Web services and obtaining the results require the construction of a SOAP message containing the query parameters, transmission, receipt of the response message, and conversion back from XML to Ja objects. Client Application IIS Tomcat RMI Domain Web Server Axis Server MESSAGE FORMAT SOAP ENCODING XML Client ASP. NET Ja Web services TRANSPORT HTTP, SMTP F. Summary Figure 0: Web services building blocks Proxy HTTP Request SOAP Ja Objects Figure 0: Architecture overview Web services are an umbrella term that describes a collection of industry-standard protocols and services used to facilitate a base-line level of interoperability between applications. The industry support that Web services have received is unprecedented. One of the contributing factors to the success of Web services is that they are built on existing Internet standards such as XML and HTTP. As a result, any system capable of parsing text and communicating via a standard Internet transport protocol can communicate with a Web service. A. Theory III. METHODOLOGY This study involves a review and verification of secondary data and a collection of information for the particular scenario defined in the scope. This project mainly developed a 3-tier architecture system to handle multi-way communication among clients, application server and server. The 3-tier architecture is shown as Figure. In this project a framework is developed to help Web & XML- Based clients to use RMI services. Web services developed with Ja registered on Tomcat/Axis is the middleware. WorkTrak RMI server is the back-end database server. Test client developed with C# is the front-end. After the procedure mentioned in this project was completed, the whole application was handed to the other group for testing. To expose WorkTrak server to Web and XML-Based clients request/response, the application was tested against B. Dependent technologies The material and equipment used in this project are listed above. These tools are necessary for creating, deploying and accessing Web services. C. Procedure This project mainly included the following procedure: 1. Installing & running WorkTrak RMI server. 2. Creating Ja Web services for Activity, Definition & Process management clients. 3. Locating WorkTrak RMI server 4. Deploying Ja Web services under Tomcat/Axis. 5. Developing client applications to test the Web service functionality. C.1. Install & run WorkTrak RMI server The Binary distribution of the WorkTrak Ja activity tracker application is ailable at http://pooh.east.asu.edu/lindquist/worktrak/worktrak.html [1]. WorkTrak is a Ja swing application that allows participant access to the RMI WorkTrak server. Refer figure 0 for running RMI WorkTrak server. The Client provides Process, Definition and Activity management activities as supported by the server. Steps are listed below:

1. Install by extracting the jar file as: jar -xvf worktrakbinary.jar 2. Edit the WorkTrak/policyRmid file as mentioned in WorkTrak/readmeBinary. 3. Start the server with the command: ant server DhostId=yourHostName (Where yourhostname determines the hostname of the machine and can be determined by ipconfig/all command on windows) store information about roles involved in workflow respectively. 7. WFAgentWS and WFAgentWSImpl: An Interface and Implementations class to manage information about the workflow agents respectively. C.3. Locating WorkTrak RMI server This project was implemented as a 3-tier distributed application. Web services communicated with the server side using Ja RMI for communication. The RMI distributed application uses the registry to obtain a reference to a remote object. The server calls the registry to associate a name with a remote object. The client looks up the remote object by its name in the server s registry and then invokes a method on it; thus providing support for the communication between the server and the client. Web services do the look up of the remote object by the following: public WFServer srv; Figure 0: version). C.2. Creating Web services WorkTrak RMI Server running(older This project used Ja to create the Web services. To achieve it, several Interface and Implementation Ja classes were created for the service with public methods. 1. WFActivityWS and WFActivityWSImpl: An Interface and its Implementation class used by workflow clients to access enacted activities respectively. 2. WFProcessWS and WFProcessWSImpl: An Interface and its Implementation class for process enactments respectively. 3. WFActivityDefWS and WFActivityDefWSImpl: An Interface and Implementation class used by workflow clients to access activity definitions respectively. 4. WFProcessDefWS and WFProcessDefWSImpl: An Interface and Implementation class for process definitions respectively. 5. WFProductWS and WFProductWSImpl: An Interface and Implementation class used to store information about work products involved in workflow respectively. 6. WFRoleWS and WFRoleWSImpl: An Interface and Implementations class used to public WFRoleWSImpl(){ String hostid= DDT95L21 ; String regport= 2222 ; try { srv = (WFServer)Naming.lookup("rmi://" + hostid + ":" + regport + "/WorkTrak"); } catch (Exception e) { System.out.println("Exception :" + e.getmessage()); e.printstacktrace(); } } setrmiurl method was used to reset the Naming.lookup URL for different clients. C.4. Deploying Ja Web services under Tomcat/Axis The steps to deploy Web services are: 1. Start Tomcat/Axis. 2. Create build.xml to compile the Web services. It is the file that the Ant tool uses to build and deploy the Web application. Refer figure 1 for build.xml.

Figure 2: deploy.wsdd After calling this deploy.wsdd file, all the deployed Web services can be viewed at: http://localhost:8080/axis/servlet/axisservlet Figure 1: build.xml 3. Jar all the class files and copy it to: Tomcat/webapps/axis/WEB-INF/lib directory. 4. Use Axis Web Service Deployment Descriptor to deploy the service. deploy.wsdd is created; it is an XML service deployment descriptor format. The following WSDD file is created to deploy all the implementation classes. The WSDD file describes the information needed to dispatch SOAP messages to the appropriate Ja class [2]. The outermost element tells the engine that this is a WSDD deployment and defines the ja namespace. <service name= WFProcessWSImpl provider= ja:rpc > tells the service name and the provider. <parameter name= scope lue= request /> specifies the scope of the service. In this case, the scope is request, which means a new service object will be generated to handle each request. There are two other scopes, session and application. If it is session, a single object will handle all requests from one client. If it is application, a single object will deal with all clients requests. <parameter name= classname lue= WorkTrak.wsserver.WFProcessW SImpl /> describes the package providing the service. <parameter name= allowedmethods lue= * /> specifies all the methods that the class is allowed to dispatch. Figure 3: Deployed Web services The WSDL file is generated dynamically from the deploy.wsdd file and reflectes over the Ja class. WSDL is the key to building Web services. Axis consumes the WSDL automatically to produce clients and produce WSDL from deployed services. As a result, all Web services were deployed.

<jac srcdir="${src}/client" destdir="${build}"> <classpath refid="compile.classpath"/> </jac> </target> Figure 4: Browsing the WFRoleWSImpl WSDL The WSDL description for WFRoleWSImpl is ailable by accessing the URL: http://localhost:8080/wfrolewsimpl?wsdl Similarly, Axis automatically provides the WSDL description for deployed Web services by appending?wsdl to the URL of any deployed service. 5. Shutdown and restart Tomcat/Axis. Using Ja Web Services, now that all Web services are published, Test client program was created to use them. First, glue code for the client was generated. The glue code can be automatically generated from the WSDL description for WFActivityWSImpl, WFProcessWSImpl, WFActivityDefWSImpl, WFProcessDefWSImpl, WFAgentWSImpl, WFRoleWSImpl, WFProductWSImpl web services using the WSDL2Ja tool: Below is the deployment of one of the Web services WFRoleWSImpl and the rest of the Web services was done in a similar way. >ja org.apache.axis.wsdl.wsdl2ja http://localhost:8080/axis/wfrolewsimpl?wsdl Or compiled using build.xml <target name="wsdl2jadescription="call the axis WSDL2Jautility to create a proxy"> <ja classname="org.apache.axis.wsdl.wsdl2ja" fork="yes" dir="${src}/client"> <classpath refid="compile.classpath"/> <arg lue="http://localhost:${urlport}/axis/services/w FRoleWSImpl?wsdl"/> </ja> </target> <target name="compileclient" depends="wsdl2ja" description="compile client Ja sources"> This command produces a subdirectory called localhost that contains Ja source code files names: 1. For WFActivityWSImpl: WFActivityWSImpl.ja WFActivityWSImplService.ja WFActivityWSImplServiceLocator.ja WFActivityWSImplSOAPBindingStub.ja 2. For WFProcessWSImpl: WFProcessWSImpl.ja WFProcessWSImplService.ja WFProcessWSImplServiceLocator.ja WFProcessWSImplSOAPBindingStub.ja 3. For WFActivityDefWSImpl: WFActivityDefWSImpl.ja WFActivityDefWSImplService.ja WFActivityDefWSImplServiceLocator.ja WFActivityDefWSImplSOAPBindingStu b.ja 4. For WFProcessDefWSImpl: WFProcessDefWSImpl.ja WFProcessDefWSImplService.ja WFProcessDefWSImplServiceLocator.ja WFProcessDefWSImplSOAPBindingStu b.ja 5. For WFAgentWSImpl: WFAgentWSImpl.ja WFAgentWSImplService.ja WFAgentWSImplServiceLocator.ja WFAgentWSImplSOAPBindingStub.ja 6. For WFProductWSImpl: WFProductWSImpl.ja WFProductWSImplService.ja WFProductWSImplServiceLocator.ja WFProductWSImplSOAPBindingStub.ja 7. For WFRoleWSImpl: WFRoleWSImpl.ja WFRoleWSImplService.ja WFRoleWSImplServiceLocator.ja WFRoleWSImplSOAPBindingStub.ja These Ja source files contain the glue code needed to find the Web services, connect to them, and encode/decode SOAP envelopes. C.5. Testing Ja Web services with a sample client

To use the Web services from a client, a Ja program requires importing the localhost namespace, creating the service, and invoking method within the web service. This client uses the ServiceLocator class of the Web services to find and connect to different Web services. An instance of the service represents the connection that can be used to invoke individual methods within the Web services. A. Steps IV. RESULTS AND CONCLUSIONS The following are the steps to run this 3-tier architecture system. 1. Start Tomcat --- Under a DOS command prompt. Type the following: >%CATALINA_HOME%/bin/startup.bat The %CATALINA_HOME% is the Tomcat home directory. 2. Start WorkTrak RMI server, from the directory where it was install. Type the following: >ant server DhostID=yourHostName yourhostname determines the hostname of the machine and can be determined by ipconfig/all command on windows. 3. Start a DOS command. Under the directory of project. Type the following: >ant deploy 4. All the 7 Web services were registered with Axis. It can be accessed via browser at: http://localhost:8080/axis/servlet/axisservlet 5. Shutdown and restart Tomcat/Axis 6. Start Visual Studio.NET command prompt. Under the directory of project. Type the following: >ant csclient The client application is started. Users could use this application to test Web services functionalities. services using Axis, a client written in a language other than Ja program can access a Web service developed and deployed on the Ja platform. Support for SOAP and WSDL makes this interoperability possible. SOAP defines standards for XML messaging and the mapping of data types so that applications adhering to these standards can communicate with each other. A WSDL description, being an XML document that describes a Web service in a standard way, makes the description portable. D. Limitations with Axis E. Results 1. Start Arbitrary Objects Axis does not allow communicating at object levels. With RMI it is possible to send and receive Serializable Ja objects, as Ja is running at both ends. Axis only sends objects for which there is a registered Axis serializer. Arbitrary Ja objects cannot be sent. 2. Remote references It is not possible to return an object reference and expect the caller to be using it as the endpoint for SOAP calls or as the parameter in other calls. Instead, a reference mechanism, such as HashMap with numeric or String keys, can be passed over the wire [2]. Results of this study show that Web services in Ja using Axis is a powerful tool that offers developers the opportunity to create interoperable Web applications. Consumers can use this system to optimize distributed work-group cooperative activities, define and enact activities as well as identify interactions, products and performers. Thus, Activity Managers can maintain enactment and sequence of defined activities to represent a group carrying out work without requiring every participant of this group to adopt and use this workflow tool. B. Ja Web services with Axis Ja Web services with Axis provide strong command line tools to the development and deployment of Web services. Generating WSDL files and passing SOAP messages are done by Apache Axis tool. Axis provides facilities to install, access, and maintain Ja Web services. Finally, all applications are deployed on Apache Tomcat server. C. Interoperability The most important requirement for a Web service is that it be interoperable across clients and servers. With Ja Web F. Conclusions and Future Work A Web service, a server application that implements the procedures that are ailable for clients to call, is deployed on a server side container. Web services can help achieve higher levels of integration between rious platforms, languages and applications. The application in this paper shows that different platforms and programming languages can be integrated in real-life scenarios using Web services technology. In the future, this project can be developed to explore and extend the Web services functionalities in more detail.

V. REFERENCES [1] Lindquist, T.E. The Binary distribution of the WorkTrak Ja activity tracker application http://pooh.east.asu.edu/lindquist/worktrak/worktrak.html [2] Axis, Apache Axis 1.1 http://ws.apache.org/axis/ [3] World Wide Web Consortium, Simple Object Access protocol (SOAP) 1.1, Ailable HTTP: http://www.w3.org/tr/soap [4] hp web services, web services concepts a technical overview http://hpmiddleware.com/downloads/pdf/web_services_tec h_overview.pdf [5] Sun s Ja, Introduction to Web Services http://ja.sun.com/webservices/docs/1.3/tutorial/doc/ [6] R. Basiura, M. Batongbocal, M. Clark, A. Eide, R. Eisenberg, D. Lee, B. Loesgen, C. Miller, M. Reynolds, B. Sempf, S. Sikumar, PROFESSIONAL ASP.NET Web Services. Chicago: WROX Press, 2001. [7] R. Nagappan, R. Skoczylas, R. Sriganesh, Developing Ja Web Services: Architecting and Developing Secure Web Services Using Ja. Indianapolis, IN: John Wiley & Sons, 2002. [8] World Wide Web Consortium, Web Services Description Language (WSDL) 1.1, Ailable HTTP: http://www.w3.org/tr/wsdl/ [9] PCIS2 Architecture specification version 1.0 (Lindquist, T.E. Editor), The US-France Technology research and Development Project on Software Tools, SPAWAR Systems Center, San Diego CA 1998. [10] Chappell, A. D., Jewell, T. Ja Web Services. Sebastopol, CA: O Reilly & Associates, 2002. [11] Priyadarshini, K. Process Management Console for WorkTrak Workflow Manangement System. [12] Sundaram s S. Worklist handler for WorkTrak for Workflow Management System. [13] Lindquist, T.E. Basics of workflow http://pooh.east.asu.edu/cse562/classnotes/workflow/wf WorkflowProcess.html