Most of today's web is driven by server side programming. PHP, ColdFusion, J2EE, Asp.Net, are all frameworks that allow server side programming. To say that server side programming is multi-disciplinary is an understatement. It is more like skating on a field of spikes. The spikes are many. There are tiers to cross, there are protocols to follow, there are multiple programming languages to learn, there are sessions to deal with, there are transactions to manage, security to worry about, scalability to plan for. The goal of the server side programming practice is to deliver a smooth platform on top of these spikes so a developer may perform a programming ballet with freedom.
Server side programming practice is increasingly converging on a set of similar patterns for solving these problems. Although there are distinctions in the provided solutions, it is possible to slice the techniques into recognizable, identifiable patterns. Understanding these patterns will benefit a developer in the following ways:
- Ease the transition between ever changing and numerous server side frameworks
- Enhance an existing framework with the additional patterns for a much smoother ride
- Understand the problem space of server side programming better
Most of the presented patterns here came from developing a server side declarative framework and a tool. I believe these patterns have a value of their own irrespective of the tool in which they are nurtured.
I have divided the patterns in to the following 5 catgories
- Applicaton Patterns
- Data Access Patterns
- Business Logic Patterns
- Presentation Patterns
- http/html patterns
Application patterns
Server side programming is being increasingly abstracted out. At the moment there are three layers in server side programming. A web server, an application server and a web application. Out of the three a web server and an application server are rarely a concern for the application developer. These components are generally handled by systems programming and the framework vendors. The main focus of a server side application programmer these days is the "web application".
A web application is aptly named. This is where a programmer writes the business functionality for an application. The three patterns presented in this category further helps in moving the programmer more closer to the task at hand. The patterns presented not only applies to a web application but any application including command line applications and stand alone GUI applications.
Even an application server which I have earlier considered a systems component is an appication at its core. So the patterns presented are relevent to an application server designer as well.
Unified Configuration Dictionary Pattern: Configuration
For evolvable architectures the key I believe is unified configuration. The container (application) and the components should have a common (unified) understanding of what configuration means and how to obtain it. They should agree upon an abstract model for configuration. This pattern lays out a configuration model and an api.
Unified Object Server Factory: Factory
COM, COM+, J2EE, and CORBA are all essentially object servers at their heart. They deal with location, life time, interfaces, and numeracy of objects. This pattern brings some of those facilities and services to a regular application.
"log patterned strings" an interface centric simplistic logging pattern :Logging
Logging, like code-reviews, seem to elicit a strong response from programmers. When I designed my logging first I always intended it to be interface based. My idea was that it would give me multiple implementations with increased sophistication over time. Starting with that idea, I have introduced an api that uses a logging message and a severity code. But in practice I found it distracting to think about severity when I want to log a message while trying focus on the logic. To provide for this freedom I have opted for an extra method just to log an arbitrary string. The implementation can use patterns in this string to include or exclude in the log file. Although somewhat inefficient at run time, it stays out of the developers hair when things are quite hectic.
Abstract Application
In this pattern an application is represented as interface providing access to the services it offers as an application. The foundation services include configuration, factory, and logging at the minimum. Additional services are discovered from the factory service.
Data Access Patterns
There is a common thread that runs through all of the data access patterns that are proposed here: raise the level of abstraction from data access to data specification. You declare what data you want and where you want to get that data from. The presented patterns have a bias and a skew toward a transactional/service centric view of data as opposed to an object centric view of data.
Declarative Relational data sets
In this pattern all data assumes and gets retrieved in a relational data structure similar to row sets. The scope of the abstraction has lesser constraints compared to rowsets allowing implemenations to be quick while forgoing the power. The pattern argues for data source independence: java objects, files, databases, XML. The pattern also argues for channel independence: jdbc, url, file systems. The retrieved data sets can be presented as vertical domain objects using reflection or as horizontal data collections with its own horizontal api.
Declarative Hierarchical data sets
Expanding on the relational data set idea, hierarchical data sets allow composition of the relational data sets into value added horizontal xml like hierarchical data sets. As in relational data sets, the focus is on declarativity, ease of use, transparency of data sources, and transparency of access channels.
Typed Hierarchical data sets
As hierarchical data sets represent structured data they can be represented in altenative forms which include: xml, and objects in any supported language. This allows for type casting of hierarchical data to a language structure such as a class. This will help with discovery of fields and also run time errors while working with that data set in a language centric IDE environment.
Transparent data pipelines
This pattern establishes a pipeline between presentation and business data. Using Hierarchcial Data Sets as the backbone,this pattern provides the devleoper an artificial view of the data so that he/she can start designing presentation for it. In its simplest form think of this as firing of an sql statment and seeing the data returned in a tabulated format. Expanding on that idea in this pattern, the degree of sophistication is lot higher allowing for non-sql data and complex screen presentations. Data aspects and presentation aspects of this pattern are discussed.
Business Logic Patterns
In transactional systems like the web, Business Logic referes to the processing that takes place on data as it travells between the screens and the database.
Parts
Taking the cue from the data access patterns, particularly the motivation part: specification and not access, in this pattern the functionality of a system is packaged into reusable parts. The more horizontal the parts are, the more reusable they are. Another unsung advantage of a software part is that it hides the implementation. For example if you have a part that knows how to email, to use, you only need to know its interface. You don't have to know the API that is used to send the email. By declaratively specifying this part against an incoming URL you will be able to accomplish the email with out knowing its API.
Processing pipelines
Parts flourish and come to yield their full potential in a declarative or programmatic processing pipeline environment where the horizontal parts are stitched together to accompish a vertical business function. Special attention is paid to the programmatic aspect of the composition.
Pipeline Transactions
Although strictly speaking, transactions fall under data access, web updates provide a nice context for transaction boundaries. This pattern discusses the transactions in the context of web updates, parts, and pipelines.
Typed interface generation
Declarative programming is a double edged sword. Declartive way of developing systems is very effective for the following scenraios:
- A small number of programmers
- Small to medium complexity
- Minimal dependenies between various parts of the system
When this is not the case declarative programming needs a helping hand. This pattern shows the way by providing tools that can generate the programmable typed api facade for the declarative backend.
Tier-less computing
Sometimes we seem to love complexity. Numerous products advertise saying how they allow you to do n-tier computing. When you are a developer and developing a solution why do you want to think about n-tiers? Develop and test it in 1 tier. Then hand it over to the deployment folks. They can deploy it on any nubmer of tiers they want. The underlying architecture should be supple enough to do that. This is not to discount the fact that the network latency will not play a role. Sure it does. But for well known patterns, like the web space, you have a known set of latency behaviours that should allow you to hide them at development and expose them at deployment. The pattern focuses on programming in java and not in CORBA, not in J2EE, and not in Jini, but at the same time being able to be deploy the solutions in CORBA, J2EE, and Jini.
Presentation Patterns
Page Data: A Hierarchial data abstraction
XML being so widely used, developers most often think of data as XML and then question how they can derive and paint a page from it. Initially I came to this road the opposite way by questioning my self about an html page. Let me say I have an html page of any amount of complexity. While getting painted, this html page will ask the server side for data dynamically. This inquiry has yielded a java api with an interface called IPageData. Inside a page you will have controls with their own data requirements resulting in IControlData. Being a java api this can be satisfied by any hierarchically structrued data including objects and xml.
Pluggable transformations
Once a data abstraction is established for page level data, we can use any available technology to plot that data. We can use XSLT, JSP, or Tags, or Java itself. This freedom allows for multiple skill sets in an organization.
Generic transformations
Every html page in a web site is distinct. In that sense they are vertical. But you can view the data structure of all those pages in a uniform way as a set of hierarchical nodes. This is a horizontal view. And you can apply a variety of horizontal transforms or generic transforms on this data independent of its specific content. Some examples of generic transforms are: xml, excel, text, java classes, other metadata structures.
Web controls
Java server faces, and Asp.net server side controls fall under this pattern. I will only touch upon the primary ideas here as the details are well documented in the press.
http/html Patterns
Master pages
This pattern solves the problem of common look and feel for a set of web pages on your web site. Borrowing the idea from a power point master page, it allows the web site authors to focus on content and not the layout.
Event based declarative caching
Dynamic yet les-frequently changing content provides a challenge to the websites. This pattern provides a declarative solution to a very simple yet effective caching approach.
Strategized Session Patterns
This pattern argues for a pluggable session patterns in application servers. Provides a couple of session patterns Aspire uses out of the box.
Security/Authorization
Provides a set of horizontal patterns for providing security in web applications.
Client side redirector: Avoiding multiple updates
This pattern solves the problem of multiple submits on the web in response to refresh and back buttons.
Optimistic paging
This pattern solves the problem of paging among thousands of records from a web site with out bogging down servers.
>> Wednesday, July 07, 2004 4:59:24 PM - Comments by satya