Looking over the web framework included with the PetStore application, it seems that one of the features is that it frees the developer from writing code to navigate the remote interface between the web and
EJB tiers.
In the conventional (non-framework oriented) examples of remote access to EJB beans, the EJB defining a remote interface, and the client looks up the specific bean's home interface, gets a reference to the specific bean, invokes its methods, and deals with remoting exceptions, etc.
What the WAF does for you (among other things) is to provide a generic remote interface used for the passing of EJB event objects and the return of EJB result objects. The user merely writes his event and result object subclasses and handlers; but the remoting code for passing requests and results between tiers remains generic.
This is all very nice, and as an architect I might say "We shall use such-and-such framework." But it seems to me that to detail the framework classes and the messages passed between them would be inappropriate use of my efforts. After all, the developers have better sources of information on how the framework operates.
But how do I show the interactions between J2EE components _without_ getting into the details of the framework classes? Should I say that the message-passing shown in my sequence diagrams is not to be taken literally -- that a business-oriented message in my sequence diagram might actually be implemented by a bunch of internal, framework-oriented operations that are not shown?