Tuesday, May 29, 2001 06:36 AM
To answer this I first need to describe my motivations for modeling. We
model to understand things better, and to communicate them. So with this
in mind we need to ask ourselves, what is it we want to comprehend or
communicate about the runtime structure of a J2EE web app?
In my mind the key areas of interest are where in the system are the key
components running? Where are the important threads of execution running
and what processes/nodes own them. Additionally I'd want to identify the
communication links between them.
The specific answer to your question of course is for one instance of a J2EE
architecture. There are many different ways to architect this, for example
jBoss provides a distribution that has the web server and EJB container running
in the same JVM. Other architectures separate this.
My recommendations for modeling this are to model each and every JVM as a
<>. This probably means that the web server and
servlet processor (i.e. Tomcat) are one <> class. I'd
also create an abstract class called MyAppServlet and stereotype it
<>, and as you suggested use a composition relationship
with an 0..n multiplicity. At this point you may want to specialize this
class with the key servlet types in your system. The only reason you might
want to do this is that not all of them will have RMI connections to the same
middle tier servers. Specializing might be advantageous, if certain servlets
communicate with a different set of EJB servers (i.e. shopping servlets
communicate with read only catalog databases, while order and inventory servlets
communicate with a different set of state changing EJB servers.
The modeling of middle tier servers will vary greatly, especially if you have
different types of servers. If you do have separate JVMs for different
types of business logic, then this is where modeling of this runtime process
stuff is really of benefit. Name the important threads appropriately.
When modeling the communication links, I'd stereotype them something more
meaningful than TCP/IP. Things like RMI, HTTP, HTTPS, WAP, DCOM (shudder),
and maybe even SOAP, are more insightful to me, since they give me some idea of
what technologies are involved, and what level of skill is required to modify
them and connect other things up to them. I'd draw the
connections from <> to <> if
Hope this helps.