Modeling Enterprise Java Applications and Deployments
Pages: 1, 2
Deployment Diagrams
For some reason, deployment diagrams usually get
short shrift in most UML books. In many books the chapter on deployment
diagrams ranges anywhere from two to six pages, with only the simplest
of sample diagrams. In my opinion these diagrams are among the most
important in all of UML. These diagrams allow you to express the
architecture of a single software system or even the entire IT
department, and they can be a critical factor in finding the source of
performance problems in your production environment.
A typical company has a fair number of
environments: development (at least one of these), testing (possibly
more than one of these), performance, staging, and of course, the
production environment. Many organizations also maintain a disaster
recovery environment, in case of natural or man-made disaster. But
there is little value in maintaining deployment diagrams for all these
environments. The development, testing, and performance environments
usually change far too quickly to warrant any serious modeling of the
software deployed on them. The staging, production, and disaster
recovery environments are (or should be) so similar in nature that
modeling the production environment alone is usually sufficient to
capture the essence of your deployment space.
Here is where UML 2.0 really shines. From the
changes that appeared in UML 2.0, it's obvious a lot of people felt
that deployment diagrams were very important. In the early part of a
project, I recommend modeling your deployments at a logical level. Use
nodes in the most general of terms. I also recommend creating these
diagrams in the earliest stages of the project. Deployment is a
critical part of your project planning, not an afterthought.
While I do see deployment diagrams in the field,
most of them stop at the logical model. It is important to model the
deployment of all your systems and not model each software system
independently. Gone are the days of silo applications. We live in a
world of interconnected systems, and those interconnections need to be
planned and mapped.
The fact is that a good, physical deployment
diagram can be instrumental in helping you to figure out problems in
production. Did the system work fine when it was launched into
production but now is having problems? Sometimes, the system showing
symptoms of distress is not the cause of the problem. Instead, a system
either upstream or downstream may not be performing as expected and
that performance problem manifests itself in an entirely different part
of the system.
There is an old parable about a raja who asked to
have three men, blind from birth, describe an elephant by touching only
a single part of that elephant. The man who felt the elephant's ear
thought an elephant was a winnowing basket. The man who touched the
tail said an elephant was a type of brush. The man with his arms
wrapped around the leg of the elephant said an elephant must be a tree.
An elephant, like a production environment, is composed of many parts.
If you can't see and understand the entire thing, then you are like one
of the blind men in the parable; Your conclusions as to the true nature
of any problem will most likely be wrong. However, modeling such a
large system is a non-trivial exercise. If you try to represent too
much of the ecosystem on a single diagram, you'll be wallpapering your
walls with massive (and useless) printouts.
Therefore, I recommend organizing your physical
deployment diagrams into a hierarchy. At the top of the hierarchy is a
complete picture of the "elephant," the entire software ecosystem. Due
to the nature of such a diagram, it contains very few physical
deployment details and is more focused on the logical relationships of
the major systems.
Figure 5 is a visually simple diagram of a
production environment. From this simple diagram you can see that the
overall architecture is hub and spoke. You can also see the entire
enterprise is logically divided into seven distinct groups, and you can
guess from the central nodes name of "Service Infrastructure" that
these logical, functional areas are connected through a services layer.
From this diagram you can begin to drill down to gain more detail.
Let's zoom in on the Customer Relations Management (CRM) system.
Figure 5. A deployment overview diagram
In Figure 6 I have changed the diagram scope to
zoom in on the CRM system. In this diagram you can see three commercial
applications included in the subsystem: Siebel, Salesforce.com, and
ACT!. Salesforce.com really is a Web hosted application that lives on
the Salesforce.com servers, but from my enterprise point of view, it is
considered a part of the enterprise.
Figure 6. The CRM domain
You can also see from the diagram that there are
two home-grown subsystems: The first allows customers to view their
account status, order products, and engage in other "self service"
activities provided through the Siebel system; the second, the CSR
Command Center, is a custom application that allows the customer
service representatives of the company to perform any function on
behalf of the customer. In addition, it provides functionality not
normally available to the customer, like tracking lead information
about contacts before they become customers.
Next I zoom in on the Customer Self Service (CSS) subsystem to get a much more detailed look at the system.
Figure 7. The CSS physical deployment details (click the image for a full-size version)
Figure 7 shows a physical deployment diagram in all
its glory. In fact, this diagram is at the upper limit of content
density. Notice the nested elements in the Domain instance (the large
box in the center of the diagram). In general, I find the maximum level
of nesting should be three levels deep. Anything beyond that and the
diagram begins to exceed the scope of its message. This diagram shows
the following things:
- A total of four physical machines are in this
deployment: the two Sun Fire v40z machines and the database machine,
which is a Dell PowerEdge 6850. The IP address of the PowerEdge is
displayed, but the IP addresses of the SunFire machines are not. That's
because the SunFire machines support virtual servers. Its is the IP
addresses of the virtual servers that are important to this diagram,
not the IP of the physical host machines.
- A total of seven virtual machines are created
within the two SunFire machines. These virtual machines have nothing to
do with a Java VM. They are fully functional virtual computers,
complete with their own IP address. A Java VM can be run inside these
virtual machines.
- You see a rough outline of an Oracle WebLogic Platform domain that contains an admin server and two clusters.
- The WebPortal cluster contains four servers. You
also see deployment lines that connect each server to a virtual
machine. This makes it clear to the SCM folks how to setup the cluster
(at least at a structural level).
- You see a second cluster named BackEnd that
contains two Oracle WebLogic servers, and you see where those two
servers are deployed onto virtual machines.
- You see that an Oracle database, containing the customer schema, is running on a Dell PowerEdge 6850.
- You see a hardware load balancer that translates
the URL "customer.bea.com" into the appropriate IP addresses used by
the Oracle WebLogic Portal servers.
- Finally, at the bottom I have defined a legend
for the physical deployment map that provides additional detail about
the types of the instances I've deployed.
In a single diagram, I have provided a significant
amount of information that it useful to the Development, SCM, and
Production Services teams.
Tip! - Three levels of nesting are usually sufficient.
However, you need another, complimentary diagram
focused on the Oracle WebLogic Server-specific details. The target
audience for this diagram is primarily the developers and the SCM
groups. Figure 8 is an example of this type of diagram.
Figure 8. A WebLogic Server-focused diagram (click the image for a full-size version)
Here I show additional, Oracle WebLogic
Server-specific configuration information. You can see cluster
addresses, multicast addresses, and multicast ports. You also see that
a data source named customerDS has been created and targeted to the BackEnd
cluster, meaning both servers in that cluster have access to that data
source. I could use similar constructs to model JMS topics and queues,
persistent stores, and more.
Furthermore, you see that the deployable modules
defined in earlier diagrams are shown here, along with how they relate
to the WebLogic clusters. The BackEnd cluster (and all its servers) have the customer.ear file deployed to them. Similarly, the WebPortal cluster and its servers have the customer.war file deployed on them. By referring to the deployable modules diagram, you can quickly close the loop on this information.
A WebLogic Platform Stereotype Taxonomy
As mentioned previously, UML stereotypes are a
powerful notation tool that allow you to capture additional information
about elements in your model. Most modeling tools come with UML
taxonomies for J2EE, Web services, and other technologies. If your tool
does not come with these predefined taxonomies, or if the predefined
taxonomies do not meet your specific needs, you can quickly create your
own. Figure 9 shows the taxonomy used in this article. Feel free to
customize this sample to suit your specific needs
Figure 9. A Stereotype taxonomy for Oracle WebLogic Platform models (click the image for a full-size version)
The important thing to remember with stereotypes is
to use them uniformly. Your models should have to pass a review process
to ensure they meet the standards set for your company. This helps you
create standardized models, which in turn helps promote clear
communication among your IT departments and sub teams. Maintain your
stereotype model independently (that is, in its own model) and then
import your stereotypes into your project models. This will save you
time and ensure that you use the most current stereotype taxonomy in
your current projects.
Summary
I have covered a lot of detail in this article.
While certainly there is more to modeling effectively than what I've
presented here, this article should help you create better models and
diagrams, improve the communication of these details between different
groups in your IT department, and provide some standards and a
methodology to help you manage your software ecosystem more
effectively. Remember that modeling is a supporting effort for what is
truly important: executable software systems.
References
Jeff Davies, a Sr. Principal Product Manager at Oracle, has over 20 years experience in the software industry. He is the author of The Definitive Guide to SOA: AquaLogic Service Bus.
Bookmark
