[Ldsoss] Scout Tracking

A. Rick Anderson a_rick at earthlink.net
Wed Jun 7 12:22:30 EDT 2006


There are fundamentally two architectures.

Standalone and online.  Any discussion we can have about the merits and 
demerits of both have been repeated ad-nausea for every application 
since the birth of the Internet.

If we try to boil the ocean on the first pass, the project is doomed 
from the beginning.  Can you image what would have happened if Linus 
Torvalds had tried to release Red Hat as a replacement to Minux?

Get something that works well and that installs well on a local machine. 
  Refactor it so that the business tier, the presentation tier and the 
model tier are distinct.

Drop it on a disconnected appserver and add an additional presentation 
tier to prove that the refactoring is sufficient.  It won't be, so count 
on additional refactoring.

Now you have a functional solution that is worth debating 
security/privacy/convience issues about taking online.

The worst case scenario is, you have a solution that works for you, and 
that others can install and that will work for them.

Pushing security concerns into the application logic itself, is IMHO, 
absolutely poor design!!!  Security and security policies are 
cross-cutting concerns that should be done declaratively in a security 
policy manager, or at worst, in the appserver.

As a ward member, do you really want to have to log in and validate 
against every piece of functionality restricted to members on the church 
website.  Ex: Once I log in once, switching to the ward webmaster mode 
doesn't require a new authentication.  Why?  Because the authentication 
is done at the middleware layer, not the individual application layer.

-- 
A. Rick Anderson



More information about the Ldsoss mailing list