Client/Server Interaction

Historically, Concourse Suite chose the Theseus MVC framework back in 2000, at a time when Struts was in early development. Theseus is lightweight, works similar to Struts, and allowed the Concourse Suite team to add value around the basic MVC functionality. The team took into consideration application security, performance, layouts, and reusable utilities to form the Concourse Suite framework.

The Concourse Suite framework uses the Model-View-Controller (MVC) web design paradigm. This methodology separates the application business logic and the presentation layer to increase reusability and minimize development time.

Starting with CRM 6, and receiving major improvements in CRM 7, URLs can be mapped to embedded portals to display pages with portlets. The flow is as follows:

In the Concourse Suite framework implementation, a single Servlet receives every web request. This Controller Servlet uses a customizable map to forward each request to a specific Java method, called an Action Class. Each Action Class has a specific task, based on an action the user is trying to complete. When the Action Class is finished, it tells the Servlet Controller and the Controller forwards the request, as well as any data that was prepared, to a JSP. The JSP uses the JavaBeans that were prepared and constructs an HTML page.

The servlet controller is responsible for processing HTTP requests, executing business logic, and forwarding the result to a JSP for presentation to the client. The resulting JSP should not contain any business logic.

The controller actually maintains and executes much more than just simple requests and responses. Review the following figure for an overview of the framework components. These components, including page layouts, hooks, security, utilities and more are discussed later.

Understanding the basic operation of the servlet controller is important. The servlet controller processes all HTTP requests made by a client in which the URL ends in ".do". For example, the following URL specifies the “Login” action: "http://127.0.0.1/Login.do".

The servlet controller maps this requested action (the part before the .do) to a Java class as defined in cfs-config.xml. So, "Login" means the controller will execute the corresponding Java class, Login.java.

If a Java Bean is specified in the web application configuration, and the HTTP request includes an “auto-populate” parameter, then the controller instantiates the Java class and dynamically populates the object with corresponding values in the request. The resulting object is intended to be used by the action class or sub-classes for the remainder of the request. This is important because the developer does not have to use the typical:

someObject.setSomeProperty(request.getParameter(“someParameter”))

since auto-populate will map HTML name-value pairs to the specified JavaBean.

The action class then processes the request and returns a single status string to the controller depending on the successful completion of the action.

The servlet controller then maps the action status string to a JSP file for dispatching to.

If a page layout or page template is specified in the mapping, then the layout and template page are dispatched instead, which will then dispatch the final JSP. This allows for menus, static header and static footer content to be re-used.

A developer will typically code an Action Class for each action the user is trying to perform. To reduce duplicate code, actions can be chained and sub-actions can be re-used by more than one action.

The dispatched JSPs contain the HTML for the client. JSPs can be stand-alone files or they can be included in other JSPs for reusability.

JSPs use the Java Beans that were instantiated during the request.

The controller implements various hooks so that the framework can be extended and customized. Hooks add additional functionality during servlet initialization, request processing, reloading, and shutdown. For example, an initialization hook might initialize a database connection pool and object cache, while a request hook might implement security functionality.

Database Portability

The framework is designed to work with commercial database servers, as well as open-source servers. To maintain compatibility and portability, Concourse Suite relies little on stored procedures and more on database independent SQL-92 and SQL-99 syntax.

Database specific code can be used, however, to increase performance while maintaining portability by wrapping database specific code in database-detection methods.

Servlet Container Portability

The Concourse Suite application does not require any unique setup at the container level. However, you might install an SSL certificate or make virtual host settings. The application framework is just beginning to be integrated with containers besides Tomcat. The only modification that remains is for the application to retrieve information from a resource, instead of at the file system level.

Java Coding Conventions by Sun/Oracle

Coding conventions allow for greater understanding of code and easier maintenance. The framework code has been developed with Sun Coding Conventions in mind. This means that code is documented and formatted accordingly, usually automatically by the IDE.

http://www.oracle.com/technetwork/java/javase/documentation/codeconvtoc-136057.html

Web browser compatibility

Since Concourse Suite is a web application, we've found it important to be compatible with as many web browsers as possible.

The framework is designed to work with Internet Explorer, Mozilla Firefox, Google Chrome, and Apple Safari to ensure compatibility with a large platform-independent user base. At the browser level, JavaScript is used for validation and dynamic interaction with page elements. Flash and Java Applets are not currently used.

Browser detection at the framework level can be used in both the business logic and the presentation layer to enhance user experience.