Home > Articles > Programming > Java

  • Print
  • + Share This
This chapter is from the book

Program-centric Architecture

Many J2EE programmers view the Program-centric architecture as the only method. This is a distributed methodology that divides up resources, making it easy to scale and make future updates to. This model is roughly based on the Method-View-Controller (MVC) programming construct.

MVC programming basically breaks up applications into three primary parts:

  • Controller—The Controller controls the flow of data, and determines where to direct requests both into and out of the system.

  • Model—The Model is the processing and data layer. This includes processing business logic, storing data, and performing functions. This layer is where the real work is done.

  • View—The View is the layout of the program and what the user actually sees—the user interface.

This is a very rudimentary look at the MVC model. MVC is used effectively by desktop application developers, but when it comes to Internet programming, there are a number of different variables that come into play.

The Program-centric approach uses this methodological approach at its core. Typically, there is a servlet that will act as the Controller, processing requests and calling the appropriate processing logic. This processing logic, the Model layer, is usually handled through a combination of Java classes, JavaBeans components, and Enterprise JavaBeans components, with a database server storing data. Finally, the View is output using JSP pages into multiple XML formats. Figure 2 shows roughly what the Program-centric architecture looks like.

Figure 2 The Program-centric approach divides up code into three layers: the Controller layer, the Model layer, and the View layer.

This is, of course, a simplified view of this methodology. There are actually a number of programming approaches that are roughly based on the MVC approach using the J2EE environment that takes advantage of different subsets of J2EE, including the Java Message Service (JMS), Java Naming and Directory Interface (JNDI), Remote Method Invocation (RMI), and even using Simple Object Access Protocol (SOAP) XML Web services.


Sun has published a specification document that includes its recommendation for developing fully robust and scalable J2EE applications. You can find this information at http://java.sun.com.

There are many significant advantages to using this approach. First, because the logic and processing is separated from the view and controller, this logic can be used in other applications, including non-Web applications.

This method is also highly scalable. Separate parts can be broken out and moved to other servers, or refined on an individual basis. Using EJB, RMI, or Web services, you can actually distribute code to be used remotely. This means that processing logic can be used on different application servers on different networks throughout your organization.

Using this method will always avoid the occurrence of spaghetti code. Spaghetti code is what happens when you build a program in a non-modular fashion and then continually go back and make changes to it: deleting old pieces, adding new pieces, working around pieces, and so on. Most programmers have experienced spaghetti code at some time. It's not fun, it doesn't perform well, and eventually the whole thing will need to be reprogrammed from scratch.

In addition, using the Program-centric approach, new features simply become modules to the core application. This makes the quality assurance process shorter. If you have already load-tested and debugged the core functions, you will need to test only the new module—you won't need to modify anything from the core.

Because the View layer is separate, upgrades to the UI can be made without having to worry about the underlying code. This means that as HTML specifications change, you can adapt easily without having to worry about logic behind the layout. This means that your designers and programmers don't have to get in each others' way any more. Additionally, new devices and markup languages can be integrated, including Wireless Markup Language (WML), Handheld Device Markup Language (HDML), and Voice XML (VXML).


A really smart method for administering your View layer is to consistently output XML or XML-compliant HTML (XHTML). Then, the controller aspect of your application can sniff what type of device is calling your application, and apply the appropriate XSL transformation to translate that page for the user's device.

  • + Share This
  • 🔖 Save To Your Account