I am quite humbled by these speakers and their ability to zero in on what is relevent and what they are trying to communicate. Although I know no perl, no python, and no klingon, I see how this is quite relevent to java. It just shows how java can rediscover its spirit and allow what I call "literate programming". My wish is that java will be in such a position that one can develop a substantial application in a single day. One should consciously aim for simplicity even in the face of complexity.

Being in portland this week I have the pleasure of talking to my daughter on the phone. This morning she was asking me to do a favor when I get back. I said sure and asked her what it is. She stumbled a few times and finally got around to saying www. Then she proceeded from the pause to say whether I could help her go to www.combarby.

"Dad, but, do you where www.combarby is? It is on the computer. So can you help me go there?"

And there was an enormous doubt in her mind whether Daddy is capable of this after how bungling I was with her newly acquired gameboy. She was wondering if I could take help from Ashley in case if I am not up to the task.

I have got up at 5 yesterday, (sunday morning), to catch the 7:25 flight, having overslept an hour. My gracious wife zipped me to the airport only to realise the american airlines an hour late. No big deal, 8:25, and I still have an hour to wait the connecting flight in Dallas.

My luck starts to kick in and the flight leaves at 9:30 with an advanced guarantee that I will miss the Dallas flight. The next flight is at 4:30 Dallas time. After 5 hours hours of the Dallas airport and the very efficient american front desk I manage to get into the flight at 4:30. Luck continues to favor and the flight was grounded in favor another plane, another gate at 6pm.

Needless to say with luck on overdrive, I couldn't find my luggage.

Well as it happened the luggage routers managed to find a flight that the very efficient front desk managed to miss and got to portland by noon.

With verve and poise, despite all that I managed to get into my Mariott room at midnight eastern time.

I believe I will give american a few more years before I try again

General structure of an html page
Abstract data model
Data specification
Horizontal JSP painting
Typed JSP painting
XSLT painting

Seeking space

In 1992 I was at OOPSLA in Atlanta and Alan Kay in his key note pointed to the importance of MOP: Meta object protocl in languages. He reasoned with such a facility programming can metamorphosize itself in to newer versions as it is true with evolutionary biology. Subsequently there was a session on Aspect Oriented Programming by a team from Xerox.

Over the years

I have watched this space over these years. I was more interested in MOP than AOP itself. I have felt that having the programming elements exposed as a datamodel for run time manipulation will open the doors for creativity and out-of-the box solutions.


It has been a while I have looked at the various JSRs and what is happening in the newer releases of java such as Tiger or 1.5 whichever it is called. I seem to be pretty happy with java 1.3. I sat in a tutorial session this morning on AspectJ. Looks like AOP is back in the running with multiple books and particularly with support in Eclipse. AOP is especially useful in container and framework designs. The question is how intrusive it is to the fundamental java programming environment.

Other enviornments

There seem to be more than one implementation of these ideas. It is worth looking into see what each one offers.

The oldman and the rook that never moved

There is a fable I have heard once. A Russian grandmaster was on a vacation to the Indian sub-continent and visiting a village. He has heard of an old man in the village who plays chess and purportedly very good at it. For amusement the grandmaster plays a game and looses the game. And he asks the old man how come he never moved any of his rooks in the entire game. The old man answered that he never knew the rules of how a rook moves.

AOP is quite significant and there is no denying it. As Alan Kay rightly puts it once in a while in a monochromatic world there arrives a blue line. At the same time as the above story illustrates we rarely tend to master and optimize what we already know. We need both: the old man and the blue line.

Sample Implementations
Updates and queries separated
Updates redirect to queries
Abstract redirection
Using response.sendredirect
Clientside Redirector:Javascript
Serverside Redirector
Using cache
Invalidating cache
Sample implementation
Sample list of parts
Work flow parts
IOC further explored for parts
Beginings of interoperable parts between frameworks
Declaring relational data sets
Typed relational data sets
Data from sql
Data from stored procedures
Data from files
Container managed Transactions
Writing your own adapter
A pipelined web transaction
A database query part
A text substitution part
A database update part
Substitution part example
Substitution part example using IOC

Uses web views
Removes blogging headers
Removes change headers
Allows shear content inside a master page

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
URL definition
Asking for generic transformation
Generic transformation api
Excel example generic transform
Ideas on language binding transforms
Code usage
Data Definition

15) Identity lecture


Enterprise identity
Structure of a master page
Structure of html
URL specification
Master page specification
Master source code
URL example of paging
Data definition
SQL with rowids
Cursors and decorators
Javscript: Figuring out next page

20) OSCON 2005 in brief


People, languages, technologies, a short note

21) OSCON 2005 Notes


Personal notes in preparation for the upcoming presentation on JAXB at OSCON 2005, Portland
Declarative URLs
Transformation definition
Data definition
JSP transform example
XSLT transform example
Your session dates and times follow for the O'Reilly
Open Source Convention in Portland, Oregon,
July 26-30, 2004:

- Conference Session
  Session ID: 4995
  Title: Server Side Java Patterns for Developing Thin Clients
  Date: 07/28/2004
  Time: 1:45pm to 2:30pm
  Location: Salon C
Implementation configuration
Abstract Http Events
Responding to events
Business logic
Solved using horizontal parts
Solved using vertical typed parts
Both solutions enabled for remoting
Tier-less computing demonstrated
A pipeline of parts
Transaction aware work flow part
Connection ownership
Alternate strategies
What is TDP
TDP Specification
TDP Data model
TDP Usage
TDP Reusable parts
A hierarchical data set data model
Equivalent class definition
Data specification
Language bindings
Language class generation
Start with a declarative api
Why declarative
Why not declarative
Adding discoverability with wrapper modules
Auto generate modules
Benefits of typed interfaces
Contains example code for working with configuration
XML configuration files
Property file configuration files
Reading mandatory keys
Providing default values
Reading objects from configuration files
Configuration as a data source for objects
XML Child, attribute equivalence
Multiple configuration files treated as a single configuration source
Simple object instantiation
Simple object instantiation: using IMultiInstance
Simple object instantiation with parameters
Simple object instantiation with parameters and IOC
Untyped creator pattern
Untyped creator pattern with configuration parameters
Abstract typed factory
Abstract typed factory 1
Abstract typed delegate
Portland is quite pretty, and July seem to be pretty reasonable for someone visiting from Florida. I have a session this year covering some server side java patterns that I have practiced, or ran into or those that just happened. This is quite a large effort for a 45 minute session. I am scheduled to cover around 15 patterns in that space (I might successfully read their names in that time period). Not to be discouraged, I will be writing about each pattern a series of articles that are going to be published between now and the begining of my session. In case an unsuspecting individuals manage to stray this side they should be treated with a full blast java code.