Many different enterprises run complex networks of servers to implement various automated communication functions to the enterprise. For example, as mobile wireless communications have become increasingly popular, carriers such as Verizon Wireless™ have customer communication systems to provide notifications of account related activities to their customers, for example, as Short Message Service (“SMS”) messages to account holders' mobile stations, as emails, etc. Because of the large number of customers served by a major carrier, and the level of account activities, the volume of notification message traffic is quite large. To effectively provide such notifications, Verizon Wireless™ implemented its Customer Communication Enterprise Services (“CCES”) as an enterprise middleware web service.
At a high level, the CCES middleware comprises a web server layer and an application layer. The architecture allows clients to send a request, for example for a notification, to a web server. The http web server then forwards the client request to one of a number of application servers. Each application server has multiple applications running on it. The application server determines the proper application to process the client request based on the context root of the client request. The application server processes the client request, in the CCES example, by sending one or more request messages to a back end system such as the Vision Billing System, Mobile Telephone Activation System (“MTAS”), the SMS gateway and others, for example, to implement account activity and to initiate subsequent automatic notification thereof to the account holder. Once the application server has processed the request, a reply is then sent back to the web server which will then forward the reply back to the client.
In a multiple server environment described above, there are many servers running many applications that perform a variety of functions. These applications may require constant updating and modifications. The updates may be done on scheduled basis once a week, for example. The process of updating these applications with new code/configuration may generally be the same from week to week with subtle but important differences. This process is called a “Change Control” at, for example, Verizon Wireless™. At Verizon Wireless™ there are about seven groups of servers, which may run the same applications, for implementing the CCES functionality. Each group of server may have anywhere from eight to sixteen physical machines. There are four steps to the current software “Change Control” process.
The first step in installing new or updated server software includes installing updated application code. In this step, an updated version of the application code is to be deployed on the servers in the group. This is involves: (a) taking down the affected servers running the file to be updated, (b) backing up current server application code, (c) installing the new An Enterprise ARchive (“EAR”) file, (d) restarting the server (e.g., each machine has its own GUI to do this process), and (e) notifying the testers to begin once the server application is back on line. The EAR is a file format used for packaging one or more modules into a single archive so that the deployment of the various modules onto an application server happens simultaneously and coherently.
The second step includes installing updated application configuration files. In about 70% of the update deployments several files may need to be deployed/updated. These are supporting application configuration files or simply files that customers may download depending on the application being used by the customer. The process to accomplish this is by copying files to some/all of the machines in the group.
The third step includes executing Structured Query Language (“SQL”) files. After performing the first and second steps, the SQL may need to be executed. This may be done once and may not be per machine type process. The deployer may be given some SQL files and may run them against three different Oracle tables. These may be run on one central Graphical User Interface (“GUI”).
The fourth step includes running of scripts. In some of the server groups, scripts may need to be run at various points within the deployment process. These scripts are small programs that need to be run at specific points/steps within the process to perform functions that aid in the deployment.
The steps in the above process are manual and require the deployer to log onto individual machines in the server group to perform the steps sequentially. That is, deploying two to three groups of servers would involve manually logging into twenty-four machines and running multiple process steps on each. This requires more than one person because one person cannot keep up with all the tasks that are occurring simultaneously. Therefore, there is a need to improve on the time-consuming repetitive tasks requiring two or more human resources to perform the four step deployment process described above, for example, on as many as twenty-four machines.