Home ›

Java EE Container

The EJB container runs on the Java EE server and manages the execution of an application's enterprise beans.

This diagrams illustrates a number of useful aspects of the UML™ Parsing Analysis approach.

There is a lot of resuse of analysis elements now, mostly the work involves just tweaking aspects of existing elements.

It is implied that EJBs execute, which is modelled as an analysis operation, with a Dependency from the source text «wrapper» Component to the Operation, so that it can be traced.

We are told that 'enterprise beans' are 'of an application', so the Association 'provide the business logic in' is strengthened with shared aggregation of the multiple :EJB[*] Property, and a Dependency is drawn from the «wrapper» Component to its Property symbol within *Applicaton_JavaEE. The other Property end is named "'of'", to become of:*Application_JavaEE.

OK, now we have some analysis models of the Java EE containers, it's time to summarise their relationship to a Java EE server ..

The EJB container is the interface between enterprise beans, which provide the business logic in a Java EE application, and the Java EE server.

This is the first time that any specific information about the Enterprise JavaBean (EJB) has been given in the Your First Cup: An Introduction to the Java EE Platform source text.

If you have followed this UML™ Parsing Analysis demonstration trail from the beginning you may recall that the analysis model - as driven strictly by the Your First Cup: An Introduction to the Java EE Platform source text - did not converge well around the 'business component' and 'business logic' concepts, which part of the analysis model to date is reproduced in all its glory (or should I say gory detail) below the «wrapper» Component for this source text sentence about EJBs, not only as a demonstration of the incredible power of the UML™ Parsing Analysis recipe in handling complex and/or confusing and/or contradictory documentation, but also because business logic is so very vital to this demonstration, especially as these analysis «wrapper» Components are to be bound to reverse-engineered "designed" Java EE Classes and Interfaces, as we work deeper into the First Cup demonstration.

Is the EJB the rescue ? Is it in fact simply the 'business component' that was modelled as *Component_business ?

For now it will be tentatively assumed that the EJB is indeed "substitutable" for it. However then it is no longer clear that a Java EE *Server aggregates *Component_business, as indicated by the analyst's "challenge" «wrapper» Component. To resolve this more examples of the use of EJBs are needed from the Your First Cup: An Introduction to the Java EE Platform source text.

There are cases when it is NOT a good idea to try to "divide and conquer", and this is one of them; here we need to see in one place all relevant analysis elements and relevant source text «wrapper» Components.

Please don't be intimidated by the complexity of the unconverged part outside the "focus" source text «wrapper» Component about EJBs. Just for now trust that the UML™ Parsing Analysis recipe - if followed patiently - will sort this out, and by building these analysis foundations well one can build and/or bind good designs on top of it. It is about making architectural words "run" via UML.. What is about to come is nothing short of amazing, and is well worth the effort !

The EJB Container

A UML™ Parsing Analysis navigation diagram after the structure of Your First Cup: An Introduction to the Java EE Platform.

The application client container runs on the client machine, and is the gateway between the client application and the Java EE server components that the client uses.

If the 'application client container runs on the client machine', then it seems that a (Java EE) 'client application' does not connect directly to a Java EE server at all, so the usage Port that *Client_Application inherited from the more general JavaEE *Client would seem to be invalid for Java EE application clients (although it does seem valid for the generic JavaEE client, as indicated by the related
source text «wrapper» Components shown).

It could act as 'the gateway between the client application and the Java EE server components' by in fact acting as a client to the Java EE server "on behalf of" the application client, so *Container_ApplicationClient has tentatively been given a usage Port to the Java EE *Serve Interface.

It seems the way 'that the client uses', and the way the application client container access, the Java EE server components is indirect and networked.

This is clearer in the next diagram, which shows (hybrid) connected composite structures ("systems engineering view"), rather than the associative "interface dependency wiring" architectural view.

The application client container is the interface between Java EE application clients, which are special Java SE applications that use Java EE server components, and the Java EE server.

This is an important (and somewhat complex) diagram, because the source text sentence from Your First Cup: An Introduction to the Java EE Platform so immediately relates to many analysis elements to date, and it raises some new questions.

Firstly, are all 'Java EE server components' contained (i.e. containable) ?

The 'application client container' has been given its own version of the *Serve Interface of *Container. Is this the same as (or related to) the *Serve Interface of the Java EE *Server ? And can a Java EE Server only serve via containers anyway ? Answers will have to wait until further clarifying source text (recalling that under UML™ Parsing Analysis one endeavours to model the available source text only, rather than injecting what one might already "know").

The concept 'application client' has been previously referred to in Your First Cup: An Introduction to the Java EE Platform:

Java EE servers are sometimes called application servers, because they allow you to serve application data to clients, much as how web servers serve web pages to web browsers.

Note that the above does not say 'Java EE application client'. To carry the new concept (with a usage Port to the *Serve Interface of the 'application client container') a distinct *Client_Application is introduced (in keeping with the UML™ Parsing Analysis naming convention used in this tutorial).

This diagram introduces another UML™ Parsing Analysis technique, the "nowrap" «wrapper» Component, which buffers graphically contained elements from the focus source text «wrapper» Component, as a graphical convenience.

The Application Client Container

A UML™ Parsing Analysis navigation diagram after the structure of Your First Cup: An Introduction to the Java EE Platform.

The special UML™ Parsing Analysis notation *Container_ApplicationClient implies that somewhere else in the analysis we expect to find an associated analysis Class *ApplicationClient. The underscore '_' can be read as "of", and sometimes the portion of the name after the underscore is later converted into part of a namespace.

The container manages the component's lifecycle, dispatches requests to application components, and provides interfaces to context data, such as information about the current request.

This source text from Your First Cup: An Introduction to the Java EE Platform is subtle. Let's break it down piece-by-piece for treatment by UML™ Parsing Analysis.

'The container' is taken to be the web container, clear from the context.

The snippet 'manages the component's lifecycle', is taken to refer to a web component as explored in the analysis of:

A web component can be a servlet, a JavaServer Faces Facelets page, or a JSP page.

It is granted a distinct named Association from *Container_web to *Component_web, as well as an Association to a statemachine for *Component_web (taken to represent the states of the lifecycle), and - just for comparison - also to a separate *Lifecycle Class, which in the analysis represents those aspects of the lifecycle that can't be encapsulated by states.

The snippet 'dispatches requests to application components', begs the questions: What kind of requests are meant ? And what exactly are 'application components' ?

The snippet 'and provides interfaces to context data, such as information about the current request' is modelled using a UML Interface provided (under the strictly port-based form of UML™ Parsing Analysis) via a Port, the multiplicity of which is shown using an "element property callout" into a UML Note.

Is the 'current request' the request sent by a remote client ?

A web component can be a servlet, a JavaServer Faces Facelets page, or a JSP page.

Is this source text sentence from Your First Cup: An Introduction to the Java EE Platform mixing apples and oranges ?

The analyst has indicated here that there is no way (at least not in this UML™ Parsing Analysis model to date) that a 'web component can be .. a JavaServer Faces Facelets page, or a JSP page', which are modelled here as UML $Artifacts$. The question is asked whether it is better to consider the special kind of servlet generated from a JSP page, and presumably also from a Facelet page, as a 'web component'.

The web container is the interface between web components and the web server.

As before, the way the 'web components' and and the 'web server' "interface" via the 'web container' is not yet clear from the Your First Cup: An Introduction to the Java EE Platform source text.

Syndicate content
[book] Submitted by webel on Tue, 16/12/2008 - 14:54
Unified Modeling Language
OMG Systems Modeling Language
Java Get Powered
PHP
Powered by MySQL
Powered by Drupal
Lunarpages.com Web Hosting