Login | Register
My pages Projects Community openCollabNet

Discussions > cvs > cvs commit: joist/www/doc/overview basic_processing.html benefits.html data_layer.html index.html overview.html properties.html redirection.html security.html servlet_hierarchy.html session.html skeleton.html three_tier.html

Project highlights: Architectural Overview

joist
Discussion topic

Back to topic list

cvs commit: joist/www/doc/overview basic_processing.html benefits.html data_layer.html index.html overview.html properties.html redirection.html security.html servlet_hierarchy.html session.html skeleton.html three_tier.html

Author commitlogger at hocus dot collab dot net
Full name commitlogger at hocus dot collab dot net
Date 2000-02-02 03:52:04 PST
Message davidp 00/02/02 03:52:04

  Modified: www project_bugs.html
  Log:
  Added header and cleaned up list items code.
  
  Revision Changes Path
  1.2 +13 -31 joist/www/project_bugs.html
  
  Index: project_bugs.html
  ====================​====================​====================​=======
  RCS file: /home/tigrisc/joist/​www/project_bugs.htm​l,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- project_bugs.html 2000/02/02 11:47:02 1.1
  +++ project_bugs.html 2000/02/02 11:49:51 1.2
  @@ -1,38 +1,20 @@
  -<TABLE BORDER="0" CELLPADDING="2" WIDTH="98%" BGCOLOR="white">
  -
  +<TABLE BORDER="0" CELLPADDING="2" WIDTH="100%" ALIGN="center">
  + <TR>
  + <TD BGCOLOR="#f0f0f0" VALIGN="top" ALIGN="left"><A HREF="http://joist.tigris.​org/index.html"><IMG SRC="/images/joist_logo_sm.gif" WIDTH="85" HEIGHT="35" BORDER=0 ALT="Joist Project Home"></A></TD>
  + <TD BGCOLOR="#f0f0f0" VALIGN="bottom" ALIGN="right"><FONT FACE="Arial, Helvetica, sans-serif"><S​TRONG><I>ho​sted by tigris.org</I>​</STRONG></​FONT></TD>
  + </TR>
   <TR>
  -<TD WIDTH="100%" BGCOLOR="#CCCC99"​><STRONG><f​ont color="#000033"
  -FACE="Arial, Helvetica, sans-serif">
  -Project Helm Bug Tracking
  -</font></S​TRONG></TD>​
  +<TD COLSPAN="2" WIDTH="100%" BGCOLOR="#CCCC99">
  +<STRONG><FONT COLOR="#000033"
  +FACE="Arial, Helvetica, sans-serif">Project Joist - Bug Tracking</FONT​></STRONG><​/TD>
   </TR>
  -
  -
   <TR>
   <TD WIDTH="100%" HEIGHT="100" BGCOLOR="#f0f0f0">
  -
  - <UL>
  -
  - <LI><A href="/bugs/enter_bu​g.cgi">Enter a new bug</A>
  -
  - <LI><A href="/bugs/query.cgi">Query the bug database</A>
  -
  - <LI><A href="/bugs/reports.​cgi">View bug database metrics</A> </LI></UL>
  -
  -
  -<BR>
  + <UL>
  + <LI><A HREF="/bugs/enter_bu​g.cgi">Enter a new bug</A></LI>
  + <LI><A HREF="/bugs/query.cgi">Query the bug database</A></LI>
  + <LI><A HREF="/bugs/reports.​cgi">View bug database metrics</A></LI>
  + </UL>
   </TD>
   </TR>
   </TABLE>
  -<BR>
  -<BR>
  -<BR>
  -<BR>
  -<BR>
  -<BR>
  -<BR>
  -<BR>
  -<BR>
  -<BR>
  -
  -<BR>
  
  
  

  Added: www/doc/overview basic_processing.html benefits.html
                        data_layer.html index.html overview.html
                        properties.html redirection.html security.html
                        servlet_hierarchy.html session.html skeleton.html
                        three_tier.html
  Log:
  The architectural overview document.
  
  Revision Changes Path
  1.1 joist/www/doc/overvi​ew/basic_processing.​html
  
  Index: basic_processing.html
  ====================​====================​====================​=======
  <HTML>
  <HEAD>
  <TITLE>The Joist Framework</TITLE>
  </HEAD>
  <BODY BGCOLOR=FFFFFF TEXT=000000 LINK=0000FF VLINK=800080>
  <h1><div align="center">The Joist Framework</div​></h1>
  <h2>Basic Processing Flow</h2>
  <p>In a nutshell, a client request is routed to a servlet, which does some security checking, then performs the requested action. The servlet determines what will be displayed as a result of the request, then hands off to the WebMacro template engine to render the HTML, which is returned to the client.</p>
  <p>Clearly this is glossing over a lot of details. </p>
  <p>As a request comes in from an HTTP client, it is routed by the web server to the servlet engine. The servlet engine determines which servlet to run and invokes its doGet() or doPost() method. All this is standard stuff handled by Apache and JServ. The WMServlet handles the doGet() and doPost() in a uniform manner. WMServlet expects its subclasses to implement the handle() method.</p>
  <p>The servlet request may specify an action, either as the result of the user pushing a button on a form, or via the URL query string. UnsecureServlet looks for the value of <code>Button​</code>, and saves it in the WebContext as the <code>action​</code>. The application servlet processes the requested action if it can; otherwise, the user is redirected to the UnauthorizedAccess page.</p>
  <A HREF="three_tier.html" rel=next rev=prev>Next<​/a><br>
  <A HREF="servlet_hierar​chy.html">Prev​</a><br>
  <A HREF="index.html"​>Contents</a>​<br>
  </BODY>
  </HTML>
  
  
  
  1.1 joist/www/doc/overvi​ew/benefits.html
  
  Index: benefits.html
  ====================​====================​====================​=======
  <HTML>
  <HEAD>
  <TITLE>The Joist Framework</TITLE>
  </HEAD>
  <BODY BGCOLOR=FFFFFF TEXT=000000 LINK=0000FF VLINK=800080>
  <h1><div align="center">The Joist Framework</div​></h1>
  <h2>Benefits</h2>
  <p>
  The Joist Framework supports the development of web applications written in java. It builds on top of the Servlet API to provide the application-level services required for a secure, dynamic, database application. Such services include:
  <ul>
  <li>Session management
  <li>Database connection pooling
  <li>Permissions based security
  <li>Login and logout
  <li>Automatic login when accessing a secure form
  <li>Cookie and non-cookie session tracking
  <li>Template-based forms interface
  <li>Security and template-based layout for static pages
  <li>SSL forms encryption
  <li>Form data validation
  <li>Data layer resource cleanup
  <li>Consolidated logging
  <li>Housekeeping required for every request
  </ul>
  By factoring out the services, Joist allows application developers to focus more on the business logic of the application and less on the "plumbing."
  </p>
  <p>
  Joist also facilitates application development by implementing or exemplifying accepted design patterns.
  <ul>
  <li>Three-tier architecture
  <li>Relational data storage
  <li>Object-Oriented Design
  </ul>
  </p>
  <A HREF="basic_processi​ng.html">Next<​/a><br>
  <A HREF="index.html"​>Prev</a><b​r>
  <A HREF="index.html"​>Contents</a>​<br>
  </BODY>
  </HTML>
  
  
  
  1.1 joist/www/doc/overvi​ew/data_layer.html
  
  Index: data_layer.html
  ====================​====================​====================​=======
  <HTML>
  <HEAD>
  <TITLE>The Joist Framework</TITLE>
  </HEAD>
  <BODY BGCOLOR=FFFFFF TEXT=000000 LINK=0000FF VLINK=800080>
  <h1><div align="center">The Joist Framework</div​></h1>
  <h2>Data Layer</h2>
  <p>This page is a work in progress ;^)
  </p>
  <h3><a name="data">DataM​anager</a><​/h3>
  <p></p>
  <h3><a name="table">Tabl​eManager</a>​</h3>
  <p></p>
  <h3><a name="cleanup">Cl​eanupManager</a​></h3>
  <p></p>
  <A HREF="index.html"​>Next</a><b​r>
  <A HREF="index.html"​>Prev</a><b​r>
  <A HREF="index.html"​>Contents</a>​<br>
  </BODY>
  </HTML>
  
  
  
  1.1 joist/www/doc/overvi​ew/index.html
  
  Index: index.html
  ====================​====================​====================​=======
  <TABLE BORDER="0" CELLPADDING="2" WIDTH="100%" ALIGN="center">
    <TR>
      <TD BGCOLOR="#f0f0f0" VALIGN="top" ALIGN="left"><A HREF="http://joist.tigris.​org/index.html"><IMG SRC="/images/joist_logo_sm.gif" WIDTH="85" HEIGHT="35" BORDER=0 ALT="Joist Project Home"></A></TD>
      <TD BGCOLOR="#f0f0f0" VALIGN="bottom" ALIGN="right"><FONT FACE="Arial, Helvetica, sans-serif"><S​TRONG><I>ho​sted by tigris.org</I>​</STRONG></​FONT></TD>
    </TR>
  <TR>
  <TD COLSPAN="2" WIDTH="100%" BGCOLOR="#CCCC99">
  <STRONG><FONT COLOR="#000033"
  FACE="Arial, Helvetica, sans-serif">Project Joist - Documentation - Architectural Overview</FONT​></STRONG><​/TD>
  </TR>
  <TR>
  <TD COLSPAN="2" WIDTH="100%" BGCOLOR="#f0f0f0">
  <H1>Contents</H1>
  <OL TYPE=1>
      <LI><A HREF="benefits.html"​>Benefits</A​>
      <LI><A HREF="overview.html"​>Architectural Overview</A>
      <LI><A HREF="basic_processi​ng.html">Basic Processing</A>
      <LI><A HREF="servlet_hierar​chy.html">Servlet​ Hierarchy</A>
      <LI><A HREF="three_tier.html">Three Tier Architecture</A>
      <LI><A HREF="security.html"​>Security</A​>
          <OL TYPE=A>
              <LI><A HREF="security.html#​permission">Permi​ssion</A>
              <LI><A HREF="security.html#​role">Role</A​>
              <LI><A HREF="security.html#​authorization">Au​thorization</A​>
              <LI><A HREF="security.html#​scope">Scope</​A>
              <LI>SSL
          </OL>
      <LI><A HREF="redirection.ht​ml">Redirection​</A>
          <OL TYPE=A>
              <LI><A HREF="redirection.ht​ml#servlet">Servl​et-to-Servlet Redirection</A>
              <LI><A HREF="redirection.ht​ml#scheme">Redire​ct for Scheme</A>
              <LI><A HREF="redirection.ht​ml#cancel">Redire​ct to Cancel</A>
          </OL>
      <LI><A HREF="data_layer.html">Data Layer</A>
          <OL TYPE=A>
              <LI><A HREF="data_layer.htm​l#data">DataManag​er</A>
              <LI><A HREF="data_layer.htm​l#table">TableMan​ager</A>
              <LI><A HREF="data_layer.htm​l#cleanup">Cleanu​pManager</A>
          </OL>
      <LI><A HREF="session.html"​>SessionManager​</A>
      <LI><A HREF="properties.htm​l">Properties files</A>
          <OL TYPE=A>
              <LI><A HREF="properties.htm​l#zone">Zone Properties</A>
              <LI><A HREF="properties.htm​l#site">Site Properties</A>
              <LI><A HREF="properties.htm​l#servlet">Servle​t Properties</A>
          </OL>
  </OL>
  </TD>
  </TR>
  </TABLE>
  
  
  
  1.1 joist/www/doc/overvi​ew/overview.html
  
  Index: overview.html
  ====================​====================​====================​=======
  <HTML>
  <HEAD>
  <TITLE>The Joist Framework</TITLE>
  <META name="description" content="">
  <META name="keywords" content="">
  </HEAD>
  <BODY BGCOLOR=FFFFFF TEXT=000000 LINK=0000FF VLINK=800080>
  <h1><div align="center">The Joist Framework</div​></h1>
  <p>The SourceXchange site is comprised of dozens of application servlets all sharing a common framework. The framework takes care of the common processing that happens for every request, thereby relieving the author of an application servlet from having to worry about them. Application authors can, instead, focus on the specific business functionality particular to the application.</p>
  <p>The basic design follows a three-tier architecture. The UI component is separate from the business logic, which is distinct from the data storage. In broad strokes:
  <ol type="1">
      <li>The UI is implemented using WebMacro templates. WebMacro is an open-source templating engine developed for java servlets (more later).
      <li>The business logic is implemented as java servlets and application specific business classes.
      <li>The data storage is implemented in a MySQL relational database accessed via JDBC.
  </ol>
  <p>The basic processing goes roughly as follows. A client request is routed to a servlet, which does some security checking, then performs the requested action. The servlet determines what will be displayed as a result of the request, then hands off to the WebMacro template engine to render the HTML, which is returned to the client.</p>
  <A HREF="servlet_hierarchy.html" rel=next rev=prev>Next</a>
  <A HREF="index.html"​>Contents</a>​<br>
  </BODY>
  </HTML>
  
  
  
  1.1 joist/www/doc/overvi​ew/properties.html
  
  Index: properties.html
  ====================​====================​====================​=======
  <HTML>
  <HEAD>
  <TITLE>The Joist Framework</TITLE>
  </HEAD>
  <BODY BGCOLOR=FFFFFF TEXT=000000 LINK=0000FF VLINK=800080>
  <h1><div align="center">The Joist Framework</div​></h1>
  <h2>Properties</h2>
  <p>This page is a work in progress ;^)
  </p>
  <h3><a name="zone">Zone Properties</a></h3>
  <p></p>
  <h3><a name="site">Site Properties</a></h3>
  <p></p>
  <h3><a name="servlet">Servlet Properties</a></h3>
  <p></p>
  <A HREF="index.html"​>Next</a><b​r>
  <A HREF="index.html"​>Prev</a><b​r>
  <A HREF="index.html"​>Contents</a>​<br>
  </BODY>
  </HTML>
  
  
  
  1.1 joist/www/doc/overvi​ew/redirection.html
  
  Index: redirection.html
  ====================​====================​====================​=======
  <HTML>
  <HEAD>
  <TITLE>The Joist Framework</TITLE>
  </HEAD>
  <BODY BGCOLOR=FFFFFF TEXT=000000 LINK=0000FF VLINK=800080>
  <h1><div align="center">The Joist Framework</div​></h1>
  <h2>Redirectio​n</h2>
  <p>In order to navigate effectively through a set of applications, the joist framework provides some redirection mechanisms for common situations.
  </p>
  <h3><a name="servlet">Se​rvlet-to-Servlet Redirection</a​></h3>
  <p>The joist framework supports modular servlet design. Servlet developers can choose to put all application processing into one big servlet, or they can break up the processing over a set of servlets. The sourceXchange site modularized according to the dictum of one servlet per page. Thus, for example, a servlet is responsible for displaying a particular form and for subsequently processing that form.
  </p>
  <p>In the course of processing a request, a servlet can determine what page should be displayed next. If the next page is generated by another servlet, then the current servlet needs to redirect to the next servlet. This can be done by redirecting through the client (e.g., a browser) and is commonplace. On a high-traffic site, though, a full browser redirect can be expensive. For these servlet-to-servlet redirects, the joist framework can mimic a full redirect by redirecting internally, thus saving the network overhead.
  </p>
  <h3><a name="scheme">Redirect for Scheme</a></h3>
  <p>Some pages need to be secured through SSL. Pages that display or prompt for passwords in particular must be encrypted. Credit card numbers, social security numbers, and other sensitive information should be encrypted as well. By using the https protocol (or "scheme"), the communication between client and server is secured with SSL.
  </p>
  <p>The joist framework provides an easy way to stipulate that a page be secured; each servlet can specify the appropriate scheme in its properties file (as <code>servletS​cheme=</code>)​. Switching back and forth between http and https requires a full client redirect. Joist handles the redirection automatically.
  </p>
  <h3><a name="cancel">Redirect to Cancel</a></h3>
  <p>Has this ever happened to you? You work through a sequence of forms, then you get to the last screen, and there are no links to follow or buttons to push. You have to either use the "Back" button or retype the home page URL. I hate being stranded like that. I also feel that the flow through the site, and the applications particularly, should never require using the "Back" button. The user should always have a navigation path.</p>
  <p>Thus the motivation for the "Cancel" button. We can quibble over the name, but the intent is to provide the user with an escape to a familiar screen should he ever head down the wrong path or into a dead end. Application servlets can register themselves as good targets for a cancel request. The framework maintains a stack of these cancel-to targets. The user can repeatedly cancel to unwind back to a good starting point for moving forward. If no cancel-to target is on the stack, cancel takes the user to his start page by default.</p>
  <p>The cancel-to mechanism maintains the servlet name, action, and context for each cancel-to target, so the user can cancel back to, say, an RFP browse screen with its search criteria intact. </p>
  <p>The mechanism eliminates duplicates. When the user revisits a servlet that is a cancel-to target, it pops the stack back to that servlet. Returning to the StartPage pops the stack entirely.</p>
  <A HREF="index.html"​>Next</a><b​r>
  <A HREF="basic_processi​ng.html">Prev<​/a><br>
  <A HREF="index.html"​>Contents</a>​<br>
  </BODY>
  </HTML>
  
  
  
  1.1 joist/www/doc/overvi​ew/security.html
  
  Index: security.html
  ====================​====================​====================​=======
  <HTML>
  <HEAD>
  <TITLE>The Joist Framework - Security</TITLE>
  </HEAD>
  <BODY BGCOLOR=FFFFFF TEXT=000000 LINK=0000FF VLINK=800080>
  <h1><div align="center">The Joist Framework</div​></h1>
  <h2>Security</h2>
  <p>Joist ensures that only those users who are properly authorized can access any given application (i.e., web page). A user must have the proper permission to access the application, then must have the authority to access the requested data.
  </p>
  <h3><a name="permission"​>Permission</a​></h3>
  <p>The underlying mechanisms evaluate access in a number of ways.
  </p>
  <p>First, each application servlet has a base permission assigned via its properties file (as the value for <code>permissi​on=</code>). This check is done right away when processing a request, and quickly weeds out users who have no business accessing the application.
  </p>
  <p>Second, each action that an application servlet can process has an associated permission. The user must have that action-specific permission in order to proceed. These permissions are hard-coded in the application servlets themselves. They could be factored out into the servlet's properties file if we felt the need.
  </p>
  <h3><a name="role">Roles​</a></h3​>
  <p>Since there are likely to be lots of permissions defined for a full suite of applications, joist provides a way to administer them. Users will be accessing applications in a variety of capacities, or Roles. For instance, some users will act as administrators, others as super-users, and others still as casual visitors.
  </p>
  <p>Each Role represents a set of Permissions. The same Permission can be assigned to many Roles, and more that one Role can be granted to a User. So when a new user is added to the system, the administrator simply assigns a role to the user, rather than having to assign each permission individually. This is something akin to assigning groups for unix accounts.
  </p>
  <h3><a name="authorization"​>Authorization​</a></h3>
  <p>Once the servlet has established that the user has the proper permissions to access the application and perform the action, it then determines if the user has the authority to be acting on the data that is the subject of the request. For instance, for a user account maintenance application, the user may have the permission to update information for users in his group (however that group is defined), but the application must ensure that he is updating only accounts he is authorized to update, i.e., are in his group.
  </p>
  <p>The authorization check can be expensive. It usually involves hitting the database, perhaps several times, to resolve the issue. For this reason, the permission checking, which is fast and does not involve hitting the databse, is done first.
  </p>
  <h3><a name="scope">Scop​e</a></h3​>
  <p>There is a notion of scoping underlying all this. In large part, a Role implies some degree of authority over a certain set of objects. The scope of authority is relative to the user (e.g., is the account in the user's group?). The rules for assessing the scope are specific to the definition of the role and the type of data (e.g., the Group Admin role implies some set of rules to establish what a group is and whether an account is in the group).
  </p>
  <p>Since a user can have potentially many roles, the application must determine which scope is operative for a given request. The joist framework does not impose a one-size-fits-all mechanism for application servlets to establish scope of authorization, but instead prescribes an API; applications implement to that API in whatever way is optimal.
  </p>
  <A HREF="index.html"Nex​t</a><br​>
  <A HREF="index.html"​>Prev</a><b​r>
  <A HREF="index.html"​>Contents</a>​<br>
  </BODY>
  </HTML>
  
  
  
  1.1 joist/www/doc/overvi​ew/servlet_hierarchy​.html
  
  Index: servlet_hierarchy.html
  ====================​====================​====================​=======
  <HTML>
  <HEAD>
  <TITLE>The Joist Framework</TITLE>
  </HEAD>
  <BODY BGCOLOR=FFFFFF TEXT=000000 LINK=0000FF VLINK=800080>
  <h1><div align="center">The Joist Framework</div​></h1>
  <h2>Servlet Hierarchy</h2>
  <p>Since we're using WebMacro, all joist servlets indirectly subclass WMServlet instead of HttpServlet directly. Common functionality has been factored out to two abstract classes, UnsecureServlet and SecureServlet. All joist application servlets subclass one or the other of these.</p>
  <pre>HttpServlet
  |
  +---- WMServlet
        |
        +---- UnsecureServlet
              |
              +---- UnsecureServlet
                    |
                    +---- SecureServlet
                    | |
                    | +---- e.g., MilestoneAnnounce
                    |
                    +---- e.g., UserRegistration
    
        </pre>
  </p>
  <h3>UnsecureSe​rvlet</h3>
  <p>The bulk of the code is in UnsecureServlet. It is primarily responsible for processing the request according to the specific application servlet, then invoking the WebMacro template engine with the proper template and associated data.</p>
  <p>The servlet request may specify an action, either as the result of the user pushing a button on a form, or via the URL query string. Some common actions, such as the <a href=redirect_cancel​.html>redirect for Cancel</a>, are processed directly by UnsecureServlet.</p>
  <p>Servlet redirection is handled by UnsecureServlet. It implements a set of convenience methods for initiating a redirect. It also intercepts the redirect and, when possible, handles it internally, thus avoiding sending the redirect back to the browser. </p>
  <p>When transitioning between SSL-secured servlets and those that are not SSL-secured, redirects must go back to the browser, though. The fact that a servlet is SSL-secured or not is configured via <code>servletS​cheme=[https|http]​</code>in its properties file. The default is http. The redirect for http-to-https and https-to-http transitions is triggered automatically.</p>
  <p>UnsecureServlet ensures that, barring any over-ride, the default template for the application servlet is offered up for rendering the response html. The <code>servletT​emplate</code>​ property in the servlet's properties file specifies the servlet's default template. The application servlet has the perogative, in the course of its processing, to over-ride the default, though this is not the usual case.</p>
  <p>The UnsecureServlet also acquires a database connection for the duration of the request. The connection is saved in the WebContext so that any object involved in the servlet processing can use it (and knows where to find it by convention). When the request is fully processed, the connection is returned to the connection pool.</p>
  <p>UnsecureServlet takes care of some basic housekeeping, such as ensuring that standard information is present in the WebContext. It also reads the servlet's default template from <code>servletT​emplate</code>​ in the servlet's properties file. The application servlet has the perogative to over-ride the default, though this is not the usual case.</p>
  <h3>SecureServ​let</h3>
  <p>The SecureServlet extends UnsecureServlet by enforcing that the user has logged in first. If not, the user is rerouted to the Login screen.</p>
  <p>The rerouting through the Login screen preserves the original request such that the user is routed there following successful Login. So if the user tries to update a proposal, but has not yet logged in, he will be asked to Login first. If the login is successful, he with be routed to the proposal update screen automatically. By default, the Login page leads to the user's StartPage (personal home page)</p>
  <p>The SecureServlet also enforces that the user has at least the base level permission to be accessing the specific application servlet at all. Each servlet's base permission is specified in its properties file (as <code>permissi​on</code>)<​/p>
  <A HREF="basic_processi​ng.html">Next<​/a><br>
  <A HREF="index.html"​>Prev</a><b​r>
  <A HREF="index.html"​>Contents</a>​<br>
  </BODY>
  </HTML>
  
  
  
  1.1 joist/www/doc/overvi​ew/session.html
  
  Index: session.html
  ====================​====================​====================​=======
  <HTML>
  <HEAD>
  <TITLE>The Joist Framework</TITLE>
  </HEAD>
  <BODY BGCOLOR=FFFFFF TEXT=000000 LINK=0000FF VLINK=800080>
  <h1><div align="center">The Joist Framework</div​></h1>
  <h2>Session</h2>
  <p>This page is a work in progress ;^)
  </p>
  <h3>SessionMan​ager</h3>
  <p></p>
  <A HREF="index.html"​>Next</a><b​r>
  <A HREF="index.html"​>Prev</a><b​r>
  <A HREF="index.html"​>Contents</a>​<br>
  </BODY>
  </HTML>
  
  
  
  1.1 joist/www/doc/overvi​ew/skeleton.html
  
  Index: skeleton.html
  ====================​====================​====================​=======
  <HTML>
  <HEAD>
  <TITLE>The Joist Framework</TITLE>
  </HEAD>
  <BODY BGCOLOR=FFFFFF TEXT=000000 LINK=0000FF VLINK=800080>
  <h1><div align="center">The Joist Framework</div​></h1>
  <h2>Yadda Yadda</h2>
  <p>
  </p>
  <h3>whatever</h3>
  <p></p>
  <A HREF="basic_processing.html" rel=next rev=prev>Next<​/a><br>
  <A HREF="index.html"​>Prev</a><b​r>
  <A HREF="index.html"​>Contents</a>​<br>
  </BODY>
  </HTML>
  
  
  
  1.1 joist/www/doc/overvi​ew/three_tier.html
  
  Index: three_tier.html
  ====================​====================​====================​=======
  <HTML>
  <HEAD>
  <TITLE>The Joist Framework</TITLE>
  </HEAD>
  <BODY BGCOLOR=FFFFFF TEXT=000000 LINK=0000FF VLINK=800080>
  <h1><div align="center">The Joist Framework</div​></h1>
  <h2>Three-tier Architecture</h2>
  <p>The basic design follows a three-tier architecture. The UI component is separate from the business logic, which is distinct from the data storage. In broad strokes:
  <ol type="1">
      <li>The UI is implemented using WebMacro templates. WebMacro is an open-source templating engine developed for java servlets (more later).
      <li>The business logic is implemented as java servlets and application specific business classes.
      <li>The data storage is implemented in a MySQL relational database accessed via JDBC.
  </ol>
  <h3>Separation of User Interface from Business Logic</h3>
  <p>Ignoring the data storage for the time being, the application servlet is split into two main parts: the business logic and the user interface. This dichotomy reflects the current best practices for application development. The business logic deals with satisfying the requested action, such as an update or a query, and determines what should be displayed as a result. The user interface determines how the results are displayed to the user. The business logic is coded in java as a servlet. The user interface is coded in HTML as a WebMacro template.</p>
  <p>This split allows for parallel development of the business logic and user interface. These are often done by different individuals, each bringing unique talents to their tasks, and their skill sets do not overlap, as a rule. The UI designer can develop templates in html without worrying about how the data is retrieved. The business logic author can develop java code to accomplish application tasks and retrieve data to be sent to the user without worrying about how that data is presented. The UI designer and the java coder simply agree on what data is of interest, and each can then go off and work independently.</p>
  <p>The split also allows for multiple UI's to sit on a given servlet. By the same token, a single UI could serve for multiple servlets. By splitting UI from business logic, we can mix and match as the situation dictates.</p>
  <h3>The Business Logic Tier</h3>
  <p>The business logic resides primarily in a set of DataManager classes. Generally, there is a DataManager class for every kind of business object. Nearly all sXc biz objects are stored in the database. TableManager is a subclass of DataManager specifically for managing relational tables.</p>
  <!-- A HREF="xx.html" rel=next rev=prev>Next<​/a><br> -->
  <A HREF="basic_processi​ng.html">Prev<​/a><br>
  <A HREF="index.html"​>Contents</a>​<br>
  </BODY>
  </HTML>

« Previous message in topic | 1 of 1 | Next message in topic »

Messages

Show all messages in topic

cvs commit: joist/www/doc/overview basic_processing.html benefits.html data_layer.html index.html overview.html properties.html redirection.html security.html servlet_hierarchy.html session.html skele... commitlogger at hocus dot collab dot net commitlogger at hocus dot collab dot net 2000-02-02 03:52:04 PST
Messages per page: