Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Web Services Simulator
                                                                                           (A Use C...
Web Services Simulator
                                                                                            (A Use ...
Web Services Simulator
                                                                                          (A Use Ca...
Web Services Simulator
                                                                                              (A Us...
Upcoming SlideShare
Loading in …5
×

Web services simulator

1,247 views

Published on

Web Services Simulator is an indispensible tool that can be put to a variety of uses during all the phases of SOA implementation

Published in: Business
  • Be the first to comment

  • Be the first to like this

Web services simulator

  1. 1. Web Services Simulator (A Use Case, by Krish Khambadkone) The value of simulation for ensuring the smooth implementation of IT projects is clear. With that said, a Web Services Simulator is an indispensible tool that can be put to a variety of uses during all the phases of SOA implementation. I want to illustrate the several uses of such a simulator while describing a valid use case. Use Case This example is drawn from a scenario that we experienced during a very large implementation for a leading Insurance Provider. Scenario: The Insurance Provider was in the process of implementing a cutting edge self-service portal where individual customers could purchase Auto Policies online that were tailored to their specific needs. The Portal technology was implemented using the Websphere Portal Stack in conjunction with a few open source custom built products. All the backend processing and information would be provided by a Legacy EIS system and exposed as web services to be consumed by the Portal. Ground Reality: There were two separate teams responsible for implementing the Front End Portal Layer and the web services layer for exposing the backend Legacy Interfaces. The Portal team had all the wireframes ready for implementation—say by July. However, the wireframes and screen transitions could not be tested without the actual web services that supported each screen. The team that was responsible for implementing the web services could deliver the first service by October at the earliest. Hence the resulting time lag of nearly 3 months where the Portal team would not be able to proceed with their work. 16/09/10 Page 1 of 4
  2. 2. Web Services Simulator (A Use Case, by Krish Khambadkone) Solution Options: It was decided to use a web services simulator to simulate the exact functions of a web services backend. A couple of commercial products were evaluated, but they would not fit the bill due to the following: - The development license per seat was quite cost prohibitive especially given there were 10-12 developers in the team - The out of box functionality provided by the tools did not exactly suit the client’s needs and a lot of customization would still be required - The XML payloads were quite large and complex in nature and automated tools were needed for generating these. Given these roadblocks, it was decided to build a custom Simulator Framework and the tools needed to generate the sample XML payloads. Solution Implementation (Simulator) The following design considerations were taken into account while designing the Simulator Framework: - The framework had to be generic with built-in mechanisms to configure it to meet specific needs. It was actually based on the design of the web services invocation framework that was also built as a part of this project. Details of the web services simulator can be found towards the end of this document. - It would have to serve an infinite number of XML output types without having to make code changes to the core framework itself - It should include functionality to easily add XML output types by just changing an XML configuration file - The framework itself should be light weight and easily deployable under an opensource web server like Tomcat - The whole framework should be deployed and be up and running in under 1 hour. Based on these design considerations, the Simulator Framework was constructed as follows: - The core framework was implemented as a SAAJ Servlet that would receive a SOAP message. - Within the framework, payload-specific interface classes would be invoked dynamically. These classes would in turn read the appropriate XML payload from either the file system or database and serve the XML output just like an actual web service would. - During runtime, on receipt of a SOAP input request, the simulator would read the XML configuration file and perform all the steps listed in the previous step. Solution Implementation (Sample XML Generator) As mentioned above, the XML payloads were quite large and complex with a lot of embedded hierarchies. Generating this by hand or even using a tool like XML Spy would have been quite challenging as the schemas were constantly evolving and were not ready for prime time. Keeping this in mind, the following approach was followed to generate the sample XMLs: - The definition of each element and attribute was maintained by a Business Analyst in a spread sheet as an XPath definition. - A Java Application was written that would read each XPath definition and construct the XML as appropriate. 16/09/10 Page 2 of 4
  3. 3. Web Services Simulator (A Use Case, by Krish Khambadkone) - The spreadsheet itself was prepared and formatted a bit before feeding it as the metadata for this program. This process did not take more than 15 minutes. The implementation of these XML generation tools saved an enormous amount of time and effort during the development process. Usage Scenarios The Simulator Framework greatly reduced the implementation cycle times. It was used under the following conditions: - The front-end portal layer could be developed and tested without any dependence on the back-end services. - All the screen transitions and screen functionality were tested using the framework. - As the services became available nearly 4 months later, the services were not fully functional so development and testing was conducted through a combination of actual service calls and calls to the simulator. - The design was such that one could seamlessly switch between real service to simulator just by changing a URL in the configuration file—it was that simple. - The simulator came in very handy especially during the maintenance down times which sometimes lasted for nearly a day, at which time the simulator became indispensible. Web Services Invocation Framework The web services invocation framework was built as a separate framework to enable easy invocation of services from the client side by any client. In this particular case, the client was the Portal. The following factors influenced the design of the web services client invocation framework. - The details of the actual web services should be abstracted out from the user. - Any client should be able to invoke a given web service using the simplest mechanism possible; for instance, a web service can be invoked by just using this one line command: Object response = wsFramework.execute(ws.USER_ADDRESS, insReq); - The framework should be so generic that other application components such as Exception Handling, Auditing, Messaging, Input/Output(File,DB) etc. would easily be pluggable into the existing framework alongside the web services components. The web services simulator was designed and implemented based on the design of this invocation framework. Here are some of the salient features of the web services invocation framework: - The invocation framework is a very generic framework and is driven through configuration files. - Any new service to be invoked will not need any code change to the core framework itself. The service is added as a new definition to the XML configuration file. - The framework itself uses open source web services libraries like Axis2 and JAX-WS to do the actual service invocation. - The framework classes wrap around these underlying open source libraries and provide all the necessary input parameters such as input payload, authentication data etc. 16/09/10 Page 3 of 4
  4. 4. Web Services Simulator (A Use Case, by Krish Khambadkone) The framework had several other components incorporated into it such as Exception Handling, Auditing, File and DB Access. Web Services Accelerators and Tools Infogain has a very rich library of such tools that are provided, in most cases, free of cost to the clients and are used as Accelerators to jump start and reduce the implementation cycle times for an SOA implementation. Some of the tools described in this article are the web services and J2EE application framework, the web service simulator and the XML file generation tools. For more information on the simulation accelerators offered by Infogain, please click here. 16/09/10 Page 4 of 4

×