jasonkitty
Project home

Currently they are many MVC frameworks that trying to decouple the web-tier from the business-tier. Nevertheless, most of these frameworks are still requesting the developers to develop codes in JSP and/or some other action classes that tied to the web-tier. Why not making a framework to allow a "configurable" way to attach the html parameters and inject the back-end services/objects into a POJO action class; and have the action class to call the proxied object to perform the appropriate action and return the results?

The underlying architecture of this framework is still adapting to the standard MVC patterns. There will be a central controller servlet to dispatch the views to html pages and a servlet to populate the views with values from the server side objects/services. These are all enabled in an XML configuration.

This framework might be integrated with Spring framework to locate the server side objects/services, or it will provide its own proxy objects to wrap the server side objects/services. Once the server side objects/services are located, it will be injected into a POJO action class. The server side object/service could be a POJO, an EJB, a Web Service or a Corba object.

For e.g.:

If there is a back-end service to retrieve the user fund transfer transaction and it is an EJB. In the XML configuration, I specify the connection and lookup attributes of this service and develop an action class as bellow: -

public class UserTransactionAction

{

            private Service service;

            private Collection userFundTransferTransactions;

            public UserTransactionAction();

:

:

            public setService(Service service)

            {

                        this.service = service;

            }

            :

            :

            public String performRetrieveFundTransferTrans(String userId)

            {

                        try

                        {

                                    userFundTransferTransactions =

service.getFundTransferTrans(userId);

                        }

                        catch (Exception e)

                        {

                                    return “Error”;

                        }

                        return “Passed”;

            }

}

Also, In the XML configuration, I specify the action to be performed is to call the “performRetrieveFundTransferTrans” method of this action class. When the user submit the request from the web page, the framework will lookup the service based on the configuration, create a proxy object of the service and inject the service into the action class by calling the “setService” method (as above). Therefore when the “performRetrieveFundTransferTrans” is being called, the proxied service will be called upon to perform the operation. The return results will be stored in the action class itself and later the framework will call the respective “getXXX” methods to retrieve these results and forward them to the next page. As you can see, the action class is a POJO and there is no interface to HTTP request and response objects which tied the application to the web tier.

The views of the system are purely HTML pages (or other types such as XHTML, DHTML or WML). The contents to be displayed on the page are specified like grapping environment parameters in UNIX shell scripts. For e.g.: -

<form name=”fundtrans” action=”…”>

:

<tr>

<td>USER ACCOUNT NUMBER : </td>

<td>${USERACCOUNT.NUMBER}</td>

</tr>

<tr>

<td>TRANSFER AMOUNT : </td>

<td> <input type="text" name="uid" size="20" maxlength="20" value=”${TRANSFER.AMOUNT}”></td>

</tr>

<tr>

With this design, the HTML pages are totally decoupled from the back-end and the web designer is not required to learn different JSTL tags for populating the web contents. In accordance with these, there should be some Server Side Include (SSI) features to be provided to handle some dynamic contents populations such as “IF-ELSE” server side include on the HTML page etc. Obviously, the works assigned could be cleanly separated between software developers and web designers.

In the future, the developers will be focusing in developing back-end services that adapt to the SOA architecture. In terms of unit/system testing, it will be easier. This is because the software developers could focus on developing and testing the back-end services. The action classes could be served as the client classes for testing the back-end services as well.

The Road Map:

1) Ajax ability might be incorporated into this framework so that the developers do not need to write complicated javascripts.

2) In the future, same framewok might be developed for Microsoft platform to access COM objects directly using the HTML pages.

3) In the future, it should also catering the mapping of XForm's fields to back-end's attributes.