Application design and Environment management touch each other when the components designed and developed are deployed on servers. A seemingly simple task gets complicated when tens of interconnected applications are deployed in multiple environments made of hundreds of servers. This article is about how to systematically approach a large deployment. Some ideas are:

• develop a conceptual model for the application deployment based on UML,
• identify application design deliverables and environment management tasks involved in the deployment
• use tools to manage the inventory of the applications, servers and their association.

UML has the Deployment View to describe the link between the logical components and the run-time resources that will execute the code. The basic concepts are Node – the run-time computational resource, and Artifact – a physical entity such as a file. The Artifact is a “manifestation” of a component. In the real world, these concepts are not used by the implementation team, instead they operate with “servers”, “databases”, “Weblogic Servers.” UML2 provides ways to accommodate these, higher-level, entities. One way is to use the concept of “execution environment.” Databases and J2EE application container are execution environments and can be represented as Nodes in the deployment diagrams. To show that a database runs on a server I am using associations between nodes qualified with the stereotype <<hostedOn>>. The picture on the right shows how to represent the Weblogic, Database and the Unix Servers in UML.

Now let’s consider an simple application that will run in this setup. A ticketing application that contains a web-based user interface and a TicketManager is deployed on this infrastructure. In UML, to show the deployment, we would have an artifact on the Weblogic Server (e.g. ear file) which is a manifestation of the components TicketWebUI and TicketManager. Also, on the DB server, there is schema which is a manifestation of the persistency layer of the TicketManager component. To make it more intuitive, we are using an association between a component and the server with the stereotype <<deployedOn>>. The semantic of this association is that the server has an artifact which is the manifestation of the component.

Note that in the diagrams there are Node types, not Node Instances: it indicates that will be a Unix Server or the type HPE2960, but not which specific server. I call this diagram Generic Deployment Diagram (GDD).

 

 

 

An application is deployed multiple times for different purposes such as testing, training, production. For each of these activities there is an Environment which contains a pool of hardware and software resources to support that activity. When the application is deployed in an environment the components are deployed on Node instances. The UML diagram is very similar with the following changes:

• the name on the nodes are now Instance:Type and underlined
• there are more attributes for specific environment.

I call this diagram the Environment Deployment Diagram (EDD).

Graphically, GDD and EDD are very similar, but there is an important difference of when the diagrams are created in the application lifecycle. GDD is an artifact created during the application design by the application architect. The EDD is created during the environment build. In this phase the environment infrastructure architect asses the GDD and binds the GDD generic nodes to EDD node instances.

 

The previous diagrams are using the default UML icons for various entities. It is possible to have custom images for some Nodes by using stereotypes. A stereotype allows to do more than just change the icon, it allows to categorize entities at a higher level of abstraction. The diagram on the right is using stereotypes to show servers hosting Weblogic container and Oracle database.

 

 

 

We have covered so far the notation used to describe the deployment of an application. The important points to remember are:

• UML with extension (execution environments, Node derivation and stereotypes) is the way to describe the deployment of real-world applications
• a Generic Deployment Diagram (GDD) is created during the application design by the application architect. It describes the types of nodes that will be used but not the specific instances
• an Environment Deployment Diagram (EDD) is created during the environment build. It is a refinement of the GDD with attribute values being assigned based on the environment resources.

When an application is deployed in an environment there are parameters that need to be configured. UML calls this configuration the “Deployment Specification.” Some of the parameters are related to the application internals (e.g. transactionality, concurrency) and they are provided by the application team. Others are related to the connections of the application to other components/applications in the same environment. In the same way in which components are bound to physical servers, interfaces are bound to end-points and these two activities are linked. For example, the URL of a web-service depends on the host on which the web-service is deployed. Note: End-Point is not an UML term, the UML term is port. However, port is an overloaded term and frequently understood as the TCP port. I am going to use in this document end-point for UML-port in the context of deployments.

We are going to call the Generic Deployment Specification (GDS) a document that the application team provides with all the parameters that can be configured for the deployment of the application. The Environment Deployment Specification (EDS) for defines the deployment parameters for a specific environment. The sum of all the EDSs for the applications in an environment is the EDS for the environment itself. The dependency between applications is reflected in dependencies between EDSs. For example, if in the environment E, application A is connected to application B and application B is connected to C, then, the EDS-A dependes on values from EDS-B which depends on values from EDS-C. It is also easy to see that in some cases will be circular dependencies between EDSs.

In small systems EDSs are managed in properties files, ad-hoc XMLs, scripts and sometimes Excel. In large systems, the complexity around creating and maintaining EDSs is high and the ad-hoc methods do not scale. To support consistent and manageable deployment specifications for a large environment:

• deployment specs must have a formal syntax to support automated processing
• some deployment properties are derived from other deployment properties
• a deployment spec could be dependent on other deployment specs.

There can be multiple ways to create a system to support these requirements. I will describe in a separate blog an option which is based on using XML-properties files and Ant.

To summarize, this article has shown a few ideas that can be used to build a deployment methodology:

• UML as-is does not have strong modeling for deployment but its basic blocks with extensions allow to model the real-world deployments
• a number of artifacts – Generic Deployment Diagram and Generic Deployment Specification – have to be produced in the Application Design phase which are used in the Deployment phase to create environment specific artifacts: Environment Deployment Diagram and Environment Deployment Specification
• a formal syntax for the Deployment Specifications needs to be defined which can be used in Ant and Shell scripts to automate the deployment.