tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Johnny Kewl" <j...@kewlstuff.co.za>
Subject Re: POJO Application Server for Tomcat
Date Tue, 21 Aug 2007 07:56:42 GMT

----- Original Message ----- 
From: "Leon Rosenberg" <rosenberg.leon@googlemail.com>
To: "Tomcat Developers List" <dev@tomcat.apache.org>
Sent: Monday, August 20, 2007 10:22 PM
Subject: Re: POJO Application Server for Tomcat


> On 8/19/07, Johnny Kewl <john@kewlstuff.co.za> wrote:
>>
>> I call it a POJO Application server, I've mentioned before that we 
>> actually popping full java >applications out of browsers, but then it was 
>> very much something only I could use, messy >libraries etc. What I've 
>> done now is (try) make a more professional package, and it would be 
>>  >really nice if the guru's just have a little read about this 
>> unbelievable servlet, and let me >know what you think, if just to see how 
>> someone is using your Tomcat, in a very unusual >way.
>>
> ...
>> I think its a new way of looking at application servers, it feels like a 
>> discovery to me, but >then who knows maybe there is something out there 
>> like this, I dont know, all I do know is >that when we drop this servlet 
>> into Tomcat, we run POJO applications over the wire as if >they were 
>> right their on the client machine, the same applications that will also 
>> run >standalone on the machine. Its so different that I really struggled 
>> to find the relevent theory >behind this technology, I think I'm close, 
>> but any pointers or corrections would be much >appreciated there as well.
>
> Just one question, what do you need tomcat for?
> Remove the tomcat from your app server, add rmi, corba, and, if you
> really wish, a http connector (which could be tomcat or a small http
> listener with xml parser) , and yeah, you are back to the good old
> days...

Well, I thought about that, but not quite in the same way, I thought about 
taking it down to the Apache native socket level, but decided TC is a much 
better solution. Harbor doesnt use RMI, and it doesnt use SOAP, all the 
protocols for Harbor, the required serialization, the Java reflection, 
everything was re-done.
Crazy Huh ;)
I wanted a pure fast binary HTTP based protocol, and there wasnt a complete 
protocol out there that could do what I needed.
RMI I felt is a little too primative for what I needed, but as you know, the 
real problem is that its not HTTP driven, and as soon as firewalls come into 
play, guess what, you probably have to use tomcat and a servlet to tunnel 
through the firewall, nah! its old technology, ok for EJB servers ;)
Then there is the whole concept of registries, which RMI and just about 
every other SUN service specification, EJB, SOAP, all have some place the 
thing has to be registered. In this context I felt that it was also 
superfluous. Harbor addresses in the same way a web site does. My 
application is at http://harbor etc, which is really nice and easy for users 
to understand. An EJB client is really a completely separate thing to the 
EJB server implementation and needs a discovery mechanism. Harbor houses 
full applications, so the client side "knows" about its server side, its 
just very different. In coding terms it comes down to,
 I want to talk to that Harbor
 I want to run that thing
 Go!
It literally comes down to that code... have a look at the examples on the 
site.
Probably the easiest "RMI" available.

So, to answer your question, the protocol is especially made to be as easy 
to set up and run as a web site, and runs on port 80, just like a web site 
does, it makes it very easy... you never going to see a user asking how to 
get the "RMI" working through their firewall etc.
So to answer your question, Tomcat is essentially a nifty container with 
great HTTP communications, thats what this technology needs, why re-invent a 
terrific wheel.
The rest is perspective.... if one looks at TC as "nifty container with 
great communications", why does an application server do its own thing, and 
incorporate TC as an add on.... the reason I think is because they do 
exactly that, use "old" RMI, and it sees web technology as an addon.
I decided that there is no better communication protocol than the web based 
ones (at binary level), why mess with that, make the application server use 
it.
As for SOAP, well any protocol with all that machinery is bound to be slow 
and pathetic, it links to non java products, ok thats nice.
Its just philosophy... do you think an servlet container should be a layer 
ontop of an application server, or the other way around (this makes more 
sense to me).

As for not having a servlet container at all, I wonder how other application 
servers are doing their HTML admin consoles...
When I'm working on a site and suddenly realise that an application server 
may come in handy, its really nice not even having to consider moving away 
from TC, I just keep going...

Hope that answers the question.... Harbor is new, need to give us a little 
time to start bench marking etc, but I have a feeling when its delivering 
full accounting programs and powerful games to users on the web.... it wont 
be seen as the relic container ;)... not even sure a comparison will be 
possible.
For example EJB has this whole concept of running local or remote, I thought 
about that, but it makes no sense in this container, local just means the 
application runs standalone, ie just run the accounting package or game on 
the machine.... its very different, and it is difficult to relate older 
technology.
I dont think its possible to build Harbor using established specs... need to 
have a viscious imagination, and be brave enough to say, that spec sucks ;)
Its working great for us, but only time will tell if my imagination is 
actually dangerous ;)

> Leon
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message