servlet

A tag library that encapsulates core functionality common to JSP pages

A tag library that encapsulates core functionality common to JSP pages

The interpretation is that text-based JSPs get at core functionality (eventually implemented as Java classes) through a standard tag library.

Text-based documents that are compiled into servlets and define how dynamic content can be added to static pages, such as HTML pages.

Text-based documents that are compiled into servlets and define how dynamic content can be added to static pages, such as HTML pages.

This is a subtle case that demands some fine tuning of the analysis model.

A UML Artifact is used to represent the text-based JSP, from which a specific servlet is compiled. However, although the source text says that 'Text-based documents that are compiled into servlets', the UML™ Parsing Analysis convention requires that the Dependency is FROM the comiled servlet to the text-based JSP, since the JSP can't possibly depend on something that may or may not exist yet or ever be compiled.

The *Page is now modelled as a composite w.r.t. *Content, which content may by static (and thus does not depend on anything else) or dynamic. in which case it must - at least indirectly - depend on results, which are obtained either from a database query or from, for example, a Java method directly. Note that the results must be formatted before they are incorporated as content.

The consideration of substitutability of *Page for *Content is now extended with a remark that it may work indirectly, using "tagged values" of the editorial stereotypes to add metadata.

In any case the analysis model is still holding up quite well.

Java programming language classes that dynamically process requests and construct responses, usually for HTML pages (composite structure)

Java programming language classes that dynamically process requests and construct responses, usually for HTML pages (composite structure)

This composite structure diagram version now nicely reflects the request and response flows indicated by the source text, and with consistent JavaEE versions of the architectural classes.

Java programming language classes that dynamically process requests and construct responses, usually for HTML pages (port version)

Java programming language classes that dynamically process requests and construct responses, usually for HTML pages (port version)

The previous analysis of a generic Java EE server seems invites comparison with this source text sentence about servlets. Since we are dealing with analysis classes, there is nothing wrong with assigning a Port to *Servlet, even if this has no direct comparison in a reverse-engineered "designed" Java EE Servlet implementation.

There are still some loose ends in the analysis model. It's clear by now that the 'web tier' is simply part of what was elsewhere called the 'middle tier', however *Tier_web was earlier given its own *Serve Interface. Is this perhaps identical to what was elsewhere introduced as the *Serve Interface for Java EE ? A stereotyped Dependency is introduce to help track this proposition.

This port-based class diagram is still only preparation for a composite structure diagram showing the resulting request and response flows ..

Java programming language classes that dynamically process requests and construct responses, usually for HTML pages

Java programming language classes that dynamically process requests and construct responses, usually for HTML pages

Here we distinguish between 'servlets' as a technology and a *Servlet class, written in the Java language (and also of course involved in JavaEE).

The source text «wrapper» Component helps to tie up some of the loose ends concerning the *Page analysis class, which is extended to HTML (and also XML) using dedicated analysis models, which provide distinct namespaces.

Note the Generalization "ladders" ! This is an indication that the analysis is converging.

Note also that we are now dealing directly with the more specific JavaEE versions of the analysis classes.

We could introduce some analysis operations with *Request as an argument and *Response as a return value, however in this case it will be left until later, so that reverse-engineered operations of a "designed" Servlet class can be referenced by the «wrapper» Component.

The above "associative" diagram is useful, however it does not offer much of a sense of flow of request and response; for that we need ports, as shown next ..

[Java Web Services Development Pack (JWSDP)]

The content or the technology discussed here is HISTORICAL or ARCHIVAL
The content or the methodology here is OBSOLETE !

Has been replaced by GlassFish.

Syndicate content