Gordon’s Place

I’ve been doing a bit of thinking about architectural layers recently. The purpose of the separate layers in an enterprise architecture is pretty well understood – to isolate the layer above from the layer below. So the UI knows about nothing below the Business Logic ( BL ) layer and the BL knows nothing about the structure underneath the Data Access ( DA ) layer, i.e. the physical storage / DBMS. Obviously, this ignorance makes it much more straightforward to modify / extend a given layer, particularly if you can manage to keep the interfaces the same. The architecture I’m using at the moment has a 100% code generated DA layer and we’ve often joked about re-writing the templates so that the data is stored in flat ASCII files, rather than a Progress DB. I’m pretty sure we could do the job in a couple of hours and if definitely wouldn’t involve changes to any of the other layers.

The most common implementation of a layered or n-tier application that I’ve come across involves 3 layers – UI, BL and DA. This is exactly the model that PSC promote these days with their Open Edge Reference Architecture ( OERA ). The thing is, that while this model hides the existence of some of the lower level layers from the upper levels, it doesn’t entirely isolate a layer from the layer immediately below it.

For example, if the UI wants to run a BL routine then it’s going to need to establish a handle to the appserver or, more likely, access one which has already been established. To have established that handle, the UI will have need to have known about the host and port number for the nameserver, as well as the name of the appserver. Or maybe the BL isn’t running on an appserver in which case the UI will need to know to run the BL locally instead. Likewise, the BL will need to know how to run the DA routines and whether they are local or remote. This is not very isolated. What if I want to change some of the details of my nameserver, or if I want to move to using webservice rather than direct appserver calls? I need to visit all of my UI routines to modify them.

So what I’ve been thinking is that we really need to add some more, very thin, connector layers to this picture. The purpose of these connector layers would be the absolute isolation of the two layers either side. It should, in theory, be possible to move all or part of the BL layer onto a J2EE appserver without modifying the UI at all, only the connector layer should change. Actually, these very thin layers could be seen not even as layers but as simple plugins, as in the diagram below.

I would see these routines being implemented as PP libraries which could be easily swapped about. Actually, there would be no reason you couldn’t have more than one of these connector plugins in use, so maybe the connector layer is slightly more complex and has routines for establishing and managing the connections to remote services. If you wanted to, you could eventually get into things like load balancing, plus these layers would be a great place to code some application / performance monitoring code to watch out for things like frequently used routines / long running routines. If you got into client side caching, which I intend to do, then this layer could evolve some routing abilities – deciding whether to make a remote call or access information from the local cache. But even if you did nothing as complex as this initially, at least implementing connector layers would give you the flexibility to change the details of the underlying layers easily.

The one issue I see with this idea is serialisation. If you don’t have a standard and consistent set of interfaces in your layer, then you’re going to have to think about serializing / marshalling the data structures into some normal form in order to pass between the layers. I haven’t done much playing around with this but it would seem that both ProDataSets in V10+ / XML might be useful here, although I’d want to be careful to avoid introducing too much processing given the frequency of use.

Any comments?