"Transforming Legacy Systems to J2EE Architecture" is a living reference document for anyone involved in the design and architecture for organizations to transform their legacy systems to Java 2 Enterprise Edition (J2EE) based applications. It also discusses the software components commonly utilized for developing applications. These components provide the development team with tools to speed up implementation, ensure robust applications, and offer services and flexibility that would not have otherwise been possible. The components fall into two categories: the primary components explicitly given to the architects, designers and build leads, and supporting components that are used by the primary components but will likely not be invoked directly. Read Transforming Legacy Systems to J2EE Architecture

The link (stage.theserverside.com) does not work. It seems the article *has* moved from staging to the production machine, but the link hasn't. The following link works: http://www.theserverside.com/tt/articles/article.tss?l=LegacySystemsJ2EE

There is very little in this article on migrating legacy application to J2EE. Looks more like a catalog of patterns.

Isn't this article about 5 years too late? Today its title should be "Transforming Legacy Systems to another Legacy Architecture".

Isn't this article about 5 years too late? Today its title should be "Transforming Legacy Systems to another Legacy Architecture".

Amusingly, very true :-) Part II is transforming legacy web based applications to JSFs using JBuilder. -John-

That J2EE = EJB. A common but serious misconception. J2EE is "a standardised range of enterprise services" (to quote Rod Johnson) not an architecture.

"J2EE is 'a standardised range of enterprise services' (to quote Rod Johnson) not an architecture." what's the difference? thats just a Spring comment to confuse the masses, which is what Spring thrives on: confusion. I might not be peace and love enough for the Glassfish and Seam teams that integrate Spring, but i see little in the way of community when the leader of the Spring movement makes comments that detract from JEE, which is what is commonly done on TSS threads, as well. I find that laughable, and self-detrimental, for there is not a prayer in the world that a company would invest in Spring were it not for its relationship with JEE. I apolgize for not being a Spring user, maybe some company I work with will, and I'll have to market a different tune, but when people come on and slam JEE functionality as something other than the enterprise platform of choice, I choose to respond...

Not me! I've been using J2EE since its inception and I think it's great. I merely felt it pertinent to point out that J2EE is NOT an architecture, any more than breeze-blocks, girders and glass are a building (even though any given building may contain any or all of them, and much else besides). If you asked your team-leader to explain the architecture for a project and received the answer, "It's J2EE", would that tell you what you need to know? If you asked for a summary of the architecture of a building and received the answer "We're going to use bricks"... See what I'm driving at?

Nicely written, but expected to see a message transformation stage. Assuming that web requests arrive and reply in a markup language, but legacy applications generally used fixed positioned data structures, I could see the request/response transformation layer? Can you point out where this is in your diagrams? Thanks, Terry