About
When developing server-side applications, one have to deal with diversity of challenges repeating over and over again, perhaps with slight variations.
Some of the challenges might be:
data persistency, such as: relational database, object database, flat file, XML file [10], EJB, etc.
remote data access / transportation, such as: TCP/IP, ORBs like CORBA [8] or RMI[16], EJB, HTTP, etc.
user (client) request processing mechanism, such as: API specific to server environment like JSDK [15], etc.
business logic separation / execution, such as: stored SQL, JSQL, customized procedures, ...
controlled access to resources, such as: eRights, JavaTM package "java.security.acl", etc.
user authentication / authorization, session tracking, such as: JSDK, RMI v2.0, CORBA, etc.
presentation / data / business logic separation, such as: model-view-controller architecture, JSP, XML/XSL, etc.
utilities such as debugging, logging, workflow pipeline, object (connection) pooling, many others.
There is number of ways of satisfying the challenges. Some of them are provided by the tools used for building the application or more precisely by the libraries which comes with the tool (RAD components, ResultSet in JBuilder [21], eRights, etc). Some other imply from the used technologies (session in JSDK, ResultSet in JDK), other are provided by runtime environment (application servers: EJB containers, logging facility, etc) and many have to be implemented (if not covered in the previous cases).
The process of building an application in many situations consist of an attempt to cover as much as possible of the required needs by combination of tools, libraries and runtime environment to minimize the need for custom development.
Such an approach might lack the presence of thoughtful architecture design because the designer is restricted by the limitation of available resources (tools). Also, different tools might use different approach and it is usually difficult to make them work together well.
The problem which I'm trying to sketch now is 1) repeat-ion of the solutions and 2) thoughtful complexity of the solution. Let me explain what I mean by that on a simple example: in my research of current solutions, I've seen repeatedly implemented feature of obtaining parameter (say HTTP parameter) value. This seemingly simple procedure might consist of many steps:
get parameter value (as value type "string" by default)
if the parameter is missing then make a choice:
either start exceptional situation handling (if the parameter is required)
or use default value (if any)
convert the value into other desired type (integer, date, etc)
verify parameter value (range, format, type, etc).
The previous sequence could also be represented as an interaction diagram, just like the one in figure 1.1.
Figure 1.1: Interaction Diagram: Example of parameter processing
This example is a perfect opportunity for "copy & paste" kind of development, it is no problem to repeat large number of code lines without much of a thinking (and therefore introducing number of possibilities for buggy and difficult to be maintained code). The more advanced designers would introduce a component (such as "Arguments") to reduce this repetition.
The "thoughtful complexity of the solution" means that one should think of the "Arguments" component as a source of data. Therefore if there is other component dealing with conversion into XML format then such should not care of all about the possible input types (like Arguments, ResultSet, Properties, Hashtable, Vector, ...), but instead consider data source abstraction approach which would help to abstract from specific data type. Obviously such abstraction has deeper roots, it is not only used for "Arguments" to be easily converted into XML.
The goal of my work is to propose a standard to design of server-side components which would cover most of the challenges and would be open to continuously cover new ones as they come. The proposed architecture, called OOSTD, consist of many design patterns --- either known ones or my own --- which ensures the complexity of the solution (yes, "Arguments" component exists and can be seamlessly converted into XML format without any further development). My vision is to initiate discussion over the proposed architecture, maintain open source version of it and include all the good contributions anyone can make.
When such an architecture is in place, then the design work is minimal and development effort can be focused on user interface and business logic. Note that the architecture also provides solutions for the business logic separation --- services --- and also support for user interface. See chapter 7 ("Complex Solutions with OOSTD") for more about this.