ONJava.com -- The Independent Source for Enterprise Java
oreilly.comSafari Books Online.Conferences.

advertisement

AddThis Social Bookmark Button

Building Modular Applications with Seppia

by Lorenzo Puccetti
03/16/2005

Software development has changed. Developers no longer build large systems from scratch, but rather assemble them from existing components. Many products, both open and closed source, are now stable enough to build on top of these components and developers have finally tired of re-inventing the wheel and have begun to work with them. This is very good, as it seems that object-oriented software construction is delivering on one of its best promises: reusability. However, assembling independently developed components is itself a non-trivial task that can lead into complex integration problems, as well as tightly coupled code, if not performed correctly.

What we need now is a tool that blends separately developed components into a well-crafted finished product; a tool that protects major subsystems of the architecture from each other. It should be easy to understand because of what it encourages: rapid development against a very modular environment. It should let you assemble applications from existing components, putting in as little glue as possible. And it should endeavor to simplify the need for highly customizable applications to have tailor-made functionality.

Seppia was designed with those goals in mind.

Introducing Seppia

Seppia is a simple Java technology to build any Java application from constituent parts. Seppia is structured around the concept of a module. A module is a self-contained part of a system. Modules are stored in folders. A hypothetical word processor built in Seppia could contain modules like this:

 |
+ modules
      +-- org.hypotheticalwordproc.spellchecker
      +-- org.hypotheticalwordproc.ui-swing
      +-- org.hypotheticalwordproc.io
      +-- org.hypotheticalwordproc.searchengine
      +-- ...

Under this model, each module is responsible only for providing a specific piece of functionality to the system.

The behavior of each module is split between Java code and JavaScript code. The Java code, stored in .jar files, provides an API for the JavaScript code to work with. The JavaScript code, stored in .js files, defines the services provided by the module.

The spellchecker module could look like this:

 +-- org.hypotheticalwordproc.spellchecker
            +-- jars
            |    +--- jazzy.jar // open source Java API.
            |
            +-- javascripts
            |       +--- WordFinder.js
            |       +--- SentenceAnalyzer.js
            |       +--- ...
            |
            +--- dictionaries
                   +--- english.dic
                   +--- france.dic

In this example, the JavaScripts WordFinder.js and SentenceAnalyzer.js are the entry points of the module.

In this article, we will build a fully functional application using Seppia technology. We will make use of some open source products and show you how to glue them into a finished product.

But before we can do that, we need to take a step back and tell you a bit more about how Seppia works.

Quick Tour Of Seppia

The binary distribution of Seppia consists of the following directory layout:


+--- jars          // contains the jars to bootstrap seppia.
+--- modules       // contains the modules. Initially there
                       is only one module,  "org.Seppia.bootstrap"
+--- StartUp.class // the class to run seppia.

We begin by assuming that we have installed the latest version of Seppia into a folder called c:\myFirstSeppia. (Note: the instructions here assume you are a Windows user. This is mainly a convenience to keep the writing concise. It should be quite easy to adapt the paths in these instructions to other systems.)

To run Seppia, use the command:


c:\myFirstSeppia\> java -cp . StartUp

This produces the output:

Seppia successfully installed at URL file:/C:/myFirstSeppia/ 

The "successfully installed" message comes from the JavaScript StartUp.js in the module org.seppia.bootstrap. Seppia is hardcoded to look for the module org.seppia.bootstrap and execute StartUp.js. This means that StartUp.js is our first place to look. This is its original code:


function main()
{
   java.lang.System.out.println(
      "SEPPIA successfully installed at URL "+module.environment.url);
}

If you fancy editing the file, you can easily transform it into a "Hello World" Swing message:


var JFrame = Packages.javax.swing.JFrame;

function main()
{
    var frame = new JFrame("Hello World");
    frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
    frame.setSize(360,80);
    frame.setVisible(true);
}

When you relaunch Seppia, you will see a window like Figure 1:

Figure 1
Figure 1. "Hello World" in Seppia

Before you go experimenting with your Seppia installation, it is important that we spell out the rules that Seppia sets to ensure a consistent design for any application. Read them carefully, as they should save you time by anticipating most of your likely questions.

  • JavaScripts are stored under the javascripts folder of every module.
  • The first JavaScript to be executed is StartUp.js, in the module org.seppia.bootstrap
  • A JavaScript can invoke another JavaScript using the "native" function run.
    • run(scriptId) runs another JavaScript co-existing in the same module.
    • run(moduleId,scriptId) runs a JavaScript in a different module.
  • The execution of the JavaScript file consists of two phases:
    • Evaluation of the JavaScript as a statement.
    • Execution of the function main().
  • JavaScripts can access the classes stored in .jar files under the jars folder of their module.
  • The following properties are available to the JavaScript:
    • id: The name of the JavaScript
    • code: The code of the JavaScript
    • module: The module on which the JavaScript is run

Pages: 1, 2

Next Pagearrow