HEAD PREVIOUS

Chapter 1
Overview

Welcome! JMatter is a software application framework. It is designed specifically for building business software applications for work groups. Examples might include accounting software, software for legal firms, medical software for small practices, software for auto mechanic shops, software for small software development shops, and more1.
The principal advantage of developing a business software application with JMatter is a dramatic reduction in development time. It is not an exaggeration to say that the difference in development time compared to traditional methods is roughly a factor of 10! That is, one order of magnitude.
Take for example, the Issue Manager demo application described in chapter . Surprisingly, even though this application is presented as a "demo", it nevertheless is a complete and working Issue Management software application that can be used for day-to-day tracking and management of software issues. The authors of the JMatter framework used this application for some time for tracking bugs and enhancements to JMatter.
This Issue Manager software application was implemented by a single developer in roughly four hours. Contrast this to comparable systems such as Bugzilla http://www.bugzilla.org/, JIRA http://jira.atlassian.com/, and trac http://www.edgewall.com/trac which, albeit may have a few more features, have taken somewhere in the neighborhood of one or more man-years to develop.
Equally important is the number of lines of code necessary to implement such a software application. Using JMatter, the entire Issue Manager application consists of 300 lines of code at the moment, including white-space (blank lines), strewn across three Java classes. Compare that to approximately 13,000 lines of python code2 in trac spread among roughly 170 files (I don't mean to pick on trac, which is a very nice issue management application; I just happen to have a copy installed on my computer).
This brings up another point: the JMatter framework is written in the Java programming language. This means that your software applications can run in a heterogeneous IT environment, on a variety of operation systems including the plethora of GNU/Linux OS's, Solaris, MacOSX, and the various flavors of Windows3.
Software development professionals or teams that use the JMatter framework therefore enjoy a significant competitive advantage over other software development firms that employ more traditional methods of developing software.
At this point you should be asking yourself some very important questions: Can this really be? How? Is it really possible to shave 90% or more of an application's code? To deliver software in so much less time?

1.1  How?

Let's take a moment to reflect on how software applications are constructed. The reason for developers' high productivity with JMatter is simple, but needs some elaboration.
All applications have a great deal in common. Examples include, a login dialog, the need for authentication (controlling who can and cannot access the system), etc...
Believe it or not though, most developers build these same features over and over again each time they work on a new application. With JMatter, things are different. JMatter provides those common things so that developers don't have to start from scratch each time. You won't find a single line of authentication code in a software application constructed using JMatter; that's all tucked away in the framework.
If it were all about login dialogs, JMatter wouldn't buy you very much. What sets JMatter apart is the fact that there are plenty more things that developers write from scratch for each new application; things that are common to them all. Here are some of them:
A User Interface
 
A window, the ability to create new users, change their passwords, the ability to create a new contact, edit the address for an existing contact, delete an old contact. The basic need to Create, view (Read), Update, and Delete information is termed CRUD. It's true that for each type of thing you're creating (a User, a Business, a Person, etc..), the forms will vary because each thing contains a different set of fields. However, the mechanism is the same. Developing a user interface from scratch is a very tedious job. Estimates state that approximately 60% of the time spent developing an application is spent constructing its user interface;
Query Services
 
The basic need to filter information. For example, the ability to ask the question: Display all Persons who live in a certain city;
Validation
 
The ability to specify which fields are required, which are optional, what constitutes a valid phone number, date, etc.. when performing form entry tasks;
Persistence
 
The ability to save information, associations between objects, and more;
Calendaring
 
Many varying applications have the basic need to deal with time: scheduling activities, looking up and manipulating events on a calendar, etc..;
Basic knowledge of simple types of information
 
So many business applications need to process dates, phone numbers, social security numbers, images, passwords, percentages, currencies, names, addresses, notes, and more. Yet here again, you will discover software developers spending time [re-]writing code to parse, validate, and format such basic information as a phone number;
Logging
 
Tracking activity in the system, the fact that someone logged in at a specific time, that they deleted an entry, etc..;
Authorization
 
Specifying who is allowed to perform what actions in a system;
Reporting
 
The ability to produce printable (PDF) reports from the information that an application manages;
Wizards
 
A component of user interface construction, often used to break down complex tasks into a series of steps.
Most of this work has nothing to do with the specific problem domain: they're generic services that all applications should have, but that [unfortunately] are constructed from scratch each time4. I like to say that these services are orthogonal to the problem domain.
We can see now why software projects are often delivered late and over budget: developers have a great deal of work to perform when building even the most basic of business applications. Before they have a chance to begin working on the problem domain, they're faced with building an entire software infrastructure. The end-result is often a combination of:
JMatter promises to empower developers to work on the task at hand without having to build a foundation. At the time of this writing, JMatter provides most of the listed orthogonal services. The implementation of a built-in, generic Authorization system has recently been completed.
The predominant architecture for software applications today is known as Model-View-Controller. You can think of JMatter as providing a complete and generic View-Controller implementation, leaving developers to work on the Model.
So to sum things up for now, the JMatter framework's goal is to provide all of these orthogonal services, out of the box, so to speak without requiring any extra effort on the part of the application developer.

1.2  Architecture

Before diving into JMatter, let's briefly discuss what types of applications JMatter produces. What is their architecture? What language are these applications written in? What operating systems can they be deployed onto, etc..
The JMatter framework and JMatter-based applications are written in the Java programming language. The implication is primarily that these applications can run on a number of target operating systems, from windows computers, to macs, to the variety of GNU/Linux operating systems out there, as well as other flavors of Unix such as Solaris and BSD.
JMatter applications by design produce software applications where all data is persisted to a back-end relational database. Databases provide powerful query capabilities that are the foundation for many business needs. The JMatter framework uses the Hibernate 5 framework to communicate to back-end databases. This affords the framework database independence. JMatter applications are compatible with a number of back-end database systems. It has been tested with PostgresQL, MySQL, and Oracle databases, as well as newer and more lightweight database systems such as H2 and hsqldb. These back-end databases are available for a large number of operating systems.
On the client side, JMatter leverages the Java Swing Toolkit to produce rich client applications. These user interfaces are platform-independent.
The overall architecture has two tiers: the client application communicates over the network to the back-end database. Multiple clients are installed on multiple workstations, and multiple users can access the system concurrently.
This type of architecture is suitable for local area network deployment, or the wide area network, over a VPN 6 connection. A number of database systems today can be configured for communications over SSL, making it possible to deploy such solutions over a wide area network without requiring a VPN solution.
To automate the task of installing clients on multiple workstations, and of keeping these installations up to date, JMatter leverages Java WebStart. Chapter 18 is devoted to the specifics of deploying JMatter applications using this technology.
At the time of writing, JMatter already has early (alpha quality) implementations of the infrastructure necessary to deploy the very same applications over the world wide web, using a three-tier architecture. We hope to release a final implementation some time in 2008. This will give users the ability to deploy their applications either to the web or using Swing, or both (a mixed population of users).

1.3  Seeing is believing

Here's what lays ahead in the upcoming chapters: we'll walk through installing JMatter on your system. Then we'll begin by studying one of the JMatter demo applications: the Contact Manager (Chapter 3). By the end of that chapter, you'll have a good feel for JMatter applications, what they look like, how to interact with them.
Part 2 of this manual focuses on teaching you how to write JMatter applications by example. We'll start by building our own contact management software. In each succeeding chapter we'll build a new application, each one building upon the notions learned in the preceding chapters. All of the tutorial applications documented here are included in the JMatter framework distribution.
The third part of this manual aims to provide a complete reference of the JMatter framework. That's where you'll find detailed information on the various features of the framework, options, and conventions to adhere to.
Bold claims have been made in this introduction. Coming from the authors of the JMatter framework, these should be regarded with a healthy dose of skepticism. It is for you, the reader, to judge the cost-benefit proposition of the JMatter framework for delivering software applications. This document arms you with the information necessary to make that judgment.
HEAD NEXT