ConcourseConnect is developed using Java Servlet, JSP and Portlet technologies. At the heart of the application is a light-weight MVC framework built from the ground-up to support very high functionality while minimizing the required skill-set to extend the functionality.

Key Components

MVC Web Application

At the heart of ConcourseConnect is a light-weight web-tier for facilitating requests from a client, whether the request is from a web browser or an application using the API.

A Model-View-Controller Framework allows a developer to separate the business logic and the client view while maintaining order between the two. This separation has the added benefit of making sure that the business logic is securely generated while the client view allows a web designer to make use of the model generated by the java developer.

Benefits include:

• Theming -- the look and feel of the application is easily possible because the application logic is not modified. ConcourseConnect provides a themes directory for additional themes.
• Internationalization of dates, times, currency and languages.
• Auto-population of forms allow the developer to work diligently and concisely.
• Security hooks so that each request is inspected before executing code.
• URL Customization so that the URLs are simple to read by humans.
• and more.

Embedded Portal

The ConcourseConnect web pages are constructed by arranging and choosing from over sixty (60) different "portlets." A portlet is really just a small web application embedded in the web page working with other portlets. Portlets contain HTML content and the capability to process HTML forms and such. The embedded portlets are tightly integrated and have access to the ConcourseConnect database, user information, and more.

So while ConcourseConnect is distributed with those sixty (60) core portlets, there are additional portlets that are remotely accessed and included. The technology is called Web Services for Remote Portlets (WSRP) and is used by ConcourseConnect for standardizing portlet interactions between ConcourseConnect and the Concursive Services server. SSL is used for communication. As part of the WSRP specification, each ConcourseConnect has a unique identity for obtaining entitled services.

The remote portlets do not have access to the local database or any local resources. They are explicitly sandboxed and are treated very much like web services in which a request is made and a response is sent back. So that a portlet can fulfill a request, the protocol sends an account id for authentication, as well as any text-based preferences that the remote portlet requires, which can include the name or contact information of a listing. The preferences are stored in the client so it's easy to poke around and see what the actual data is being sent.

The immediate benefit is that the services can be remotely updated without each ConcourseConnect being updated individually. So far the only services deployed are ads, weather, and web-activated telephony. If you or others are interested in developing and monetizing services please contact us. It's possible that installations can have their own WSRP server, and you should also contact us.

Distributed Cache

ConcourseConnect achieves great web performance by caching information between user requests and across users. The most frequently used, and the most frequently expected-to-be-used content is cached.

When the underlying data changes, so does the cache. Data in the cache ranges from complete portlets to specific records. ConcourseConnect distributes changes very quickly by invalidating cache objects and having web servers in the cluster update objects on-demand.

The result is a dynamic web experience that feels like each page is fully static content.

Message Queue

The message queue allows for lots of background tasks to keep the site running without overloading the server. This approach coordinates indexing, email, integration and more.

Workflow Engine

The embedded rules engine allows ConcourseConnect to asynchronously execute components based on events created by a user. All user activity, including viewing, creating, modifying and deleting information, triggers the workflow engine.

The workflow engine is configured and customized externally from the application through an XML configuration file. The XML defines which objects trigger which processes. When an event trigger occurs, the underlying process begins.

The process is made up of action and conditional components. Action components perform an action, like sending email, or communicating with other systems, while conditional components evaluate the state of the object. When a component is executed, the result determines which component to execute next.

Here's an example of a workflow process that occurs when a user creates an issue in the application:

Here's a link to the example workflow.xml file.

The rules engine is lightweight and can be used to communicate with much larger and robust business process management systems if needed. Components implement the ComponentInterface and can be added by adding a .jar to the application classpath.

Task Scheduler

There are times during the lifecycle of a web application when background and scheduled jobs are preferred. Think of these as tasks that execute at the server without the user having to wait for the operation to complete. One such task is to generate thumbnail images whenever a user uploads a photo. Having multiple images, each sized for a specific use in the web application, cuts down on the size of the images being downloaded.

Some uses of the scheduler:

• cleaning up temporary files on the server
• calculating and ranking user contributions to the site
• sending daily/weekly/monthly email digests of the site's activity

The scheduler can be extended by a developer by supplying an XML definition of the schedule and the code to be executed.

Each task has a name, description and Java Class. The trigger can be a cron expression or simply a start-time and repeat-interval.

Document Indexer

Indexing gives ConcourseConnect the power to find data quickly by relevance, popularity, chronologically or by geolocation.

The title "Document Indexer" is a bit misleading because all objects in ConcourseConnect are considered documents... from Profiles, to Wikis, to Blogs, to actual Document files. Some of this information is indexed in a live real-time in-memory index while larger documents are stored and quickly accessed from a disk index.

Indexing occurs very quickly and in real-time.