----- Original Message -----
From: "Leon Rosenberg" <[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
