etendi BRIDGE

Business Summary of the Solution:

etendi BRIDGE, an easy-to-use, interactive, safe and secure web-based meeting place that bridges the gap when parents and kids can’t be together. Developed specifically for non-custodial divorced parents or co-parenting situations, grandparents, military families, or the heavy business traveler, etendi BRIDGE allows family members to stay connected by providing a single place for them to be together online. Features include live video phone calling, shared spaces for photos, videos and documents, personal notes, an interactive white board, and a shared calendar. etendi BRIDGE leapfrogs existing web-based messaging or video communication tools by providing in one web location everything needed to create a true virtual meeting place. Parents, kids and other family members can be online at the same time and have a video phone call, play games or work on homework together. When they can’t be together online, they can create and leave text or video “Thinking of You” messages and use shared web spaces to build custom web pages, photo albums, explore common interests, plan events and build shared memories.

Technical Summary:

The application is an RIA’s implemented using Flex 3 for the client communicating with a server based on Spring Framework and backed by MySQL or PostgreSQL. SOAP is used as the primary communication protocol, however, the implementation of the server and client lends to easily replacing SOAP another layer (e.g. BlazeDS).

Architecture Details:

Server Application Architecture

The server portion of the framework is comprised on the following high level components:

• Java 6
• MySQL (or PostgreSQL)
• Hibernate
• Spring Framework (including Spring Security)
• CXF SOAP (formerly XFire)
• Red5 (optional add-on for media)
• BlazeDS (AMF communications)

Spring. The Spring Framework provides an alternative to conventional J2EE server side programming. Spring is built upon the paradigm known as Inversion of Control (IOC). In a nutshell, the primary different between a Spring managed resource and a J2EE resource is that instead of a section of code in a class asking for a resource via JNDI (as in classic J2EE), the Spring resource has a bean setter for an interface matching the type of resource needed and then Spring takes care of “injecting” that resource into the class instance before it’s ever needed. The advantage is that the code requiring a resource can be decoupled from the mechanism for actually acquiring that resource.

Spring configuration deals with Javabeans as it’s fundamental object. In a Spring configuration one defines a series of beans representing resources or beans which do work using the resources. Once beans are defined they are woven together using dependency injection.

Spring also heavily utilizes interfaces in class signatures. This is advantageous so that concrete implementations of an interface can be swapped out without the class where the resource is used being affected. An example would be the database access object (DAO). A DAO implementation provides implementations for methods to access the data while hiding the details of how that data is acquired. So, in one instance the DAO could be an implementation of Hibernate and in another JDO. So long as the implementations adhere to the interface they should be swappable.

Spring out of the box has a component known as core. The core component provides the basic IoC functionality and basic framework for a bare bones Spring instance. There are numerous other modules: MVC, Security, Test, JDBC, etc. Each module can be added to the classpath and configuration as additional functionality is needed. The Spring MVC module provides form based functionality for conventional web pages.

MVC. The Spring MVC framework is used to implement login, password reset and sign up.

Security. Application security is handled via the Spring Security module. Spring Security is very configurable and provides role-based security. Roles are used to define various security rules dictating which role has access to a given resource. Resources can be as high level as a URL (in the case of a servlet) or as granular as a method call (from a SOAP interface or other managed service in Spring). Aspect Oriented programming is heavily used in Spring to provide declarative security.

When a user first visits the site, served by the Spring MVC Framework, an HTTP session is bound. By default a session can be given a default role, ROLE_ANONYMOUS. If a user logs in various other roles can be bound to that session. Spring Security handles redirecting a user to a login page if the resource requested cannot be satisfied for that session’s role.

Hibernate. Hibernate maps the server side business objects (POJO’s) to database tables. The Hibernate implementation classes implement a generic DAO interface which defines a series of methods which provide access to the underlying POJO’s. The Spring JDBC module is defined for a particular database and then injected into the Hibernate service. The Hibernate layer creates a series of mappings between a Java class (POJO) and a database table. The particular database is abstracted by the Hibernate layer. If database specific features are used sparingly it is quite possible to swap out one database for another.

Hibernate has many advanced features such as caching, code based queries and fine grain control over writing custom queries if needed.

SOAP. The SOAP interface is implemented using the CXF framework. CXF is powerful and flexible. One can design code first interfaces (SOAP interfaces generated from existing code) or schema-based interfaces (the SOAP interface is first designed via a WSDL and then implemented). Each has it’s trade offs. Code based schemas are easier to develop and provide quicker development cycles. Code based schemas are probably more appropriate when the client and the server can both be modified, such is the case with etendi. For services accessed by third party clients, the schema based interface seems to be more rigorous and less prone to errors from code based changes.

AMF. BlazeDS provides a very similar means for creating an RPC interface as SOAP. The primary different is that BlazeDS is based on Actionscript Message Format (AMF) and is primarily only available to Flash clents (however some Java and PHP implementations do exist). BlazeDS is still relatively immature in comparison to CXF and does not have the same level of customizability.

BlazeDS also provides a messaging framework. If real time messaging is needed without media streaming capabilities then BlazeDS provides a decent alternative to Red5. Red5 seems to have more maturity at this point.

Client Application Architecture

The client application is a Rich Internet Application written in Flex 3. Flex 3 is an application programming framework for creating Flash-based applications. Flex provides a rich set of GUI components and communications API’s.

The client application communicates with the server via three primary mechanisms: RTMP, HTTP-based (SOAP, Rest, etc) or AMF (BlazeDS) requests. The implementation of the data layer is abstracted such that the client code is not dependent on the underlying implementation details, much like the DAO pattern used on the server. Using this scheme an AMF based data access layer can be swapped out for a SOAP based one or vice versa.

All requests from the browser or client application are subject to the security rules implemented on the server (Spring Security). Authentication can be implemented in several ways. Some applications may require broad security restrictions requiring a user to authenticate prior to loading the client application. Others maybe implement finer grain security rules so that the client application can load via an unauthenticated session, but is subsequently required to provide a means to authenticate the user before any data calls are made to the data services (SOAP, AMF, RTMP, etc). Finally, any combination of the two can be employed as needed.

Flex applications are event-based. Virtually all operations in a Flash application are asynchronous. Event driven development lends itself well to creating non-blocking user interfaces which can fetch data in the background while the GUI remains responsive.

The client application is broken out much like a server-side application utilizing the MVC pattern. The data layer is built upon an API which the controller code uses to acquire data. A model of the server-side data is maintained in the client. The model is updated via calls through the data access layer. The view layer utilizes the model to bind data to GUI controls and provide a means for the user to interact with the data.