It's a pleasure to be writing this article in the beautiful, high-tech, Mediterranean city of Netanya, Israel. It's the evening after the first day of the workweek here - Sunday, of course - in my current consulting engagement. But working Sundays isn't the only thing I've had to get used to here.

Although I've driven a car in at least 12 different countries on several continents, I've never had a greater potential for roadway dyslexia than I have here. Not only is the Hebrew language foreign to my ears, the script found on street signs is written right-to-left (at least that's what I've been told) and doesn't even remotely resemble the Roman-based characters I've grown quite fond of. Oh, and the Hebrew text is generally followed by a second line of text in Arabic. Hebrew with Arabic - my guess is that it's the highway department's answer to 128-bit encryption.

What do my language deficiencies have to do with representing Enterprise JavaBeans in the Unified Modeling Language (UML)? Everyone needs a common method to communicate thoughts and ideas. In Israel the international language is, thankfully, English, which in many cases is the third line of text hosted on road signs here.

But it doesn't end there. As I present Java 2 Enterprise Edition course instruction and discuss project strategies for migrating existing proprietary application server components to the J2EE architecture, I speak freely in English as those who speak native Hebrew, Russian, and French listen and participate. It works because we have English in common. But when it comes to communicating software architectures and designs in general, and EJB specifically, why do so many often resort to "foreign" methodologies and syntaxes or even choose to "grunt" instead?

Why Not UML?
From my vantage point, there's been an explosion in the use of UML. When we all come from differing software development backgrounds, we can make architecture and design work for us because we have UML in common. But why do some hesitate or even fail with UML?

Frankly, I believe that many start off with good intentions to learn and use UML. But because of work environments that lack a reliable software process, capable engineers end up abandoning a standards-based modeling approach for the "code by the seat of your pants" antimethodology. Generally I've found this is due to a lack of understanding and/or commitment at the top. Because they've never used or understood a software process themselves, many managers are all too willing to let their development staff live with the pain. So for those of you who think you need to be good looking to be hired for an "Object Modeler" position and that "Senior" is completely out of context, you'd better visit your favorite online bookstore and order a copy of Martin Fowler's UML Distilled (Addison-Wesley) immediately following your plastic surgery.

On the other hand, many of you are completely sold on using a software development process with UML, but may find the cost prohibitive. True, the cost of UML tools can be out of the stratosphere, but there are options. At least one of the leading UML vendors has expressed willingness to configure its product to fit your budget by unplugging costly features such as round-trip engineering. Granted, round-trip engineering may sound appealing, but one UML authority told me it shouldn't be used by organizations with a Capability Maturity Model that's less than Level 4 or 5 (www.sei.cmu.edu/cmm/).

Trying to maintain a set of object architecture and design artifacts that are perpetually synchronized with the source code of a complex software system can be a daunting task (with one exception explained below). So why pay for a feature you may find too difficult to use? And if you're just looking for a way to try out the various UML diagrams, there's at least one pure Java Open Source UML tool, called Argo/UML, available free of charge at http://argouml.tigris.org/. Argo/UML has been somewhat limited in the past, but has many more diagram types in the latest version.

Whatever your budget, note that UML is an understandable and generally concise syntax. While there are a number of diagram types - officially nine in all - most of us will make good use of about four or five. I recommend mastering at least use case, collaboration, class, sequence, and a combination of package and component diagrams. Also useful for some stages of design are state and activity diagrams. You can take a phased approach to UML, perhaps starting with use case and class diagrams, then adding a new diagram type as you see fit. Also be aware that the software development process you follow will greatly influence which diagram types you use and at what stage in a development iteration you use them (see sidebar, "When to Use UML Diagrams").

But there are issues for those of us who know UML and want to make it work for our middle-tier, enterprise-component development, namely Enter-prise JavaBeans.

Modeling Enterprise JavaBeans in UML
Unfortunately, the UML doesn't at present support the expression of every software idiom we need to use. While there's excellent support for the Java language in general, and simple JavaBeans components specifically, there's currently no standard definition of how to model Enterprise JavaBeans in UML. Granted, there are ways to model EJB in UML, and as you'll see, depending on the tool you use, it might work out very well. But the Enterprise JavaBeans architecture was specified well after the UML was completed. Because it's a complex specification, there proved to be aspects of the Enterprise JavaBeans component architecture that the designers of the UML didn't previously consider. What that spells for you and me is the potential for UML modeling tools to be difficult to use when designing EJBs. However, UML designers exercised appropriate forethought in these situations and built extensibility features into the language so it can grow into the tool it needs to be for any given software model.

How will the UML be extended to support Enterprise JavaBeans development? The Enterprise JavaBeans Specification version 1.1 stated under Appendix A entitled Features deferred to future releases: "We plan to enhance the support for Entities in the next major release (EJB 2.0). We're looking into the area of use of the UML for the design and analysis of enterprise beans applications."

Unfortunately, the proposed final draft of the version 2.0 specification doesn't even mention the UML. If previous performance is any indication of the future, we can't expect to see the next specification for another year or so. However, we may get an answer sooner than that.

Java Specification Request Number 26
It appears that the EJB specification group has turned over the UML/EJB specification to the Java Community Process Program, who has assigned it a specific Java Specification Request number, JSR-026. I must emphasize the words "it appears" because it's actually difficult to understand what's happening with this whole subject. I've attempted to contact a few members of the JSR-026 Expert Group, including the specification lead, but have failed to be granted any insight into the progress and status of the work accomplished thus far. However, I can tell you which Enterprise JavaBeans development issues are being discussed.

In general the UML/EJB specification will focus on creating extensions to the UML that will allow tool and framework vendors to provide standards-based modeling capabilities and source code synchronization facilities between the UML and EJB implementations. While the common round-trip engineering features of many UML tools focus on model-to-source-code synchronization, a giant leap forward will be the definition of standards for storing UML models in the EJB-JAR file and associating the model components with the actual software components they represent.

Companies creating reusable EJB components will then be able to bundle UML models of their components to permit tool and framework vendors to use their models to automate the consumer's use of the components. Perhaps some component development organizations are already shipping UML models to their customers, but likely such models are supported by only a single UML tool vendor. The real strength behind standardizing an EJB-JAR UML model archive is to allow all models to be read by any number of standards-based tools and frameworks. Thus, the UML models become just as open and reusable as the Enterprise JavaBeans components they represent.

So we're really talking about empowering both EJB component vendors and EJB component consumers, which will become increasingly separate camps over the next few years. EJB component vendors will have the tools they need to rapidly develop and deploy server-side components using UML-based tools that understand the logical and physical EJB constructs to UML model elements, including sophisticated and vastly im- proved round-trip engineering facilities. Once the EJB components and UML model bundles are delivered to the component consumer/customer, he or she is empowered to quickly examine the server-side object model diagrams and use them to define relationships between their newly acquired EJBs and their existing software. Hopefully with a few drags and drops and some relatively simple glue code, the new components will soon be in live production!

One of the JSR-026 Expert Group deliverables is an XML DTD (Document Type Definition) describing the valid format for the UML models housed in the EJB-JAR file and the relationship of model elements to EJBs in the same deployment file. The UML model file stored in the EJB-JAR will be XMI, an XML-based definition designed to facilitate the storage of UML models in an open, vendor-neutral format.

It appears that JSR-026 won't be fully incorporated into the EJB specification until, perhaps, version 3.0. Since JSR-026 deals with issues of deployment, the UML/EJB specification may not be provided until there's some resolution to standardizing deployment of a single EJB-JAR file to any number of compliant servers. On the other hand, the Expert Group may release a specification be- fore you've read this article. You can check on the progress of the specification by navigating to this Sun URL: http://java.sun.com/aboutJava/communityprocess/jsr/jsr_026_uml.html. Either way, we need to model server-side components. So what can be done at the present time?

Together Control Center
The JSR-026 home page states concern over vendors who will use proprietary scaffolding to host EJB modeling in the UML tools. In the long run we'll be happy if all UML tool vendors implement their EJB wiring according to specification. But in the meantime I'm more than happy to make use of whatever's available to help me get my work done. And Together Control Center from TogetherSoft is one of those tools. Together Control Center is a top-of-the-line product for Java-based modeling and does an excellent job of supporting the creation and deployment of Enterprise JavaBeans to a variety of servers. From the quality of their proprietary EJB modeling tools, I believe that TogetherSoft will have little trouble moving to a specification-conforming edition, that is, once the JSR-026 Expert Group catches up to them.

If you've ever developed an Enterprise JavaBean, you know there are a lot of parts to keep track of. If you're creating a session bean, you have three Java source files to maintain - the remote and home interfaces and the bean's implementation class. If you're creating an entity bean, you'll have to add another file to support your entity's primary key if the primary key is too complex to be represented by a Java String or a java.lang wrapper class (e.g., Integer). Just making sure all your remote and home interface methods are properly implemented in your bean class can be challenging. Add to that the creation of the ejb-jar.xml deployment descriptor as well as server-specific deployment descriptors for resource management and object-relational database mapping, and you realize there's plenty of room for error.

Together Control Center helps simplify EJB development. While you still have to create all the files you did before, Together Control Center minimizes the number of errors you can produce. Most useful is the UML class diagramming for EJBs. Two toolbar buttons support EJBs - one for session beans and one for entity beans. Let's take, for example, the Session EJB button. If you click the button and then click the diagram, a UML class element representing your EJB session bean's implementation class appears. Automatically generated for you is the bean's SessionContext instance variable, as well as the setSessionContext(), ejbActivate(), ejbPassivate(), and ejbRemove() methods, and a default ejbCreate() method.

As you add elements to the class, such as new business methods, you may not realize what's being done for you in the background. If a newly added element has a corresponding element that must be synchronized with the remote or home interface, Together Control Center automatically adds the element to the proper interface. For example, if I add a business method named getUsersByAccountId(), the same method definition will be added to the bean's remote interface. Adding a new ejbCreate() method, say, with an initialization parameter or two, adds a corresponding create() method definition to the bean's home interface.

By default you don't see the EJB's home and remote interfaces, only the implementation class. That's great when you're first designing your component. By hiding the remote and home interfaces you save a lot of diagram real estate, and you're less distracted by the additional pieces. However, when I start to define my client-side classes, such as one supporting the Verge EJB Client Design Pattern (a wrapper class that hides the details of the J2EE/EJB APIs and other extras necessary for client interaction), I prefer to model the client by showing navigation dependencies to the remote and home interfaces as opposed to showing the client conversing directly with the EJB implementation class (which in fact it can't do).

To make the remote and home interfaces visible, you simply use the View/ Diagram View ManagementS properties sheet to toggle the EJB view settings. Figure 1 shows the results of just a few minutes of EJB modeling with Together Control Center.

In addition to adding a new business method or ejbCreate() method, you can add the standard EJB deployment references for environment, bean, security role, and resources. In Figure 1 I've added a special bean environment entry named "allowASPAccounts" as a Boolean. If you're setting up special transaction attributes and security roles, you may want to make use of the special EJB Assembly Diagram provided by TogetherSoft as a proprietary UML extension. As you can see in Figure 2, the assembly diagram states that "Any- User" can open() an account and query for allowASPAccounts() support, but you must be an "AccountAdmin" to terminate() an account. It also sets the required transaction attribute for the open() and terminate() methods, but states that allowASPAccounts() supports transactions but never initiates one.

Time and space don't permit me to delve much deeper into Together Control Center, but one last feature I must mention, which by the way isn't specific to EJB, is the unique round-trip engineering capabilities of Together's product line. There's no need to synchronize your source code to your model, or your model to your source code, because your Java source code is your model's archive. When you create a new class in Together Control Center, it generates a Java source file automatically. If you then vastly alter this Java source file using a programmer editor, save your changes, and return to Together Control Center, your changes are immediately reflected in your model. In fact, a major strength of Together's products is that you can actually use them as your development environment. TogetherSoft calls this unique feature OneSource Simultaneous Round-trip Engineering.

You can try out Together Whiteboard edition for free without any size or time limits by downloading it from http:// togethersoft.com. The Whiteboard edition is limited to only class diagrams, but includes all the basic IDE features of the full product and GoF (Gang of Four) and other design pattern plug-ins.

Deploy on JBoss/Server
In conclusion I'd like to shift gears a little and tell you about one of my favorite Java 2 Enterprise Edition subjects of late. It's the JBoss open source Enterprise JavaBeans Server project (www.jboss.org). I started using JBoss last July and found it to be a fascinatingly wonderful product! The contributors to the JBoss project have produced a truly first-class EJB server and container. Last summer as I evaluated the code drops that eventually led to the recent JBoss version 2.0 product suite release, I thought I'd stumbled onto something worthwhile. Having been described as "coders on steroids," the JBoss team, led by Marc Fleury and Rickard Öberg, has produced an incredible amount of solid code in a relatively short period of time. But they're not just coding. The developers do such a good job of managing the support forums that they've attracted an additional bunch of helpful contributors to the project. Personally, I'd like to thank Darius Davidavicius of Lithuania and Torsten Terp of Denmark for patiently helping me create an Oracle data source for JBoss/Server.

As you're probably guessing, all is not perfect. I didn't struggle with the data source creation for no reason. There are some serious holes in the bowels of the JBoss documentation. And while there are already EJB 2.0 features cropping up (such as a recent preliminary implementation of message-driven beans), how long can a group like this go on without some nontechnical assistance? A large-scale project like this will eventually begin to have some large-scale needs. In the spirit of the Linux and Apache projects, I believe that a project of JBoss' magnitude is a natural fit for large-scale financial support.

Recently the aforementioned Darius reported that JBoss/Server is outperforming the market's leading EJB server by over 20% as both servers run his deployed code side-by-side. When you consider that non-e-commerce, three-tier applications are beginning to be sold into business enterprises on CD-ROMs with EJB servers as the infrastructure, JBoss/Server has removed the per-CPU licensing barriers to those markets. Our Israeli client is a testimony to that, and they're using JBoss for that very reason. Add to that the array of business-to-enterprise start-ups coming down the pike and the millions of dollars that can be saved on developer and deployment licenses. What could that be worth?

Of course, there's always going to be a place for the market-leading, top-priced EJB application servers. It's a given, the same given that some variety of Windows is still outselling Linux by a long shot. But just as there's a place for Linux, there's a place for JBoss. In the short term I'd at least like to see TogetherSoft create an EJB deployment interface for JBoss.

At a minimum, I recommend you download the JBoss product suite if you haven't already done so. See if you don't agree that it's one of the tightest, well-architected pieces of software you've used in a long time. If so, think about contributing in some way to the effort, either technically or otherwise.

SIDBAR:
When to Use UML Diagrams
While anyone can learn to draw pictures of software, it's sometimes when you draw them that matters most. One failure of many books about UML is that they spend a lot of time dissecting the syntax into excruciating detail, but they don't really teach you when the various diagrams should be used. Be aware that the software development process you follow will greatly influence which diagram types you use, and at what stage in an iteration you use them. Therefore, I can't provide absolute direction, only some general guidelines based on my own and others' experience.

Many teams are finding success using an iterative software development process. By iterative I mean that relatively small chunks of software are created in relatively brief development cycles. Once a small software deliverable is defined, a cycle called an iteration or "timebox" is begun. Upon successful completion of the iteration, a release is performed. Then another small software deliverable that may complement a previous iteration is performed. After each iteration is integrated into the release, software testing can begin on the latest deliverable. At some point enough iterations will be complete and stable enough to constitute a product ready for alpha and beta test, and eventually final release.

• Step1:
  Use Case Diagrams: At the beginning of the product conception stage, the nontechnical and technical teams will merge to perform some high-level requirements analysis and create a product vision document. Following full consensus, the same team will work together to create perhaps 10-12 high-level use cases that clearly define the product's intended use. At this point both text documents and UML use case diagrams can be used to fully express the product's requirements. Then, the first development iteration begins. The test team will use the use cases to begin developing a test plan, while at the same time the development team will use the use cases to create lower-level use cases for defining software requirements. The resulting software requirements can then be shared with the test team to help flesh out their test plan into test requirements. Many times this work will be performed in unison.
• Step 2:
  Collaboration Diagrams: Following the use case portion of the iteration, collaboration diagrams can be created to look at the behavior among the various objects in a single use case (one bubble, most likely including any directly accessing actor). At this point things are becoming more concrete. We're transitioning from relatively high-level models to the discovery of which objects will be alive inside a use case, and what method invocations cause the collaborations.
• Step 3:
  Class Diagrams: While collaboration diagrams introduce objects, they generally indicate very little about static relationships between the collaborating objects. Static relationships defined in class diagrams include object types and super types, special interface implementations, navigation and dependencies, how the objects are composed and aggregated, and what additional properties and methods must be created to support the real world. At this point most developers are itching to cut the code. But if you're just a little more patient it will pay off.
• Step 4:
  Sequence Diagrams: Class diagrams are among the static diagrams because they don't indicate behavior, only compositional relationships. Collaboration diagrams are good for discovering new objects, but they're not so good at documenting collaboration sequence. In fact, sequence can get a little hairy in them. But sequence diagrams are great for defining the interaction between objects of various types at the method invocation level. By providing sequence diagrams of your object interactions you'll be able to analyze your class designs before the code is cut, and provide clear direction to those who actually write the code.
• Step 5:
  Package and Component Diagrams: Now you need a place to house the classes you've defined. Package and component diagrams are used to define object dependencies and relationships at a much higher level than class diagrams. Actually there's really no such thing as a package diagram, per se. Rather, you can "invent" package diagrams by inserting package icons with interpackage relationships and nested packages on a static structure diagram (class). Package diagrams can map one-to-one into Java class packages. A single component object in a component diagram can map one-to-one to a single Enterprise JavaBean and define its navigable dependency on other middle-tier components. Use these diagrams to help your team understand how the current iteration will be packaged and how it can be snapped together and deployed with existing software from previous iterations.

  If you hand over a set of well-defined collaboration, class, sequence, package, and component diagrams to an experienced group of programmers, they'll have little if any question of how the iteration must be coded and deployed.

  But what about the software architect's role? Actually the architect's role will begin in step 1. A single architect or group of architects could be called on soon after the product requirements are completed, since at that time the target platform(s) have been defined. A system architecture will be created even before the first development iteration begins. The resulting architecture document won't be limited to a single type of UML diagram since it's impossible to express a complete architecture using a single kind of modeling diagram. While it's out of the scope of this sidebar text to explain how to provide a complete architecture document, you should consider reading about the 4+1 View Model approach to software architecture on www.rational.com/products/whitepapers/350.jsp.