Index News FAQ TUTORIALS Contact Mailing List Partners DeskTop

Old Versus New
Pojo Application Server

100 percent free

IOC

IOC, or inversion of control, is actually a very generic term that encompasses other principles like Observer Patterns and Dependency Injection, and probably Coherent Disintegration as well, however IOC has really come to mean, the way IOC application containers do their thing.
Its actually an extremely obscure concept, a little like calling your car, a propelled device, and then trying to define the precise meaning of propelled, in the end one simply associates propelled with that device, and whatever meaning it had before that, is gone.

So lets start at the beginning, and lets try keep the concepts simple without getting too caught up on buzz words. Essentially all these concepts describe the very simple idea of injecting one object into another.

So yes, you have done it before, and in theory after writing code like that shown above, you could call your application, an IOC injected Observer pattern thingy. 
In POJO development we rarely stop to think about it like that, we simply passing one object into another, and its so easy, the exact design pattern normally goes unnoticed.

Now move to an application server and that becomes front page news.
In a typical IOC application container, the code actually looks quite alien, and it gets a lot of help from xml configuration and or annotations. 
It's full of helper glue, and its this glue that is doing the injection for you. An IOC application container typically has a built-in injection factory that parses the xml, or interprets the annotation, and then via introspection injects one object into another.

Compared to the simplicity of a few lines of code in POJO, this stuff looks like Martian soup, and one starts to wonder just why they so different? Why is late binding through complex text configuration such a big deal, why is it even needed?

It clearly has something to do with the idea of only using beans, it seems clear that the design intension from the start is that the developer will only create part of the application. One could argue that yes, the idea is to supply all the building blocks in the container and provide the programmer with wonderful tools, but one could also argue that its entrapment, and why cant the tools be supplied as normal java classes, just as its done in POJO.
EJB is a common spec divided by implementation, one can forget about moving their code from one container to another, they all seem to IOC differently.

Much of it also has to do with it being container centric, not only is the application one writes, just a fragment in the container, the client user interface side is considered very much a separate entity, they live outside the container. The intention was never for the developer to make a whole full coherent application, just to develop part of an incomplete system.

Its not really surprising that beans in these application servers always seem to be lonely little entities, IOC as its applied to these containers is really the only life line, or contact these isolated little beans have with the outside world, how else could it work? 
They have no dedicated UI, they don't act as the core controller, they are controlled, and really the name is wrong, these things are IOC micro applet containers, where is the application?

The impetus for Harbor comes from wanting to make it easier, the motivation is to get back to the language we very fond of, pure Java, and the ideal is to make it more intuitive.

This account is a personal view, and one shouldn't take it too objectively, you are encouraged to do your own research, read the specs, try an IOC container, and then formulate your own opinion, if you then also think that the effort doesn't justify the reward and the complexity borders on pain... come back and give the POJO container a try.
 

Coherent Disintegration
also called
Coherent Diffusion
Copyright (c) 2007 Kewl Stuff Technology,  All rights reserved.

When we started to get libraries running in Harbor, and using the client side to control them, the thinking was very much that what was making injection now simple and easy, was because the UI client side code could now do that injection. 
The thinking was that what makes injection easy in a POJO application is that the client side is quite capable of injecting the required service objects into the required factory objects. 
In other words, when a user say uses an accounting package and clicks on Bank A, the client application then simply injects that Bank A object into the accounting factory object. 
Remember that here we talking about a client application running remotely, so when a client injects one object into another on the server, and in so doing gets rid of any forced requirement for "IOC" on that server, it already felt like reason to celebrate, and it already behaved as POJO.

The thinking was still conventional, namely that the UI client side, now virtually connected to its body on the server, could do what a POJO application does, but it still felt like one needed to develop two applications, the client side, and the server side. 
The thought was then, well lets deliver the client in almost the same way as a web server delivers a web page, that is, first the "browser" sucks up the "client", and then the client talks to the server, almost analogous to the Ajax idea.

Then an accidental thing happened, we started putting the client side code into the Harbor, and it started feeling like a full POJO application, so we decided to scrap the 2 halves and make one full application, and to get this to work, we made another tiny little client, that first loads up the UI side, and then that UI side chats away to the server's classes.

So just to recap, we started off focused very much on scrapping the bean idea, and making any application run on the server, and to get rid of annotations and or the xml normally needed for "IOC" injection on the server, we made it so that classes working on the client side could manipulate classes in the server with the emphasis being on making that also feel like pure POJO. In other words, to us, it feels like we just injecting one object into another on the client, but in actual fact, the real classes are mimicking those actions on the server. 
We thought that was pretty neat, then almost by accident, we discovered that one could simply drop the entire application into the Harbor, and then using another special little client, launch the UI side on the client, and let that chat away and manipulate server objects.
Not only did we get rid of "IOC", and bring POJO back, we discovered we can take a full working application that runs outside the Harbor, and simply use that.

Naturally with a full application just sitting there in a server, something needs to get it going, something needs to get the thing to load up and start. 

The real question is, what is that another special little client that we been talking about. 
Well besides being tiny, one can almost think of it as a little bootstrap program, and besides it being the only piece of code that need carry Harbor specific API's (note that its outside the full application, so it does not break your pure POJO), we noticed something else, in a well designed application, it always mimics a tiny part of the real applications code.

Its the MVC model at work. 
Its this concept that simplifies the whole process of putting an application on the wire. Although absolutely simple once one gets the idea, the resulting power and scope of this concept is ground breaking. 
Once you have read this section if you then look at the Tutorials, you'll see this powerful simple concept in practice. 
Give yourself a little time to click, once you do, the way you view an application server will change forever.

So not only do you get POJO, and not only are you able to develop outside the container, and dump the entire working application into the container, as a coherent whole, if you apply good coding practice to your application, the "client" that one gives out to bootstrap the process, is NOT the VIEW side, its the CONTROLLER.

We needed a name for this, and called it the Coherent Disintegration or the CD unit. 
If some software or someone needs to control an application in the Harbor, all they need is the CD unit.
If you place that on a web site, and its downloaded and started, the UI will magically appear on the clients machine, and that will chat away happily to the server side software.
 
If you haven't heard of these buzz-words, don't worry, the simple concept follows below...

Harbor has 2 main API calls that you need to understand, getRemoteClass which makes a class run on the client side, and loadRemoteClassInst which makes a class run on the server side, however its manipulated on the client side. Before we discuss Coherent Disintegration further, some insight into these 2 functions is required.

If part of your application is say a SWING UI , then if on the client side you used getRemoteClass on the main UI class, that class and all its dependencies will load up on the client machine. For example using simplified psuedo-code to illustrate the concept

obj = getRemoteClass ("com.yourCo.yourUIclass");
obj.start();

This starts a class stored on your server, at a remote client location.

You would probably never do this, but its going to get the point across, if you changed that function to loadRemoteClassInst 

obj = loadRemoteClassInst ("com.yourCo.yourUIclass");
obj.start()

That same SWING UI application would start up on the server, even though this code is running on the remote client.

So, now lets make some simplified pseudo-code for a Coherent Disintegration, or CD unit.

objDB = loadRemoteClassInst ("Your DataBase Control Class"); 
objUI = getRemoteClass ("Your UI class");
objUI.start(objDB);

This will load up the database class on the server, and then we inject it into the local client, and then any calls the local client makes internally (eg objDB.getBalance("UserName")) will actually happen against the code running on the server.

The only dangerous thing about this, is that it is so easy to forget that some magic is happening.
It looks like java, it feels like java, it is java, there is just one little thing, those two classes that you injecting into each other, are 1000 miles apart.
In Harbor there is a lot of instrumentation, and tools you can use to see what is actually happening, and its important that when you developing, you try stay aware of distances.

When you develop your standalone application, you do it as normal in your IDE, and the way to master this and create absolutely amazing applications, is to identify or manufacture the piece of code in your application that is the CD unit, or the controller, in other words you are encouraged to develop against the very good MVC model.

The CD unit is really just the controlling piece of code in your application and normally its tiny.
In a mapping application it would be the piece of code that says, start the mapping factory and inject Africa, or Canada etc. 
In a typical application, it would be the part that says, create the UI, create the Model (mapping or travel engine etc), create the desired database pool, inject the pool into the MODEL, and inject the MODEL into the UI.

You then leave that controller unit as is in your standalone application, and create a boot strap CD unit, which is identical to the original POJO CD unit, except you can now decide which parts of it must run client side, and which parts of it must run on the server.
You place the tiny CD unit on your web site, and let your users enjoy full powerful applications.
If you always try identify the CD unit in your application, you'll be well on your way to fame and glory.

A POJO container certainly feels terrific, the simplicity of the design cycle and the resulting power of this new concept is astounding.
We believe the core reason is that the actual control of the whole application is now ours to govern, and more importantly, it can be given away.
In other words where an IOC container hogs control, a POJO container hands it out.
If we had to liken it to a TV set, the maintenance man changes channels on an IOC container, a POJO container gives the user a remote control. 
Its not restricted to business logic, if you a game developer have a good look at this, it runs anything.

Harbor levers the raw power of pure Java, if you can build it, now you can wire enable it.
POJO application servers are the future...

How It Works

Harbor Symbol

Models, Models, Models! Free Modeling Portfolio! ModelCoast.

Photographers! Free Photographic Portfolios. Imagegods.

Visit The Best Free Image Hosting.