Using spring's Web Services Emulator framework Solution

A large WEB development plan typically consists of multiple development projects that are synchronized 24x7 by a team of geographically dispersed teams. The various components developed by these teams need to achieve seamless interoperability as much as possible. The key requirement for this type of development is to establish a good agreement between the teams responsible for building the different components. A good simulator framework ensures as much team independence as possible and potentially increases productivity by implementing all the requests and responses supported by the various interface conventions. This article describes using the emulator framework in a fast WEB development environment, step-by-step demonstrates how to use rational®application Developer to quickly create an emulator framework, and includes examples and code.

Brief introduction

Complex development projects often require that the development processes of each phase be as independent as possible. Assuming that the interfaces between processes (the conventions between different subsystems) have been completed as early as possible in the Software development Lifecycle (SDLC), a good simulator based development strategy can achieve significant optimization in the development process.

This is especially important for deploying new applications and systems to an existing environment, such as in the telecommunications sector, where a large number of independent Software vendor (ISVs) are mixed, and non-functional requirements are important, especially in managing system latency and throughput. In these complex environments, many factors make it complex to actually deliver new applications in an existing environment. Some of these factors include:

Some features need to be developed and released, but lack of all systems and services on which new applications depend

Need to maximize concurrent development activities related to different processes while minimizing interdependencies between processes

Need to demonstrate that new applications meet end-to-end throughput and latency requirements when publishing functionality

The development team needs to be prevented from modifying the subsystems, and they need to rely on these subsystems during the SDLC coding and unit testing phases

The need to easily provide a variety of test data scenarios within a repeatable, stable, and reliable process

In all of these areas, a robust emulator framework will be valuable. This article describes an emulator framework and explains how to use the Websphere®application Server to construct an emulator framework. An application that uses Service Oriented Architecture (SOA) will be highlighted here to extend this to other types of environments and schemas.

Simulator Best Practices

Simulator overview

Merriam-Webster's definition of a simulator is "a device that can reproduce or indicate a phenomenon that may occur in a real situation under test conditions". The simulator can be used during the SDLC process by providing the endpoint with a more agile development environment for the backend service, rendering the back-end service as a calling application, but actually just simulating the real system. The simulator responds in the same form as the real-time background service and uses the same request/response Convention, but simply returns the preset data from the configuration data. This allows modeling of functional and non-functional features that support the system, even if you do not have access to the system itself.

A more common and common programming practice is to use stub interfaces that bypass local client interface calls, but instead execute additional local code paths and return preset data. In many cases, the stub accelerates initial development, but does not implement the functionality that is available to execute the entire code path and invoke the work interface. When using the stub method, the application needs to know that it is in stub mode so that it can execute different code paths. By using the emulator, the application only changes the endpoint without knowing that the response came from the emulated backend system.

Figure 1 and Figure 2 show the difference between two methods

Figure 1. The application uses local stub code to bypass the WEB service invocation