Web Applications

I have been involed in architecting and writing web applications as long as there has been a “web”. Recently, I have been doing due dilligence on web architectures. Most architectures recognize the value in the Model 2 (or MVC) approach in their design. But is this this sufficient?

This is a work in progress so excuse the mess and please check back for updates.

Intended audience

This article is geared towards enterprise web applications. An enterprise web
application in the context of this article consists of the following:

  • An application backed by some well defined business process.
  • At least one developer per tier (JSP, Servlet and business process)
    with the ability to easily scale to multiple developers per tier
    without resource contention.
  • There is a well defined development and release cycle. That is,
    development is not ad-hoc.

If your application does not fall under the above constraints then the
concepts defined herein may not apply. For example, introducing Model 2
into an environment where there is only one developer may kill productivity
due to the overhead associated with the multiple layers.

Starting points

There are just as many starting points as there are web frameworks.
Below is an attempt to enumerate a few of the initial conditions
for a web-enabled application.

  • Scratch. Nothing exists except a set of requirements.
  • A business process exists that is exposed via a well-defined API.
    This API may or may not be tooled for the pecularities of a web
    application.
  • An exsiting application that is to be web-enabled. Depending
    on the architecture of the application, this may fall into the
    case above. In a worst-case scenario the application is tightly
    coupled to a presentation mechanism (such as a monolithic VB app).
What’s going on?

I was originally going to do a full write-up on the request / response, MVC, and the like but after re-reading Designing Enterprise Applications
with the J2EE(TM) Platform, Second Edition
and MVC Detailed it would be significantly redundant.

I will be updating this entry with more information using the above link as a reference.

Advertisements

2 comments

  1. how would a unification help (the application) being developed ? the fact that the input is HTTP is an artifact of the environment it is coming from (the browser). Not too sure if SOAPing it would change much (probably degrade performance if anything) – the only thing that comes to mind is that one would )to an extent) think of server side and from-client interactions as simply – interactions.
    maybe i will understand more as u take this forward

  2. The unification comment was derived from another entry that I was working on that required more background info to it. I just butchered that entry and brought it into this one. Thank you for your comment though. There are a bunch of turds in there that need cleaning up, explaining, and moving around. Hold tight hopefully things will get better!
    Having said all of that, I do not want to discourage comments at this point. In fact, they’re more important early on to prevent me from going off the deep end of insanity!


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s