Web Start On Steroids - POJO Application Server

A POJO Application Server on the surface feels very much like Web Start, and its often confused with WebStart the well known Java launcher.

When one witnesses an application starting remotely, its easy to mistakenly assume it is Web Starting, after all when a program pops up out of a browser, it just looks like, well, a program, however the mechanism is very different.

As you know a POJO Application Server hosts entire Java applications, and for the purposes of this article we going to assume, that out there, there is a POJO Application Server, and its hosting a java application. 

We going to concentrate on how this Web Start on Steroids illusion is being
created.

Imagine for a moment you writing a plain old Java program somewhere, and you decide you want to launch a remote class sitting on a POJO Application server.

//load a class instance FROM  the POJO Application Server

Class uiApp = vessel.getRemoteClass("the.remote.class.path.to.say.the.UI"); 

if(uiApp != null){

I_UI i_UI = (I_UI)vessel.newInst(uiApp);
i_UI.start();

}

That literally is the code. 

If this is pointing at a Swing UI class on the POJO Application Server, it will jump out of this application that we writing, and run.

Same effect, but its really "Web Starting", from a few lines of code in your application. 

It does not work at Jar level, it will only get the classes necessary to run the remote class, in this (your) application.

So when it starts up a remote UI class, it gives the illusion of Web Starting, but its actually really just allowing one to pull down classes from a remote server application. 

If we took this little bit of code and put it on the traditional WebStart... it would download very quickly, and then start that UI from the POJO server, and users wouldn't know the difference.

But that doesnt explain why the samples that come with a POJO Application Server start so fast. 

On a LAN, in most cases, from the time one says, go, its little more than a few seconds before the application is running.

There's another trick that POJO Application Servers use, look at this code.

//load a class instance ON the POJO Application Server

I_RemApp i_remApp = (I_RemApp )vessel.loadRemoteClassInst(I_RemApp
.class, ""the.remote.class.path.to.say.the dB.Pool");

i_remApp.runSomeMethod();

Again, this is literally what the code looks like.

As you can see we pointing it at a dB pool on the remote POJO Application
Server, and we call methods as usual.

Nothing remarkable really, except that this class, even though we using it in
our application, is not running here, its running on the POJO Application
Server.

It was never downloaded, when we call a method, we actually calling the method
on the remote POJO Application Server.

The reason it starts so quick, is because only the UI classes are running in this
application. 

Developers write little programs like the one above, to start the UI side, here,
and they leave the other classes running on the POJO server.

This is why it gives the illusion of Web Start on Steroids.

Incidentally you now also know half the API calls on a POJO Application Server,
an why, even though remote users run the applications, they never leave the
server.

http://coolharbor.100free.com/index.htm

POJO (Wire Mining) Application Server - Release Version 1.0

POJO (Wire Mining) Application Server - Release Version 1.0

First release of this innovative - Wire Mining
Java Application Server.

Its certainly unusual, like nothing else out there, this newbie may even be the most powerful application server on earth.

This container certainly comes from a different world, and the jury is out.
Will this concept hold up, will it become a way of life, will POJO developers marry this container, is it a niche or a flood building?

Application servers, as we have come to know them, are boxed technologies. We build beans in them, then we apply JMS, JPA, JNDI, use annotations to inject other boxes, and through these components we slowly build up the application's server ability.

With the POJO Application Server, one drops the full application in and then, we do nothing, that's it, the container carries no additional tool-set.

One may think, no tools in the container, that cant be good, it must be weak?

The POJO container feeds on Java applications, if its a bean, it runs it, if its an accounting package, it runs it, if its a game, it runs it.

No tools, but enormously capable.

Well that's certainly different, and the client side? No, there is no client side, we drop the full application in.

The POJO container serves up the client to a remote machine.

So where is the client? Its the UI side of the application.

And the Server? That's the server side of the application.

These differences shock one's intellectual senses, but the conceptual simplicity behind it really twists the mind - this idea of Wire Mining.

The container does not change an application, it simply splits it. It sends the User Interface classes to the remote users machine, and keeps the rest of them on the server. Through RMI the client side continues to operate against the server classes... i.e. the application continues to operate as normal, but its backwards, we don't apply RMI to the application, the application is pulled apart by the container.

This idea of intercepting calls from UI classes to Server side classes, and extending those method calls across a network, is called Wire Mining.

When we instance a class in another class and call a method, essentially we are creating a wire, and that's what this container mines.

That is all it does... but that translates to container specific API that one can count on one hand, the ability to design and debug an application outside of the container, and in most cases no more than a dozen lines of code to put the application on the wire.

Other characteristics emerge... when just the client classes are delivered to a remote machine, its so small, it challenges the web browser.

Whether you put a web site up, or deliver full Java (client side) applications to a remote user, is now a very gray area.

Whether users download games, or run them from the server becomes a choice.

Whether your office accounting package will now also popup from a browser link becomes a possibility.

The final answer is in perspective, where does something with no tools get its capability from?

The answer is that its all inside any POJO application already. The idea doesn't look up for a greater technology, it looks down through a microscope.

When an application's wires are mined, and class calls are stretched across the network, a simple getter and setter method starts to look a lot like a message service. A class left behind on the server, starts looking very similar to biz logic. A class with a thread feels very much like a remote server to the user.

No boxes, but its all there.

The best definition is...

A POJO Application Server takes the developers Conceptual View of the class structure in a POJO application,
and turns it into a physical networked reality.

We created it with the goal of trying to make our lives easier, accidentally discovered a few things along the way, and cant believe the capability that has emerged.

Its free, because we thought maybe you also like simple.

You be the Judge and Jury... electric chair, or hall of fame.

Perhaps the only question is... what happens if a competitor uses it?

Enjoy!