Introduction

Introduction
Pojo Application Server

There are many reasons for wanting code to be stored centrally, however it certainly is not desirable to have all your code run centrally.

Whether your clients are the employees in a large company, or out there on the web, its nice to be able to go to one local machine, make the changes required, and know that 2000 clients will benefit from those changes the next time they start the application remotely.
As a developer, no longer having to rush up to the 5th floor, or catch a plane to go sort out a problem, is efficient, and centralization of whole applications is certainly an attractive utility.

One doesn't want to lose the processing power of clients because typically in a large organization, the power of client machines is way underutilized, and collectively enormous, whereas servers tend to be bottle necks struggling under heavy load.
Thus even though one may choose to store all the applications centrally, its desirable to have 90 percent of the processing requirements passed out to the clients.

In many ways a POJO application server is not unlike a web site, however instead of delivering hypertext, it delivers java. Harbor is in fact a very special web application.

When passing out processing work to clients, one does not write heavy clients and light server applications (the client against bean model).
Its much simpler than that, one writes a single coherent POJO application, its tested outside the server, and then when dropped into the server, it will Coherently Disintegrate.
The developer tells the server what part of the application (which classes) must run on the client box and what part of the application (which classes) must run at the server.

The transport protocol used in Harbor is binary based, and there is no translation to a text based standard, such as xml, this makes it very light and very fast.
The protocol runs on HTTP, and this allows one to treat the application server, as they would a web site. For example one does not need special proxies, or have to open up an additional firewall port, if a web server works, Harbor works.

Its clear that this technology has to be able to do Remote Procedure Calls, but still something more is needed, namely the ability to split an application into separate operational, but still coherent parts.
In other words, one can take a plain old java application, make some of its classes run in Tokyo, and some of its classes run in New York, and the application itself, has no idea that its actually disconnected and running on different machines, it still thinks its a nice cozy bundle of java goodies.

Coherent Disintegration

This is the core idea behind a POJO container.
Essentially its a design pattern, and it means that one abandons the idea of remote client software talking to server software, in favor of placing a full coherent application on the server, and then simply telling it, that some of it must run on the client, and some of it must run at the server.

Harbor lets you build a full coherent application, and does the rest for you. Not only does the whole idea of EJB's evaporate, concepts like Inversion of Control fly out the window, they are redundant in a POJO container, just as they are in POJO, or to be more accurate, they are used in POJO, but are very easy design patterns in that environment.

The simplicity of design translates to enormous power. Whether its a game, a vehicle tracking system, a specialized server, a bank payment system, your POJO server will run it.

Because Harbor brings POJO to the application server, things become very easy, however make sure you have read the documentation and have a good look at the demo code, not because its difficult, but because its so deceptively easy, you may completely overlook and forget that there is something very special indeed going on.

What It Does

Feel free to drop us an email anytime...
and help make this the best application server, ever.