Is Tomcat-JBoss the appserver we plan to utilize? If
so, perhaps we ought to agree on a uniform version?
Since much of this development will likely occur in a
decentralized manner, sharing a common runtime
enviroment will be worthwhile.

  If the group is interested, I would be glad to add a
subproject and lists to one of my SourceForge
projects. That would give us centralized project
management and source code control (CVS).

  Before we make use of Craig's RR account for this
project, it would be wise to ascertain whether he can
event legally provide such a server over their
network. I am familiar with providers implementing a
dracionian acceptable use policy, and I would not want
to see anyone come to harm over this.

  I have a question or two after reading the Use Cases
a few times:

  The dependence on a single RegisteredUser value type
seems, at first glance, as though it might become
expensive quickly (see Use Case 5b). For most
purposes, on such a web
site, there are three types of information:  access
control (authentication and authorization),
registration (detailed account information), and
preferences (start page, favored information, etc).
The middle one is the least frequently used and often
the most significant in size. Supposing those
assertions to be true, it would seem proper to model
the use cases around lighter-weight objects.

  Is the System Administrator Agent (or actor if you
prefer) really necessary? To presume physical access,
or even shell access, does not necessarily make for an
effective deployment. If this were for a customer you
would hardly tell them that they require a database
administrator to perform certain types of routine
site-level maintenance. Would it be worthwhile to move
to a roles-based access control mechanism? Say with an
expression such as "SiteAdmin(1) > Moderator(*) > User
(*)>
Guest(*)"? Then we would simply add the cases necessary
for the SiteAdmin to change the access of a Moderator,
but a Moderator would be unable to do the opposite.

  In Use Case 1d, should the Backend be transmitting
the message? This is really not a question of where
the event should take place; the appserver is clearly
the correct spot. I think it calls us to consider the
grouping of database engine and appserver into a
single conceptual tier called "Backend". While our current
hardware constraints may make that necessary, and
there is nothing intrinsicly disordered about such a
configuration, it might be useful to still describe
them separately in the Use Cases.

  Is Use Case 2 a realistic situation? In what
context would a login lead to a reqistration request?
As a web user, I would certainly find that quite
irritating.

  The second paragraph of the "Design note" leaves me
thoughtful. While I understand the principle at use
here, the implementation does not appear to lead
obviously to the described result. In a situation
where there is stateless communication between the
Middleware and Backend, it is clearly necessary that
the User's credentials are part of each request,
otherwise there would be no point in separating User
from Administrator. By way of implication, however,
this note describes some kind of security auditability
increase derived therefrom, and more troubling still
and easy correction of problems. Unfortunately, this
does not appear to my untrained eyes to be an accurate
assessment. The communication between the browser and
the Middleware is completely not secured, and is
therefore quite easily hijacked. When you can hijack a
session, there is no serious Middleware security
because the Middleware can be made to "lie".
  Meanwhile the communication between the Middleware
and Backend is similar not secure, and also quite
easily hijacked. In that context, it makes no
difference if the Middleware is even secure because a
third party can easily implement a man-in-the-middle
attack against the installation.
  While the "Design note" may be a best practice, and
I agree with you wholeheartedly that it is, it does
not impart the benefits, to my understanding, as
described. Perhaps I am terribly mislead or ignorant.
In either case, it would be quite happy to be
disabused of this notion.

christian