< Previous | Next >

Lesson 4: Create an application deployment scenario

The next major step in deployment planning is to assign real-world application components to real-world infrastructure according to the plan in the previous topologies. The topologies at this stage show how a specific instance of the application is deployed.

About this task

The sample project that you imported in the first lesson includes two topologies in the com.mycompany.infrastructure namespace. For this tutorial, these topologies represent the infrastructure that is available to you. The TestInfrastructure.topology topology shows a test environment, consisting of a single piece of hardware that is running an application server and database.
Testing infrastructure
The DeploymentInfrastructure.topology topology shows a production environment, consisting of three separate pieces of server hardware:
  • One server is running an application server.
  • One server is running a database.
  • One server is running an application server and a client for the database.
Production infrastructure

In this lesson, you create topologies to describe how your application will be deployed on both of these environments, in each case using the same physical model from the previous lesson. Using the same physical model for each deployment instance illustrates how you can model the technology choices in the physical model once and then apply those choices to many deployment instances.

All the units in the infrastructure topologies have a contract of public, rather than public-editable as all of your previous units have. You can see the contract of a unit by double-clicking it and selecting General from the list at the top of the pop-up window:

The public contract of the units
These units are public so that they can be seen and used but not changed by other topologies. When you import these topologies into your own topologies, you will use these units as the source and target of links. However, because the topologies represent hardware and software in the real world, you cannot change them from the topology editor.

By contrast, the units in the topologies that you create in this lesson have a contract of private. Up to this point in the tutorial, all of the units you created have a contract of public-editable, because the units were at least one level of abstraction above a deployment instance. Thus, any problems or dependencies on the units could be resolved in a later topology by providing other links or units. However, the topologies that you create in this lesson represent specific deployment instances. Therefore, all problems and dependencies must be resolved before you can use the topology as a deployment instance.

Also, all these units are concrete because they represent specific, existing hardware and software. Until now, most of the units that you have worked with are conceptual, for many of the same reasons that they are public-editable.

Realizing the physical model to the test infrastructure

About this task

Show Me Lesson - Realizing the physical model to test infrastructure

Procedure

  1. Create a new topology with a default contract of private:
    1. Select your project and click File > New > Topology.
    2. In the New Topology window, select the Basic Topologies category and the Blank Topology template.
    3. Name the new topology TestDeploymentInstance.
    4. Set the Namespace field to com.mycompany, but do not click Finish yet.
    5. Click Next.
    6. On the second page of the New Topology window, set the Contract field to Make All Units Private by Default.
      The second page of the New Topology window showing the Contract field
    7. Click Finish.
  2. Import the test infrastructure diagram (not the entire topology) by dragging the TestInfrastructure diagram to the TestDeploymentInstance diagram. If the TestInfrastructure topology is not open, click the "+" symbol next to its name in the Project Explorer view to expand it.
  3. Convert the imported diagram to a shapes container.
    The imported diagram
    You can drag units out of the imported diagram to use them as though they were in the current topology or use them from within the Import Diagram container.
  4. Import the physical model's diagram by dragging the diagram from the Project Explorer view to the TestDeploymentInstance diagram.
  5. Expand the servers and applications in the imported diagram.
    The imported physical model

    There are several errors in this imported diagram that did not exist when you were editing the physical model. Because you specified that units in this topology are private by default, the topology editor is stricter about identifying problems that will prevent deployment. For example, many of the units in the imported physical model, such as the server hardware units, have errors that are labeled "Conceptual unit not realized." Because this topology reflects a specific deployment instance, all of the units must be concrete or realized to a concrete unit for the deployment instance to meet all of the requirements set down by the physical model.

  6. Create realization links from the three server hardware units in the physical model (AccountingMachine, CreditAppMachine, and CreditDBMachine) to the TestMachine unit in the infrastructure topology.
    Tip: You can search for valid link targets by dragging the link handle to an empty place on the diagram and selecting a type of link.
    The three conceptual server hardware units are realized to the single concrete server hardware unit

    Recall that the server hardware units in the physical model represent specifications for hardware, rather than specific pieces of hardware. In this case, the hardware in the infrastructure model satisfies all of the specifications in each of the conceptual units; therefore, you can use that single piece of hardware in the place of all three conceptual units.

  7. Create realization links from the CreditJ2EEServer and AccountingServer units in the logical model to the TestServer server unit in the infrastructure topology.

    The link from AccountingServer to TestServer is valid because the units are of the same type and have the same capabilities. The link from CreditJ2EEServer to TestServer is valid because the target unit is a subtype of the source unit and the target unit has all of the capabilities of the source unit.

    The relationship between these two units is an example of how you can describe the needs of the application in the physical model without specifying every detail. In this case, the CreditManagementWeb application needs a Java™ EE-compliant server, but the application does not need the server to be any particular brand of server or to support any particular version of Java. In the deployment instance, you can resolve that generic Java EE-compliant server unit to a specific brand and version of server. In this way, each level of abstraction specifies only the details that are significant at that level.

    The two conceptual application server units realized to the single concrete server unit
  8. Create a realization link from the conceptual CreditDB in the physical model to the DB2® database unit in the infrastructure model.
  9. Save the topology.

Results

There are still errors in the physical model, but by realizing the conceptual infrastructure units to concrete infrastructure units, you have ensured that the test infrastructure matches the specifications in the physical model. In the next section, you will resolve the remainder of the errors by realizing the application components in the physical model.

Importing the application components

About this task

Show me Lesson- Importing the application components

The sample project includes an EAR file (that is, a Java EE application), a WAR file (a web application), and a DDL file (a specification for a group of database tables) in the Resources folder. For the purposes of the tutorial, imagine that this application was sent to you to be deployed as described in the physical model. In this section, you add these application components to the deployment instance and specify how they will be deployed.

Procedure

  1. In the Project Explorer view, expand the Resources folder of your project and drag the CreditDB.ddl file to the diagram. This DDL file describes the database that the application requires. When you drag the DDL file to the diagram, the topology editor creates a database unit that corresponds to the file. This unit is bound to the DDL file in the same way that the components in the logical model were bound to the UML components.

    You can tell that this unit is bound by the square icon at the bottom right corner of the unit. The unit also has an install state of To be installed, which indicates that it is not currently installed but needs to be.

    The database unit, showing the bound state and install state

    This unit also has an error because it must be hosted on a database.

  2. Create a hosting link from the database component to the DB2 database unit in the infrastructure topology.
    Hosting the database component on the database unit
  3. From the Resources folder of the project, drag the EAR and WAR files to the diagram, and expand the EAR unit.
    The imported EAR and WAR units
    These units are bound to the application files like the database component is bound to the DDL file. Like the database component, they must be hosted on the infrastructure and used to realize the components in the physical model.
  4. Set the install state of the web component unit to To be installed:
    1. Click the Installed icon at the bottom right corner of the web component.
    2. From the list of install states, click To be installed.
    The install state specifies whether the unit is currently installed, currently uninstalled, or is to be installed as part of the deployment operation. In this case, you are designing a topology that shows how these applications will be deployed; therefore, the units should have an install state of To be installed.
    Setting the install state
  5. Similarly, set the install state of the EJB and web units inside the EAR unit to To be installed.
    The units with an install state of To be installed
  6. Create hosting links from the EAR and web units to the server in the infrastructure topology. You do not need to create hosting links from the EJB and web components that are in the EAR component.
  7. Create realization links from the EAR, web, and EJB units in the physical model to the bound units that you just created. Now all of the errors on the physical model are gone.
    All of the errors in the physical model resolved

    One error remains in the deployment model: the database requirement on the CreditManagementWeb unit is not satisfied:

    The database requirement
    This error is labeled "Unsatisfied jdbc/CreditDB requirement." When you import the EAR and WAR files, the topology editor examines the applications in the files and adds requirements to the units to match the needs of the applications. This web module has a data source requirement, so the topology editor creates a corresponding requirement on the unit. In the next few steps, you configure the connection between the web module and the database and resolve this error.

  8. Create a dependency link from the CreditManagementWeb unit to the CreditDB database component:
    1. In the Common Tools drawer of the Palette, click Dependency Link.
    2. Drag the dependency link from the web unit to the database component. A window opens showing the possible links to be created between the units:
      Window showing the possible links to be created
    3. Select the check box next to the link with the 50% value in the left column. The check box for the corresponding capability on the target unit is selected automatically.
    4. Click Add, then click Apply.
    This dependency link indicates that the web application must be able to communicate with the database. However, database connections like this one require Java EE data sources to be configured on the application server. Therefore, this link has an error that is labeled "Access to database implied by link is not configured." The topology editor can configure the database connection automatically, as shown in the next step.
  9. Click the error icon on the dependency link, select the error, and then double-click the resolution that is labeled "Configure access to database."
    The data access configuration resolution
    The topology editor adds three units to the infrastructure model:
    The units that were added to the infrastructure model
    These units are highlighted in yellow because they are not part of the imported diagram, although they appear inside it. The units are in the TestDeploymentInstance topology, but they are shown on their hosts, the units in the infrastructure topology.

    Also, the new units are configuration units, which represent settings that are applied to other units, rather than discrete pieces of software. In this case, the topology editor indicates that a JDBC provider and J2C authentication must be added to the server configuration in order for the application to be able to access the database while running on that server.

  10. Save the topology.

Results

The complete deployment model describes how the application will be deployed onto the testing infrastructure:
Complete deployment model

Realizing the physical model to the production infrastructure

About this task

If you want to create a deployment model with even more detail, you can create another topology to show how the same application will be deployed on the development environment that is modeled in DeploymentInfrastructure.topology. The main steps are the same, but instead of realizing the three conceptual pieces of hardware in the physical model onto one server, you will realize them each onto a separate server in the deployment topology:
  1. Create a new topology for the deployment instance. This topology must have a default contract of private.
  2. Import the deployment infrastructure topology diagram.
  3. Import the physical model topology diagram.
  4. Import the EAR, WAR, and DDL files and set their install states.
  5. Create realization and hosting links.
  6. Create the dependency link to the database and use the resolution to configure the database connection.

When you are finished, the new topology will look similar to this:

The complete topology for the production deployment instance

Summary

In this lesson, you planned deployment for two deployment instances of the application using the physical model and the application files themselves as a guide. You also saw some of the ways that the topology editor can help you identify and resolve potential problems in the deployment instance.

You can import the completed project for this tutorial into your workspace to check your work. To import this project, see the sample Planning deployment with the topology editor tutorial.

< Previous | Next >
Feedback