Skip to main content

business applications development: piecing the puzzle

Posted by eitan on May 10, 2005 at 7:35 AM PDT

extreme programming tells us:
don't waste your time building features that you don't even know yet you're going to need

that's so true and many of us have in the past been bit by this tendency to try to
forecast a need.

however, i find that one can look at software application development in general and come
up with a list of infrastructural tasks that are performed repeatedly and menially each

that is, that there is room for improving the general productivity of software developers.

more specifically, if we look at the class of applications known as business applications,
we will find that irrespective of the domain model, support for the following basic features will
always be needed:

1 persistence
the basic ability to store and restore objects from a persistence store
2 object lifecycle management:
creating, viewing, editing, and deleting objects
3 validation
ties in to object creation: what consitutes a valid entry for an object:
which fields are required, what is the set of valid values for a field,
4 defaults
prototype objects for types
5 search / query
the ability to perform searches / queries against a large repository of objects
6 reporting
for a search, the ability to customize what specific fields to return, in what
order, and how to dress it up for printing (or producing pdfs)
7 authorization
who is allowed to view, edit, create, and delete objects
8 calendaring / scheduling
for objects that are 'schedulable', the ability to view these objects in some
sort of calendar layout, and the ability to perform scheduling activities on
them (change time, date, duration, etc..)

i haven't bothered to make the above list complete. other services should be
on that list (remoting, other aspects of security, transactions, registries,
directories, and in general: guis, and state management, internationalization,

irrespective of the object model in question, these services are going to be required.
i think this idea is the basis for j2ee:
the notion that there exists a list of services that some kind of container or framework
can supply that should not be reinvented each time.

i've heard gavin king rightly complain that [in some respect] the vision for j2ee has
not been realized to its potential in that the list of services has not really grown beyond
the original set:
security, transaction, jndi/lookup, remote connectivity, persistence, authorization,
application management

my contention is that there can/should exist [in the ideal] a container for running business
applications that provides support for all these services [1-8 above] and more.

i can imagine an ecosystem where service providers with expertise in specific [shall
we call them..] aspects of business application development can plug in alternative implementations
for services into the business application container.

here's an example of something that has always disturbed me:
the fact that a software developer has to make a choice whether the gui for their
software application should run inside a web browser or whether it should be implemented
using a different toolkit such as swing.

again, i can imagine a business application server/container that gives you the choice.
just like persistence, the ui is orthogonal to the business domain. so the basic idea
is that the developer concern himself/herself only with supplying the business domain
in question: the implementation of the object model.

the end result should be an app whose objects can be created, edited, viewed,
browsed, searched, reported upon, and much more.

i can think of two frameworks that, at first glance, one might think: "there cannot
possibly exist another pair of frameworks that are as far removed from one another, that
are as polarized from one another." these two frameworks/containers are:

yet i've come to realize that these two frameworks have much more in common than
first meets the eye: they both attempt to provide a framework or container
that generically solves certain aspects of business application development.

the difference lies in the choice of services that each has decided to support.
j2ee makes security and transactions generic. nakedobjects makes the ui generic.
there actually is an overlap: they each address (or try to address) the problem of
generically persisting objects.

in the meantime we saw o/rm vendors solve that problem properly. yet there'd been an
"impedance mismatch" between the o/rm solutions and the container designs.
the o/rm solutions could not be plugged in to a j2ee or nakedobjects container with ease.
this is in my mind what ejb3 solves: the mating of the right o/rm solutions with a
generic business application server/container. or the formal separation of these
two concerns: the container and the persistence manager.

robin roos (of jdo fame) has recently made a number of postings to the nakedobjects
mailing list. one of his messages dealt with the issue of being able to plug in
a jdo-based persistence mechanism into nakedobjects.

so, the vendor that builds the container should not be the vendor that provides
the service. well, they can be, but we should recognize that the two require
expertise in different domains.

what i want to see is more of a "unified field theory" for business application containers
and services, so to speak. a generic blueprint for plugging in services into a completely
specified container, including services that have not even been thought of or
identified today

let's talk about Ruby On Rails (RoR). It fascinates me how all of these disparate
discussions and disparate solutions are all part of one large problem. sometimes
it's hard to see. i am no RoR expert. in fact i'll admit it: i have only skimmed
the RoR web site thus far.

i believe that the success of RoR stems directly from the fact that it exploits
the redundancies that exist today across the development of business applications:
the fact that developers today manually do things that a container could do for
them, for free:

1 persistence
the basic ability to store and restore objects from a persistence store
2 object lifecycle management:
creating, viewing, editing, and deleting objects

and more. RoR delivers on that. and it makes developers much more agile.

if i understand it correctly, many of RoR's design ideas were inspired by the
NakedObjects (NO) framework.

so my forecast is that such an ecosystem will come to be. RoR so far looks
like the one leading the race.

Related Topics >>