Library of Components

The Expresso Library helps you to rapidly develop web based applications. Portability, scalability, stability and flexibility are the most important factors in this business: therefore the framework is based on Java Servlet technology.

Expresso provides a library of extensible components for providing services to web-based client applications. Building on Sun's standard API's it provides facilities for web applications using servlets including components for: security, access to databases, email connectivity, job control, health check, logging, event notification, database objects, download, configuration values, and access to other server-side components, etc. Expresso provides a toolkit so the developer can concentrate on application logic. It's complements EJB technology letting you write the server-side logic quickly and easily.

Expresso is a next-generation tool for developing and deploying dynamic applications which resemble current desktop applications much more than they resemble Internet technology.  The deployment infrastructure is highly scalable, robust and secure. 

Build Sophisticated Web Applications Quickly

Expresso provides components which make it very easy to quickly build sophisticated web applications. Rather than simple servlets that merely enable access to a database, the Expresso Framework allows you to build entire systems, with secure, high-performance database access via an object-to-relational mapping (no need to embed SQL in your code), background job queuing and handling with dynamic invocation of custom server-side objects, and sophisticated event notifications and logging to facilitate management of your completed application.

Using the Expresso framework, developers focus on creating the business logic and layout of the UI.  All the tedious infrastructure work is already there to build upon, so that creating applications is easy and fast.  

Expresso works with JSP, which allows people to build their own custom interfaces to our servlets if they wish.

Building on Sun's APIs

Expresso Framework is a super-servlet run-time environment of common services (session, monitoring, database connectivity) for supporting N-tier applications.

Expresso provides facilities that most people who write an extensive web application using servlets usually have to write for themselves: security, access to databases, email connectivity, logging, access to other server-side components, etc. The standard API's from Sun give the raw capabilities for all of this, but most servlet authors have to still "invent" the specific implementations themselves. Expresso provides the developer community a toolkit that has those services (and a few more) already written, so developers can concentrate on the business issue being addressed by the application. 

Infrastructure Layers 

This diagram shows the relationship between the database layer, application framework and package layer.  The list of packages are applications or component tools which we are developing.  

Content Topics Library Components Build Apps Quickly Building on Sun API Layers Components Administrative Functions Extensible Framework Benefits  Framework Use Job Queuing Scheduling Jobs

Expresso Components  Security Job Control DB Connection Pooling Health Check Logging Event Notification Database Objects Configuration Values

Building on the Java Servlet API, Expresso provides an extensible framework for providing services to client applications in any servlet-based web environment.

Components of Expresso

The Expresso Framework is a specialized process that runs in the same java virtual machine that servlets use on the server side. Its job is to check the job queue in the database for new jobs, and to handle the requests for jobs appropriately. The application framework checks the queue at intervals defined in setup (typically every few seconds), and launches the appropriate objects to handle requests based on information contained in the request. The object that is launched then handles the request. The object launched is either started as a separate thread (if it is designated as multi-threaded), or held until all multi-threaded jobs are complete & run separately (if single-threaded). Jobs that require no other job to be in process when they run should be single-threaded.

Jcorporate has a few other small projects which are currently bundled with the Expresso Framework and include:

Administrative Functions

All Expresso application framework functions can be controlled via html screens via the browser, without any need for access to the server itself (security permitting, of course).

Design of the Expresso framework includes the following features:

• Extensible Framework
• Event-Driven Processing

An Extensible Framework

In addition to it's built-in services, the Expresso application framework product is designed to easily accept new service functions added by your organization. The application framework , and incorporated into it’s framework seamlessly. The output or status of the task can then be used to generate events, queue other jobs, run reports, and many other functions.

For example, when used with Jcorporate’s Data Warehousing Toolkit, data transfer/aggregate services can be used to periodically transfer & consolidate data from any number of different sources into one or more data warehouse servers. Detail can be consolidated according to any criteria by inclusion of custom SQL statements, and denormalization can be done at the time of transfer as required. Transfer and load status can be automatically e-mailed to a specified user.

How the Application Framework is Used

Let's consider a simple use of the application framework to build the basics of an accounts receivable system. Although it is common to build such a system to "web-enable" an existing legacy application by "wrapping" the legacy application as objects, let's assume for this example that the application is a new, standalone package.

Here are the steps we'd use to build such a system:

1. We create a new package to hold the classes for our receivable system. Let's say it's "com.abcco.ar".
2. Create a schema object that describes the database objects (tables) required to store the data. This would include a customer object, an invoice object, and a payment object (again, we're keeping this very simple!). We also define a number of configuration values, such as the default terms (30 days, for example), and the aging periods we wish to handle (say 30, 60, 90 and over 90 days). Also in the schema we list the standard reports this system can produce: A customer list, an invoice list, and an aging list.
3. We create the database objects described in the schema. No need to physically create the database tables - the system will do that for us when the package is initialized. Each object is an ancestor of the "SecuredDBObject" class, and thus has automatic security built in to it. These object get created in the com.abcco.ar.dbobj package.
4. We create the reports listed in the schema in  the com.abcco.ar.report package. These reports are ancestors of the HTML object "ReportPage". No HTML code need be embedded, as a full templating system allows HTML reports to be build with a few method calls.
5. We insert an entry in the "SchemaList" table to point to the schema object we created in step 2. This tells the application framework everything it needs to know about the application.
6. We create some web pages to give access to the AR system, using references to the DBMaintAuto servlet to provide automatic data entry/maintenance facilities. For example, to create a link that provides data entry/maintenance to the customer table, we would make a link like this: "/servlets/DBMaintAuto?com.abcco.ar.dbobj.Customer". The object would automatically provide the DBMaintAuto servlet with all the information it needs to provide list, search (with wildcards, ranges), update and delete facilities to the users of the system (via appropriate security).
7. We run the application framework's "Initialize" servlet - the framework reads the schema object we've registered, creates the database tables, creates the report registration entries, and builds default security (allowing the system admin to get access to the newly created database objects).

The system is ready for use! Obviously, this is a very simplistic accounts receivable (AR) system, and would need further facilities - but the system described above can be build in less than a DAY, and be fully developed in less time than you might believe.

Integrating Job Queuing Facilities

We might wish to extend our AR system with a process to perform "aging", that is, the calculation of what our company is owed in each of the aging terms of 30, 60, 90 and over 90 days. If this is a long process we might want to have it run in "background" e.g. have the user request it to run & then allow the user to go on with other tasks, rather than waiting while the process completes. This is a perfect example where the job queuing facilities of the Expresso Framework can be used. Here are the steps:

1. Create the server-side object that actually does the calculations. This object is an ancestor of an object called "TimerService". It implements a "run" method (like a thread) that actually performs the processing required.
2. Create a servlet that provides the user a place to request the aging process - let's say that this would be a form that requests a date - the aging date - which is passed as a parameter to the server-side object we created in step 1. The servlet queues the job by creating a JobQueue entry & storing it. In this case we also create a JobQueueParam entry to pass the aging date to the background job. Once the job is queued the servlet simply returns to the user a message indicating this & the user goes on to other tasks.
3. Now the user can run the process by filling in an aging date & submitting the form - the application framework picks the job up from the queue and instantiates the server-side object we created in step 1. It hands the object the parameters from the queue and a database connection & calls it's run method.  The server-side object indicates if it is single-threaded (e.g. must not be run in parallel with other jobs) or multi-threaded (can be run at the same time as other jobs). When the job is complete, the application framework triggers an event (defined by the server-side object). This event e-mails the user (and any other users who are registered to be notified of the event) that the job is complete.

At any time during processing the user can view the status of the job, either real-time or via it's log entries, and the system administrator can stop, start, or reschedule the job among other jobs in the prioritized job queue.

Scheduling Jobs

Jobs can also be launched on a scheduled basis (e.g. once a night, every Saturday at 5, etc.) by using the operating system's job scheduler (for example, CRON on Unix, AS/400 scheduler on the IBM AS/400, NT Scheduler on Windows NT) to launch a process that queues a job just as if the user requested it.  These scheduled jobs can run reports, do processing, or any other task that is built into our server-side object. They send events and log their process just like all jobs handled by the system do.