Architectural Concepts Explained

In This Topic

MVC

MVC is an abbreviation for Model-View-Control and is a design pattern used extensively in XperienCentral which uses the Spring MVC framework which is based on this pattern. This pattern separates software components into three responsibilities: the data model, the view (user interface), and the controller that handles the interaction between these two. The MVC model can be depicted as follows:

The MVC design pattern helps to decouple the graphical user interface from the application logic.

Back to Top

Spring MVC

Spring MVC is a web application framework used by XperienCentral to render the Workspace. It is designed around a generic Spring Servlet (the DispatcherServlet) that dispatches requests to controllers based on URL mappings defined in an XML configuration file (springmvc-servlet.xml). Using the Spring MVC framework has the following important advantages in the case of XperienCentral:

• Spring MVC provides an API to easily apply the MVC design pattern. Models, views and controllers are identified in the API and Spring MVC provides default implementations for them.
• Spring handles the automatic binding of posted values in HTML forms onto a Java object called the Form Backing Object (FBO). This increases ease of development because developers do not have to parse HTTP requests themselves.
• Spring MVC provides default property editors (used for converting Strings to complex Java objects) and provides an easy way to create custom property editors. Property editors make it easy to transform a string (received, for example, from a posted HTML form field) into a complex Java object.

Spring MVC, however, does not provide a way to deal with a component-based application like XperienCentral. For this reason an additional XperienCentral-specific web layer has been built on top of Spring MVC in order to address this. This API is the same as the Spring API itself. which means that while developing in XperienCentral you do not actually see any difference.

Back to Top

Business/Domain Object

A business object, or domain object, is an object that is modeled after a business concept. Business Objects within a system are typically stateful, persistent and long-lived. Business Objects contain business data and models the business behavior. Examples of business objects are authors, persons, books and cars.

Back to Top

Form Backing Object

A common misconception is that the form backing object and business object are one and the same. While a business object’s target is a business concept, a form backing object’s target is a particular view (not necessarily presenting business object properties). A form backing object is typically not persistent, is short-lived and is only used as data transfer object between HTML and zero or more Java business objects.

Back to Top

Controller

A controller is the glue between the model and the view. The view and the model (usually containing at least the form backing object) are both created by the controller. It is the controller that determines whether values posted by an HTML form should be submitted and if one or more business objects should be updated. It is the controller which handles the data transfer between the business object and Form backing object. It is the controller which receives HTTP requests and creates the HTTP responses.

Back to Top

Abstraction Layers

Separating the application into several abstraction layers is a good design principle which prevents tight coupling of the software. Loose coupling of the software, made possible by introducing abstraction layers, makes the software very flexible, pluggable and extendible which is very important for a component-based application like XperienCentral. For this reason XperienCentral identifies five different abstraction layers as depicted in the figure below:

User Interface Layer

The user interface layer contains the software components that handle the rendering of the user interface for the end user. Such a component is called a view. A view can generate XML and/or PDF but mostly it generates HTML. The source of the view can be defined in many formats, but in most cases the language used will be JSP, which makes it a JSTL view.

With an edit view in the picture above we refer to a view that is used to render a software component (like an element or panel) in the Workspace. With a website view we refer to a view that renders the software component on the website environment.

When using the Spring MVC web application framework, views are agnostic, which means that they are not bound to a specific source or output format like HTML or JSP but can use any source and any output format. However, views usually use JSP as the source format and provide HTML as the output.

Web Layer

The web layer is responsible for all communication between the model and the view. It retrieves the HTTP requests, generates the view and returns the result. The controller uses a data transfer object called the FormBackingObject to hold the data that must be rendered by the view or to hold data submitted by an end-user using an HTML form. The controller handles the transfer of property values between the FormBackingObject and the business objects it represents. The FormBackingObject is closely related to one or more business objects in the domain model layer but they are not necessarily the same. For the Workspace, the controller will be a Spring MVC controller; for the Website environment this is the ControllerServlet.

The controller is responsible for handling all requests and returning the correct results. The web layer typically has dependencies with all other layers.

Services Layer

The services layer exposes several services to software components such as authorization, configuration, preferences, session management and transaction management. Services provide business logic that provides multiple business objects. Business objects themselves usually only contain logic for updating and retrieving its own properties.

Persistence layer

The persistence layer is responsible for persisting the business objects invoked by the controller. It is good practice to define a DAO in order to prevent the business object from containing dependencies on a particular persistence implementation like the JCR or JDBC calls.

Domain model layer

The domain model layer contains all business logic (business objects and business rules). The domain model objects are implemented as POJOs and do not contain references to any of the other layers. However, the other layers may refer to objects in the domain model layer. The business objects usually contain only business logic that updates and retrieves their own properties. When business logic involves multiple business objects, it is recommended that you use a service instead.

Back to Top

OSGi

The OSGi Service Platform specification is an open services standard that defines a standardized, component-oriented computing environment for networked services. Adopting OSGi has several advantages:

• OSGi addresses all major concerns with regard to implementing a service container. Service registry, location, and management are all well defined.
• OSGi supports hot deployment of bundles (services and components) and addresses the specific classloader issues.
• OSGi is an open standard, has open source implementations, and a lot of commercial backing.

Services in an OSGi service platform are implemented and deployed as bundles. A bundle is actually just a JAR file containing specific manifest entries.

Back to Top

Service Framework

The XperienCentral service framework is the central part of the XperienCentral architecture. It allows XperienCentral to be modular by physically separating logical components into services with well defined interfaces. Because the service framework follows the service container paradigm, it provides the execution environment and the mechanisms for dynamically locating, accessing and managing services.

Back to Top

Plugins

A plugin is a wrapper around an OSGi bundle with XperienCentral-specific enhancements. A plugin is an OSGi bundle that publishes one or more components. Such a component may be an element, panel, media item, service, task or a form. A component is not a concept that is defined by OSGi but is rather XperienCentral-specific. For this reason you cannot, for example, start or stop individual components but only the bundle as a whole.

Back to Top

Component definitions

A component definition defines the basic behavior of the component, most importantly its type. The supported component types are:

Back to Top

Inversion of Control (IoC)

Inversion of control is a pattern that allows an object to become a passive participant in the system. When the IoC technique is used, an object relinquishes control over some feature or aspect to the framework or environment.

Back to Top

Dependency Injection

Dependency injection is a specific type of IoC. Using this technique an object on which a service object depends is injected by the framework into that service object. This can be done using the setter or constructor technique (other techniques can also be used).

Dependency injection is heavily used when defining service dependencies. When a component defines a service dependency, a reference to that service is injected by the framework into that component instead of the component itself retrieving the reference.

Back to Top