Web Service Deployment: Deploying Web Services in the Northern Electronics Scenario


Frederick Chong
with Jim Clark, Max Morris, and Dave Welsh

September 2005

Applies to:
   Enterprise Architecture
   Solution Architecture
   Service Oriented Architecture (SOA)
   Service Oriented Management (SOM)
   Application Integration
   Business Process
   Business Operations Modeling

Summary: The Architecture Chronicles on Dynamic Modeling: Aligning Business and IT seek to present to business, solution, and infrastructure architects a holistic and integrated approach to aligning business and IT through dynamic modeling to achieve better performance, accountability, and business results. This document focuses on the deployment of Web services for a product shipping solution in the Northern Electronics scenario. (19 printed pages)


This Document
Deployment Requirements
Deployment Modeling
Systems Management Server 2003
Additional Information

This Document

This document is part of the Architecture Chronicles on Dynamic Modeling: Aligning Business and IT. This volume seeks to present to business, solution and infrastructure architects a holistic and integrated approach to aligning business and IT through dynamic modeling to achieve better performance, accountability, and business results. The information map to the series provides an up-to-date description and cross-index of the information available and can be found at the Microsoft Architecture Resource Center.


This document describes how Northern Electronics uses a deployment modeling approach to deploy Web services that make up part of the product shipping solution. It shows how Northern Electronics specifies the deployment policy for one of its Web service. Then, it shows how Northern Electronics uses this deployment policy and Microsoft Systems Management Server 2003 to package software components and configuration settings of different types and versions of Web services into deployment packages; associate different Web services deployment packages with computers in Web service farms; and both schedule and manually activate and control when the Web service deployment begins and completes.


Many thanks to Nelly Delgado for her help with technical writing, Claudette Siroky for her graphics skills, and Tina Burden McGrayne for her copy editing.

The authors would also like to thank Gajanan Phadke, Vishal Kapoor, Amol Wankhede, Aziz Matheranwala, Amit Kumar Srivastav, Bhushan Pawade, Bhasha Johari, Avadh Jain, Mughda Gadre, Maneesha Nalawade, Sonika Arora, Anil Sharma, and Anurag Katre (all of Tata Consulting Services) for their contributions to the implementation of the Northern Electronics solution.


This document focuses on the deployment of the Web services in Northern Electronics's product shipping solution. Background information about the Northern Electronics scenario can be found in the Architecture Chronicles on Dynamic Modeling: Aligning Business and IT at the Microsoft Architecture Resource Center.


Figure 1. Northern Electronics Web services

Northern Electronics designed and implemented two Web services as part of its product shipping solution: ShippingService and PickupService. The ShippingService Web service is an external-facing Web service that enables Northern Electronics to receive a transport order notification from its partner, Acme Consolidation Company. The transport order notification indicates whether Acme Consolidation Company can meet the requirements stated in a corresponding transport order. The PickupService Web service is an internal Web service that supports the Northern Electronics warehouse management application in organizing the queue of goods that are to be picked up and loaded in future working days. These two Web services are shown in Figure 1.

After the software components that implement the Web service functionality are tested, the software programs are ready to be deployed into the corporate data center where the IT servers are hosted. This document examines Northern Electronics's requirements, architecture, and tools for deploying the ShippingService Web service. This reflects the general techniques that Northern Electronics uses to deploy all of their Web services.

Who's Who in Northern Electronics

The following individuals from Northern Electronics are involved in deploying the Web services:

  • Jackie: She is the program manager whose responsibility in this context is to identify the deployment requirements and organize the effort to complete this phase of the project.
  • Tom: He is the solution architect whose responsibility in this context is to work with the lead developer and application administrator to design the deployment policy and infrastructure.
  • Sam: He is the lead developer whose responsibility in this context is to create the installation program files.
  • Dan: He is the application administrator whose responsibility in this context is to implement the deployment policy and oversee the deployment of the Web services.
  • Craig: He is the application support analyst whose responsibility in this context is to deploy the Web services and monitor the deployment status.

Deployment Requirements

Jackie, the program manager, assesses the deployment requirements. One of the main goals is to have multiple run-time instances of the Web service deployed in Web farms within the data center so that there is minimal impact to the service availability in case a subset of the servers goes down. The Web services instances that are deployed must be images of one another, meaning that the software components and configuration are all identical within the Web farm. Instead of manually deploying the Web service instances one-by-one on each computer, Jackie wants to be able to take advantage of the similarity of the deployed instances to automate the installation and configuration of Web services in the Web farm.

From the deployment management perspective, Jackie realizes that the administrator needs to be able to decouple the activity of specifying the deployment policy for a particular Web service from the activity of executing the deployment. These two functions are typically performed by individuals in different roles. Jackie works with Tom to decide that the deployment policy should specify:

  • The collection of software components and programs that implement the Web service.
  • The application and computer configuration settings that affect the runtime execution of the Web service.
  • The server farm or collection of computers where the service should be installed.

When deploying a new Web service, Northern Electronics's policy is to schedule the deployment to occur at a time when it is least disruptive to peak time operation, for example, just after midnight. On the other hand, the company also wants to use the same deployment infrastructure to push out critical security patches and bug fixes that may require immediate deployment action. Therefore, Dan must be able to trigger the actual installation of the service manually or automatically through a schedule. After the installation starts, the operations staff must be able to monitor the progress of the installation within a given time interval. The status of the installation may indicate that the installation is in progress, has succeeded, or has failed. If the installation does not complete successfully, the operation staff must be able to diagnose the reasons for the failure.

Deployment Modeling

After considering the deployment requirements, Dan, the application administrator, notes that that there are two levels of design details that must emerge to support the requirements.

The first set of design details is focused on the deployment infrastructure components that can help to:

  • Activate, download, install, and configure software in a distributed environment.
  • Control, monitor, track, and troubleshoot the set of deployment activities from a central console.

The second set of design details focuses on the policy mechanisms that specify:

  • The software components and configuration settings for different types of Web services.
  • The computer groupings targeted for deployment.
  • The Web service types to be deployed and where they will be deployed.
  • The timing of the deployment.
  • The deployment infrastructure settings, such as where the installation files reside and where progress should be logged.

Deployment Infrastructure Design

The first task involves designing a deployment infrastructure that will facilitate the starting, ending, and troubleshooting of deployment activities. To enable such activities, Dan collaborates with Tom, the solution architect, to come up with a logical architecture of the deployment infrastructure as shown in Figure 2.


Figure 2. Logical architecture of deployment infrastructure

The logical architecture consists of the following entities:

  • Deployment controller. The application administrator uses the deployment controller to:
    • Configure and manage deployment policy.
    • Schedule and trigger deployment actions at the Web service farm computer.
    • Monitor deployment progress and take corrective actions if necessary.
  • Deployment agent. This interacts with the deployment controller and performs software deployment actions according to the instructions and policy received from the deployment controller.
  • Deployment policy store. This provides the central location where the deployment policies are managed and stored.
  • Software distribution point. This provides the network location where the installation program and Web service software component can be downloaded at deployment time.
  • Deployment progress log. This provides the logical location where deployment agents write deployment status and the deployment controller monitors progress.

Deployment Policies

The second task involves designing a policy structure to express information related to what, where, and when to deploy. The following design concepts are used for this purpose:

  • Computer collections
  • Web service deployment versions
  • Software to computer bindings
  • Deployment scheduling
  • Deployment infrastructure settings

Computer Collections

Computer collections are used to express logical groupings of physical computers in a Web farm so that all computers within a grouping can be deployed and configured in the same manner.

Web Service Deployment Versions

The specification of the operation interface of a Web service will evolve over time. The software components and the deployment configuration will likely differ among different deployments of the Web service. Each version of the Web service may support a different service interface or document contract.

Note   Architects and developers need to know at design-time and run-time which version and which deployment of a Web service they intend to create or use. Versioning is a solution design consideration that is not addressed within this document. Related topics such as discovery and directory are also not addressed within this document.

Over time, the implementation of Northern Electronics's ShippingService Web service may be enhanced for the following reasons:

  • A new version of the Web service needs to understand a new element in the transport order notification document. For example, a new field, such as a transport company identification code, may be introduced due to new transportation regulation requirements. When the new version of the Web service is introduced, the Web service should recognize the identification code in the updated format of the transport order notification document.
  • A new implementation of the Web service is built using a new messaging runtime.
  • An existing implementation of the Web service needs to be reconfigured to use a different instance and implementation of message queuing.

When Northern Electronics decides that a new set of software components or application configuration settings (or both) need to be deployed, it must be possible to package the software components and settings into distinguishable deployment packages even though the resulting Web service provides the same logical business service. This idea is shown in Figure 3.


Figure 3. Deployment versions of ShippingService Web service

Software to Computer Bindings

Now that Dan has computer collections and Web service deployment versions, he needs to specify the Web service version that will be deployed to the specific collection of servers. By associating the two entities, Dan creates a deployment unit that can be made available on the network. Note that it must also be possible to deploy different versions of the same Web service on the same collection of servers. This requirement can be illustrated by a simple example where different versions of the ShippingService Web service are to be deployed in multiple Web server virtual directories created on a particular computer in a server collection. Figure 4 illustrates the ShippingService Web service Version 2 associated with Server Collection 1.


Figure 4. Binding Web services components and settings to server collections

Deployment Scheduling

Not only must the policy allow Dan to specify what needs to be deployed and where it should be deployed, it must also allow him to specify when a deployment is to take place. A deployment can begin immediately, when the administrator selects the Start Software Distribution option in the deployment management console. In other cases, Dan may want to schedule a deployment activity, for example, in the middle of the night when the installation network traffic is least disruptive to the operational environment. Figure 5 illustrates this policy concept of associating a time element with the unit of deployment.

Deployment Infrastructure Settings

For each deployment activity, the deployment agents require additional information to deploy the software, such as pointers on how and where to download the installation package. In many cases, these are distributed file shares that already store the installation package files. As another example, the deployment agents will receive information about the location of the log file and the log file name that will label the progress log. The log file is used to write installation progress. Figure 5 illustrates that it must be possible to specify these deployment infrastructure settings with the Web services that are to be deployed.


Figure 5. Deployment policies

Systems Management Server 2003

After Dan has a good understanding of the deployment requirements and the approaches to deploying the Web services, he investigates existing products that can help him distribute the software in a straightforward and accountable manner.

The Northern Electronics IT organization uses Microsoft Systems Management Server (SMS) 2003 to deploy desktop software applications and manage security patches on client workstations. Dan believes he can leverage the SMS knowledge and capabilities of the IT organization to help him deploy Web services. He also believes this will simplify the number of different management products that the company must acquire and receive training for. Dan has heard that SMS supports a multi-purpose software distribution capability. For these reasons, Dan decides to take a closer look at the possibility of using SMS.

In his research, Dan finds the following advantages to using SMS:

  • All Windows-based platforms are supported by SMS.
  • SMS can monitor its bandwidth usage to ensure that software is not installed over the wide area network (WAN) at inappropriate times.
  • Software can be distributed based on user names, group names, computer names, domain names, network addresses, or inventory collection values so it provides a wide range of parameters that can be used to specify computer collections.
  • Software can be distributed at a specific time.
  • SMS shows the status of application deployments.
  • SMS reports if a deployment succeeded or failed.
  • SMS provides a record of the existing hardware and software deployed.
  • SMS allows administrators to monitor activity to ensure that the correct software is deployed to the correct locations.
  • SMS provides a scalable change and configuration solution for centrally managing client computers and servers, which increases productivity and improves service quality within the organization.

Preparing Installation Packages

Sam, the lead developer, is responsible for creating the installation packages. He works with Craig, the application support analyst, to understand any operations constraints, such as making sure that the components that are deployed can run under the data center security policies. Before Sam can let Craig know that the developed and tested Web services are ready to be deployed, he must complete a few packaging and management tasks. One task is to make sure that the desired combination of software components and settings can be bundled together into an installation program that can be executed on the deployed application server. The Microsoft Windows Installer is the recommended technology for packaging run-time executables and their configuration information. Using an .msi file allows Sam to distribute one file that contains all of the files needed for installation as well as the logic needed to complete the installation. The .msi file contains all the file types to be deployed including the following files:

  • Executables
  • Dynamic-link libraries (DLLs)
  • .NET configuration files
  • Databases
  • Web pages
  • Web forms
  • Web service files
  • Discovery files for Web services
  • XML Schema definition (XSD) files

In addition, the .msi file can be created using the Visual Installer component of Microsoft Visual Studio .NET.

To help distinguish the deployment instance that the .msi files are targeted for, the files are named to reflect the name of the Web service that the software component implements, as well as the deployment version of the Web service. For example, a file named ShippingService1001.msi means that the .msi file will install the ShippingService Web service with a unique combination of deployed binaries and settings version labeled 1001.

After the .msi files are created, the files are copied over to a distributed file share directory. Because Northern Electronics relies on the same deployment infrastructure to deploy multiple Web services, it implements the following file share structure to help organize and structure the installation files:


Using the preceding directory structure, all deployment versions of the ShippingService Web service are stored in the \\BinaryDFS\Binaries\ShippingBinaries directory.

SMS Software Distribution Concepts

After preparing the installation files, the next step is to configure the Web service deployment policies. Deployment policy can be configured using the SMS 2003 Administrator console. The following SMS concepts closely relate to the elements in Sam's logical designs:

  • SMS Client. An SMS client corresponds to the installation agent in Dan's design. The SMS agents can be invoked and controlled through a set of interfaces based on Windows Management Instrumentation (WMI).
  • Collection. A collection is a set of computers grouped together because they satisfy one or more rules. For example, a rule can specify that computers that are assigned to be in a certain system role be added to a collection. Another example of a collection membership rule is "all computers within a resource domain." The notion of a collection enables Northern Electronics to logically group its Web servers so that Web services can be deployed on a specified set of computers.
  • Package. A package is the basic unit of software distribution and is used to specify the names of programs and files to be installed as well as the server location where those files can be downloaded. This works well for deploying the Web services because Sam can create a package named ShippingService and use it to organize the different versions of the ShippingService Web service.
  • Program. A program is used to indicate the activities that should occur at the client agent when the package is received, such as running a program or copying files to a particular directory. A package can have more than one program associated with it. As previously indicated, this is useful for specifying the program files that are used for installing different versions of a Web service. Each program definition contains a command line instruction that is used to kickoff the software installation process at the client agent. For example, the command line can specify the name of an .msi file that will install and configure the Web service.
  • Advertisement. An advertisement is the policy mechanism for associating programs that are defined in packages with the collection of computers where those programs are to be deployed. Deployment actions are then initiated by running an advertisement. After the advertisement runs, the SMS agents on the collection of computers can either be triggered to detect for those advertisements or will poll periodically to find the applicable advertisements. An advertisement can also be associated with a schedule so that it is only available during a certain period of time. This is useful for scheduling multiple planned deployments so that the number of parallel deployment activities is not overwhelming to track and administer.

Finally, all the information related to packages, programs, collections, and advertisements are stored in a SQL database that is set up to store the deployment policies of the SMS site. This means the deployment policies can be accessed and managed in a distributed environment.

Using SMS to Manage Deployment Policies

The SMS 2003 Administrator console is used for managing the deployment policies and for initiating deployment tasks such as running an advertisement and triggering the SMS agents in a server collection to start polling for the latest deployment policies. For Northern Electronics, Dan, the application administrator, creates a package named ShippingWebService to represent the software distribution unit for installing all versions of the ShippingService Web service. Sam views the ShippingWebService Package Properties dialog box by right-clicking ShippingWebService in the SMS Administrator console and then clicking Properties.


Figure 6. ShippingWebService package properties

Figure 6 illustrates the configuration of the location where installation files for the ShippingWebService package can be downloaded. In this case, the files can be downloaded from the following network location:


After the package is created, the .msi files for installing different versions of the ShippingService Web service can be associated with the package. Dan defines the program definition for version 1 of the ShippingService Web service as shown in Figure 6.

To view the Program Properties in the SMS Administrator console (as in Figure 7):

  1. In the tree control in the left pane, expand the Packages node.
  2. Expand the ShippingWebService node.
  3. Right-click Programs, point to New, and then click Programs.

The corresponding .msi file is named Shipping100.msi. Using this scheme, when deployment version 2 of the ShippingService Web service is available, a new program can be created to appropriately reference another .msi file named Shipping200.msi. Each .msi file contains the binary and configuration (for example, registry information) files that will install the ShippingService Web service.


Figure 7. Program properties for version 1 of ShippingService Web service

At the same time, the file directory at the data source is structured in the following way so that the installation programs for all versions of the ShippingService Web service are located within a single directory. The hierarchy is shown below:


A computer collection named ShippingWebServiceFarm contains the group of Web farm computers where the ShippingService Web service will be deployed.

Prior to deploying the ShippingWebService package to the Web service farm, Dan uses the SMS Administrator console to create an advertisement for associating the ShippingService Web service with the computers in the Web service farm. Dan right-clicks Advertisements, points to New, and then clicks Advertisement. The dialog box in Figure 8 is displayed. Dan selects the Shipping100 program so that version 1 of the ShippingService Web service will be installed for this particular deployment instance.


Figure 8. Advertisement associating ShippingService Web service deployment with a collection

If multiple versions of the ShippingService Web service have to be deployed in the same Web service farms at different times, multiple advertisements can be created to capture and kickoff those activities. Table 1 summarizes how the policy configuration may look for this deployment scenario.

Table 1. Policy Configuration

Advertisement PackageProgramCollectionScheduleTime
Shipping Web Service Version 1-00Shipping Web ServiceShipping100WebFarm Collection00110:00 A.M.

(12 Feb 2005)

Shipping Web Service Version 2-00Shipping Web ServiceShipping200WebFarm Collection00110:30 A.M.

(12 Feb 2005)

Shipping Web Service Version 3-00Shipping Web ServiceShipping300WebFarm Collection00111:00 A.M.

(12 Feb 2005)

This same approach of defining different advertisements can also be used for configuring the policies of other deployment scenarios where different types of Web services need to be deployed.

Enabling Deterministic Service Deployment

When the Shipping Web Service Version 1-00 advertisement runs, the deployment policy is in effect for the SMS agents that reside on the specified computer collections. By default, SMS agents poll for new software advertisements according to a preset interval that is an SMS site-wide configuration policy. When SMS is used for server-side application deployment, a more instantaneous and deterministic policy-change detection behavior is desirable. This way, administrators can have more control in activating the deployment and tracking the deployment status.

To change the default SMS agent polling behavior, Dan makes the following extensions to the default SMS Microsoft Management Console (MMC) behavior:

  • A Visual Basic script is used to invoke the TriggerSchedule WMI method at the SMS agents of the computers in the collection. When this method is called, the SMS agent starts polling the SMS server for new policy changes, including software distribution advertisements. The following code sample shows how to invoke the SMS Advanced Client to download the policy:
    'Connect to the SMS_Client WMI namespace and get the client instance
    Set oCCMNamespace = GetObject("winmgmts://WebServer001/root/ccm")
    Set oInstance = oCCMNamespace.Get("SMS_Client")
    'After getting the instance, instantiate an instance of the input
    parameters 'for its "TriggerSchedule" method
    Set oParams = oInstance.Methods_("TriggerSchedule").inParameters.SpawnInstance_()
    'Then set the scheduleID as an input parameter to "TriggerSchedule"
    oParams.sScheduleID = "{00000000-0000-0000-0000-000000000021}"
    'Finally, execute the "TriggerSchedule" method over the "SMS_Client"
    'instance by passing the input parameters to it
    oCCMNamespace.ExecMethod "SMS_Client", "TriggerSchedule", oParams
  • To invoke the Visual Basic script from the SMS MMC, a new menu item extension named Start Software Deployment is added to the SMS Administrator console so that administrators can select this menu item to invoke the SMS agents at targeted computer collections. To add the new menu item to trigger the Visual Basic script, add the following registry keys:
    "Name"="Start Software Deployment"
     C:\\SMS_Tools\\Push_Deploy\\Push_Deploy.vbs {00000000-0000-0000-0000-000000000021}
     ##SUB:collectionID## ##SUB:__Server## ##SUB:__Namespace## //NoLogo"

    The CommandLine registry key contains the path to the Visual Basic script that executes when the Start Software Deployment option is selected. Figure 9 shows that the Start Software Deployment menu item can be selected by right-clicking the target computer collection and clicking SMS Tools.

        Click here for larger image.

    Figure 9. Adding and using new deployment menu item in SMS Administrator console

Tracking Deployment Status

The deployment status for each Web service installation can be tracked at three levels of detail:

  • The first level of status tracking is provided through the SMS Administrator console by drilling down into the Advertisement Status container under the System Status container object. For each of the advertisement status, Craig can view the status of the deployment by looking at the various categories of messages that are reported by the SMS client agents. The message categories represent stages and results of the deployment, such as whether the program has been started and if the program has installed successfully.
  • The next level of status tracking is obtained by querying and drilling down into each of the messages that are received from the SMS client agent. For example, Figure 10 shows that by right-clicking the advertisement status, clicking Show Messages, and then clicking the Failures option, Craig can query for all the received failure messages.

        Click here for larger image.

    Figure 10. SMS advertisement status

  • Craig can then look into the details of the messages by double-clicking on the messages in the query results. An example of the Status Message Details dialog box appears in Figure 11. This shows the message details when the program indicated by an advertisement fails to deploy at the targeted computer named SMSCLIENT1.

        Click here for larger image.

    Figure 11. Failure message when installation is aborted

  • The third level of status tracking has the most detailed history of the installation progress and is provided by the .msi installation log file. Information in the .msi log file is used to diagnose and troubleshoot problems that might have caused the .msi to abort the installation. For the Windows Installer to generate a log file when installing an .msi file, the name and location of the .msi log file is specified through the command line text box in the program property page as shown in Figure 6. For instance, Craig might specify the following program command line for installing version 1-00 of the ShippingService Web service:
    Msiexec /I \\SDDFS\Binaries\ShippingWebService\Shipping100.msi /qr /L*

    The computer named WebServer01 installs the Shipping100.msi and creates a log file named WebServer01_Shipping100_Install_Log.txt in the \\LogDFS\InstallationLogs file share. This scheme centralizes storage of the detail installation logs to a known file share so that the deployment administrators can quickly locate the relevant log file based on the computer name and the program that is being installed.


This document examined Northern Electronics's approach for deploying Web services. Northern Electronics used a deployment modeling approach to specify the software components and configuration settings of different types and versions of Web services into deployment packages; associate different Web services deployment packages with computers in Web service farms; and schedule or manually activate and control when the Web service deployment begins and completes.

Using the SMS 2003 software distribution capabilities, Northern Electronics was able to:

  • Group computers in Web farms together into collections.
  • Develop packages and programs that defined the various types and versions of Web services to be deployed.
  • Use the Windows Installer's .msi file to package the software components and configuration settings for Web services.
  • Use the SMS Administrator console and the SMS Advanced Client to download and install .msi files from software distribution points.
  • Use the SMS Administrator console and .msi log files to track installation status and troubleshooting setup problems.
Note   Although SMS's software distribution feature is highlighted for deploying Web services, it can be used in a similar fashion to deploy other server-side applications and software components, such as .NET components in n-tier distributed applications.

Additional Information

For information about Windows Installer, see Windows Installer on MSDN.

For information about Microsoft Systems Management Server, see the Microsoft Systems Management Server Web page at http://www.microsoft.com/smserver/.