HARBOR

INDEX

POJO Application Server

WIRE BOX

The sculpture of a Harbor application.

A Harbor Java application is a stock standard application, with a Wiring Box, called the CD_Unit.
This is a visual tutorial on the idea of Coherent Diffusion (or the MVC model).

What we going to do here, is create a standard visual representation of a "normal" java application, and then show you how that changes when one applies a Wiring Box (CD_Unit) to it. 
The reason we need a Wiring Box is so that Harbor can get at the wires and stretch them across a network.
Once you understand this conceptual view, look at something like the mailer example, and you'll see what the code looks like in practice.

	This represents a normal class.
	This represents a class that is accessed through an interface.
	Shows Class A calling Class B. ie inside Class A ClassB classB = new ClassB();
	Shows Class A calling Class B through interface ie inside Class A I_ClassB i_classB = new ClassB(); where I_ClassB is the interface to ClassB

Lets now build a typical simple application.

There is a UI class and this uses a FACTory class.
The UI class also uses a little Helper UI class.
The FACTory class also uses a Helper FACT class.

Imagine that we want the UI to run on a remote machine, and the FACT to run on the server.
Lets introduce a wiring box...

Notice that the UI and FACT classes have been given Interfaces, also notice that there are now no direct connections between the UI and FACT. 
The wires to the two halves of this program now go through the CD_Unit or Wiring Box.

In the 'typical' application the UI class instantiated and called the Factory class directly. 
The Wiring Box now does that, and the code inside that wiring box would look something like this...

I_Fact i_Fact = new Fact();

I_UI i_ui = new UI();
i_ui.setFactory(i_Fact );

Notice that all the control is now done in the Wiring Box, each class is instantiated, and the CD_Unit gives the factory class to the UI.
This is why they are called controller classes in the MVC model.

One might be tempted to ignore this model and just apply the RMI (Harbors API) directly to the UI. 
In something as simple as the 'typical' model, it could work, however its a bad idea. 
Just for the purposes of example, lets introduce another UI class (UI Extra) to this model.

Where would you do the manual RMI (wiring calls) now? If we build a wiring box into one of the operating UI components, which also controls other components, it immediately starts becoming complex. 
Because in Harbor all the components move or operate on the wire, mixing control with component is not a good idea.

That's almost it... except for one other reoccurring important design pattern. 
Because the wiring box gets to see all the components (imagine another 5 factories for example), it becomes much easier to pass the entire Wiring Box into UI's that use it, instead of every component.
So it looks like this...

The code in the wiring box or CD Unit takes this form...

I_Fact i_Fact = new Fact();

I_UI i_ui = new UI();
i_ui.setFactory(this);

Now that UI, because it has a callback reference to the CD_Unit, can get at any factory method, in any factory.
It means we can expose methods directly in the CD_Unit and this also makes error checking easy when we make the Ship.

When you make your SHIP... you will now find its almost identical to this Wiring Box.

This is because the Wiring Box has a ONE to ONE relationship with the required RMI calls.

That's really all there is to it.
This is what people mean, when they say... "apply MVC to the application", or "make a Wiring Box", or "make a CD_UNIT".

The great thing about this, is that its what terrific programmers do anyway.

Good programmers naturally separate VIEW and MODEL, and the leverage of the MVC model is amplified in Harbor.

For example if you made a new application which is almost identical to the old application, except for say one new UI component, and one new FACTory object. That's all you literally have to make in the new application, because the CD Unit in the new application can continue to use all the components that are still OK in the old application.

Applying Coherent Diffusion may seem like a little extra work, but after several applications, one needs to write very little code to get something done. One simply plugs into utilities and modules in other applications.

In some ways, Harbor is not new technology at all, its really just allowing us to apply old tried and trusted techniques to networked applications.
We can now build applications for a network, the way they were meant to be built, everywhere.

The incredible power of Harbor comes from being able to use Java, as it should be used.

==============================