Marcus, you wrote:
> Thanks for your long and very describing post. However, most
> respectfully, most of it described ideas and prectices used by us for
> quite some time now, only that we do not use the term "application
> layer". At Suns .Com practice, we call it the "presentation layer" which
> serves the "Client layer", i.e. the browser in this case. So I guess
> that there are parts of the community who regards that layer having a
> different name. I was curious if you had some other ideas, hence my
> question.
>
[Randy Stafford] Well, I respectfully submit that Sun's .Com
practice is inconsistent in its use of these terms with the rest of the
community (the considerable community, that includes people like Martin
Fowler and Kyle Brown) that has been writing about layered architecture -
since 1992, in the case of the Smalltalk tradition, to which Java owes much
of its heritage (see Tom Stambaugh's contributions to
http://www.c2.com/cgi/wiki?SmalltalkMinusMinus for a very insightful
perspective on the history of Java). I agree with you on the "tiering"
point - the presentation layer runs in the client tier. And the
distribution of layers across tiers has followed an interesting evolution in
the history of our profession - from all-layers-in-one-tier with file-based
persistence, to two-tier-fat-client architectures with all layers in one
tier and a remote RDBMS, to modern architectures where the presentation,
application, services, domain, and persistence layers are split across three
or more tiers.
> However, let me comment on this passage:
>
> Randy Stafford wrote:
>
> > 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.
>
> I most certainly agree with the second sentence. But to me that does not
> mean that it is also the natural place for keeping state. If the state
> to keep is defined by the service used, meaning that everybody using it
> must keep the same state, IMHO the stateful bean might as well keep it.
> If the client/application layer, using your terminology, has its own
> state (selections in boxes etc) to keep, the application layer is a good
> place for it. To me it is all a matter of responsibility.
>
[Randy Stafford] It is a matter of where to allocate
responsibility, which is the central issue in object-oriented design. Both
alternatives represent different design choices, with different
consequences. The consequence of keeping state in stateful session beans is
that this choice places a much heavier demand on server resources,
especially in a high-scale scenario. The consequence of keeping state
outside the (stateless) services layer is that different kinds of clients
all have to be coded to keep state - but to me this seems natural for the
reasons cited above, and besides, you'd probably have to design a different
stateful session bean for each kind of client, because they are different.
We have this scenario in the FoodSmart example application - we have web UI
clients, as well as (markedly different) database loader/importer clients -
all of which keep their own state but use the same stateless services layer
to accomplish their purposes.
Best Regards,
Randy Stafford
Senior Architect
GemStone Professional Services
===========================================================================
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".
