Patrick Thomas wrote:
Your remark about POJOs being part of the API prompted me to chime in
-- William pretty much gave you the general answer, that Tomcat
doesn't seem to be the best way to go for this (because everything is
passed via http).
Maybe HTTP is the transport protocol for a messaging framework that runs
on top. I don't know enough about all the different intra-JVM
mechanisms I've head of CORBA, RMI over IIOP, EJB Remote, XML-RPC, and a
dozen more related protocols. Some are too raw or not a framework, some
cover multiple levels of the same problem. A more featureful
Application Server (like JBoss) can already do EJB Local/Remote call
design patterns out of the box, I don't (think I) need JBoss and
everything it is. I suppose what throwing in the air is the question:
Is there a web resource that details each of the common intra-JVM
communication mechanisms thats in place for their pro's con's,
everything from memory consumption, runtime speed, security policies,
programming interface, easy of setting up how to future proof remotable
API usage so it remains compatible and extensible at the same time.
Then what contracts does each of these mechanisms provide to the
applications that use them.
HTTP could be a big part of a push or pull data mechanism or it maybe
implemented outside of HTTP with raw sockets and another wire protocol,
in this case it would be a JAR file that sides outside of tomcat itself
and my application which is running in the same JVM as TC would use it
independatly of TC.
Your serializing objects idea is a little too raw for my use, I'm
looking for something with a more reliable contract and wider community
testing than a roll your own TCPIP stack approach.
--
Darryl L. Miles
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
