Modeling Enterprise Java Applications and Deployments
Pages: 1, 2
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 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:
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 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.
Here I show additional, 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.
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
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.
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.
Jeff Davies works as an AquaLogic Evangelst at BEA Systems. He has 20 years of experience developing software, including commercial products like ACT!(tm) for Windows and Macintosh.