Marcus-
Hopefully a reading of the prior art on layered architecture will shed some
light on what the community regards as the application layer. Some
prominent authors in this area include Martin Fowler, Kyle Brown, and Chip
Wilson (see http://www.gemstone.com/javasuccess/layered_arch_pattern.html
for a list of literature references).
The presentation layer consists of pure UI widgets - e.g., subclasses of
java.awt.Component or, in a web UI, HTML and javascript elements. The
application layer is responsible for mediating between these widgets and the
back-end sources from which they get their data values. Historically in
four-layer architectures, these back-end sources are traditional domain
objects. Nowadays in distributed architectures, which tend to have five
layers (the fifth being a "services" layer between the application layer and
the domain layer), these back-end sources are more likely remote services
(session beans) that return domain objects and/or state to the client.
The application layer is implemented by Frames and Panels, or
ApplicationModels in Smalltalk, or, as I asserted, servlets or JSP beans in
a java-generated web UI. Clearly the servlets or JSP beans are typically
responsible for invoking the session beans to get the data values that go
into the dynamically-generated HTML, right? As we've defined it at
GemStone, the responsibilities of the application layer are: i) mediating
and adapting (a la the GoF patterns) between the presentation-layer widgets
and the back-end services; ii) maintaining conversational state; and iii)
handling exceptions thrown by the services layer.
It is true that old-style servlets (ones that generate HTML) can be
considered part of the presentation layer, because they generate it - but
that is not all they do; they also invoke the back-end sources. In a "model
2" JSP UI, the servlets don't generate HTML - rather, they invoke back-end
sources and pass data values back to JSP pages via JSP beans. Therefore
they are pure application-layer components. In a "model 1" JSP UI, the JSP
beans perform that function instead of servlets, and form the application
layer. In both models of JSP UI, the compiled JSP classes can be considered
part of the presentation layer for the same reason that old-style servlets
can.
Since the servlets and JSP beans are so customized to support the use cases
going on, and so "close to the glass", they form the natural place to store
conversational state. In their context they know the selections of data the
user has made, the edits s/he has made, and the actions s/he is trying to
take - therefore they have the most context with which to invoke services,
retry failed invocations, give error messages to the user and redirect the
user, etc.
Best Regards,
Randy Stafford
Senior Architect
GemStone Professional Services
> -----Original Message-----
> From: Marcus Ahnve [SMTP:[EMAIL PROTECTED]]
> Sent: Wednesday, April 19, 2000 2:25 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Largest EJB Implementation ?
>
> Randy Stafford wrote:
> >
> > Marcus Ahnve wrote:
> >
> > > > It
> > > > then becomes a design choice where to store it. Storing it in
> stateful
> > > > session beans may limit scalability, as you suspect. What is wrong
> with
> > > > storing it in HttpSession state?
> > >
> > > Because then every client has to store their own session instead of
> just
> > > being responsible of displaying things to the users.
> > >
> > [Randy Stafford] It is the responsibility of the presentation
> layer
> > to display things to users. The application layer, implemented with
> > servlets or JSP beans, for example, is responsible for mediating between
> the
> > presentation layer and the services layer, and is a logical and likely
> place
> > to store conversational state.
>
> I regard the servlet/jsp as being part of the presentation layer, and
> therefor not the natural place for storing sessions. However I'm curious
> about what you are calling the application layer, I guess that it's
> mentioned in your "iCommerce, design issues and solutions" paper which I
> unfortunately have not yet had the time to read. But easter is coming up
> with a lot of sparetime so I might just have changed my mind come
> monday. Otherwise I'll be back with a lot of new arguments ;-).
>
> /Marcus
>
> Marcus Ahnve
> Sun Java Center
> Sweden
>
> ==========================================================================
> =
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
