It's there in a few forms, but not as far as I'd like to see it
go. OpenEJB implements a lot of these things and Jeremy's
bullets capture why pretty well. I've chatted a lot about it
with him and others at Gluecode. I've been beating poor Hiram
on the head with it forever. It's essentially xinet.d, but in
Java.
The idea is to have one consistent way of producing sockets
which is decoupled from the consumers of the sockets (e.g. the
actual protocols). Further, the EJBContainers themselves are
not (at least didn't used to be) dependent on any of the
protocols, so you can add addition implementations of protocols
to the system without having to change the container.
Despite it being in the org.openejb namespace, the code is
already generic. So what we have in OpenEJB and soon to move
into ActiveIO is this:
A Socket Producer: Contains a stack of QoSs for producing the
socket, essentially as interceptors that can be stacked up
anyway you like.
Implemented now are:
- Simple thread-pool (not used since work manager support
was added)
- Geronimo Work manager (e.g. better thread pool)
- Host Based Authorization (for example, saying only
localhost can use this IP:PORT)
- Request Logging (doesn't do much now)
To be implemented:
- SSL support
- Support for ActiveIO abstractions so more than just TCP/IP
can be used.
- Better request logger
To be integrated:
- Hiram's One-port functionality is high on the slate.
A Socket Consumer: The thing that actually reads/writes data
from the socket.
Implemented now are:
- EJBd (the custom OpenEJB ejb/jndi protocol)
- Telnet (a cheap telnet implementation I wrote)
- HTTP (a cheap HTTP implementation I wrote, Jetty's or
Tomcat's would be better)
- Admin (a small protocol to do administrative stuff with
the server like starting/stopping things)
Could be implemented:
- One to wrap jetty's stuff
- A network-based deployer
- An Admin protocol specifically for Geronimo
- Any code that allows you to pass in a socket could just be
wrapped and plugged in
- A VM-level Socket producer so "legacy" code could be
supported as well (code we don't control that insists on
creating it's own ServerSocket)
- A proxy to reroute calls to another IP:PORT
Right now in a plan you can, for example, have two producers for
the EJB protocol. One only for local traffic and one for
internal traffic.
<!-- Public, smaller thread pool and restricted access to a
set of specific hosts -->
<gbean gbeanName="geronimo:type=NetworkService,name=EJB1"
class="org.openejb.server.StandardServiceStackGBean">
<attribute name="name">EJB</attribute>
<attribute name="port">2401</attribute>
<attribute name="host">209.237.227.195</attribute>
<attribute
name="allowHosts">209.98.98.9,207.171.163.90,216.239.39.99</
attribute>
<attribute
name="logOnSuccess">HOST,NAME,THREADID,USERID</ attribute>
<attribute name="logOnFailure">HOST,NAME</attribute>
<reference name="Executor"><name>DefaultThreadPool</
name></ reference>
<reference name="Server"><gbean-
name>openejb:type=Server,name=EJB</gbean-name></reference>
</gbean>
<gbean name="DefaultThreadPool"
class="org.apache.geronimo.pool.ThreadPool">
<attribute name="keepAliveTime">5000</attribute>
<attribute name="poolSize">30</attribute>
<attribute name="poolName">DefaultThreadPool</attribute>
</gbean>
<!-- Private IP bound, bigger thread pool, access to just
the local subnet -->
<gbean gbeanName="geronimo:type=NetworkService,name=EJB2"
class="org.openejb.server.StandardServiceStackGBean">
<attribute name="name">EJB</attribute>
<attribute name="port">2402</attribute>
<attribute name="host">192.168.10.12</attribute>
<attribute name="allowHosts">255.255.255.0</attribute>
<attribute
name="logOnSuccess">HOST,NAME,THREADID,USERID</ attribute>
<attribute name="logOnFailure">HOST,NAME</attribute>
<reference name="Executor"><name>HighThreadPool</name></
reference>
<reference name="Server"><gbean-
name>openejb:type=Server,name=EJB</gbean-name></reference>
</gbean>
<gbean name="HighThreadPool"
class="org.apache.geronimo.pool.ThreadPool">
<attribute name="keepAliveTime">1000</attribute>
<attribute name="poolSize">100</attribute>
<attribute name="poolName">HighThreadPool</attribute>
</gbean>
<gbean gbeanName="openejb:type=Server,name=EJB"
class="org.openejb.server.ejbd.EjbServerGBean">
<!-- blah blah blah -->
</gbean>
In this setup we have two different pools. It would be nice to
use the same pool for both, but partition them differently so we
could guarantee no one is dominating the pool.
The StandardServiceStackGBean is just one collection of QoSs.
You could create another gbean that had the ones you want or you
could declare them individually in a plan (a little hard to
manage though).
<gbean
gbeanName="geronimo:type=NetworkService,interceptor=Daemon"
class="org.openejb.server.ServiceDaemon">
<attribute name="port">2402</attribute>
<attribute name="inetAddress">192.168.10.12</attribute>
<reference name="SocketService"><gbean-
name>geronimo:type=NetworkService,interceptor=Logger</gbean-
name></ reference>
</gbean>
<gbean
gbeanName="geronimo:type=NetworkService,interceptor=Logger"
class="org.openejb.server.ServiceLogger">
<attribute name="logOnSuccess">HOST,THREADID</attribute>
<attribute name="logOnFailure">HOST</attribute>
<reference name="SocketService"><gbean-
name>geronimo:type=NetworkService,interceptor=AccessController</
gbean-name></reference>
</gbean>
<gbean
gbeanName="geronimo:type=NetworkService,interceptor=Pool"
class="org.openejb.server.ServicePool">
<attribute name="keepAliveTime">5000</attribute>
<attribute name="poolSize">30</attribute>
<attribute name="poolName">EjbRequestThreadPool</attribute>
<reference name="SocketService"><gbean-
name>openejb:type=Server,name=EJB</gbean-name></reference>
</gbean>
<gbean gbeanName="openejb:type=Server,name=EJB"
class="org.openejb.server.ejbd.EjbServerGBean">
<!-- blah blah blah -->
</gbean>
This is more or less same as the above except we;
- explicitly declared all the interceptors in the stack
- left out the Host-based authorization QoS
- Constructed the ServicePool in away that makes it
create it's own pool instead of passing one in.
Anyway, that's just what is there now. It gets a lot more fun
when you add SSL and have support for a remote deployer. Then
you could could still have a remote deployer, but enforce it
over SSL and restrict the hosts that can access it. Much more
is possible if you get creative. For example, HBA is still
really a naive way to prevent a denial of service attack. You
could implement something that did clever things to thwart those
kind of attacks, but only use that for publicly bound socket
producers.
This is a big long email, but by no means complete. There are
really a lot of things you can do with having a more robust way
that sockets are dished out in the system and ensuring the whole
server is using it. I consider what we have to be a good
prototype and plan to rewrite it all in ActiveIO to be more
transport agnostic. I know Greg Wilkins has some great code in
Jetty that is related and would like to get him contributing to
it was well if he's up for it.
-David
On Aug 13, 2005, at 6:24 PM, Dain Sundstrom wrote:
Isn't this something that ActiveIO already does? Hiram? David?
-dain
On Aug 13, 2005, at 5:24 PM, [EMAIL PROTECTED] wrote:
Jeremy Boynes <[EMAIL PROTECTED]> wrote on 14/08/2005 02:44:40
AM:
> Aaron's recent thread on SSL has made we wonder if we should
consider
> providing our own socket listeners for HTTP(S) and other
protocols
> rather than using the ones supplied by the containers we are
embedding.
>
> Reasons for doing it include:
> * ability to integrate with custom work managers (thread
pools) and
> SSL infrastructure
> * consistency across all embedded containers
> * potential for multi-protocol support on one end-point
> (i.e. multiplexing everything over one port like WebLogic
does which
> can make life easier when firewalls are involved)
> * potential for integrating with custom QoS frameworks e.g.
allowing
> custom negotiation with load-balancers in a clustered
environment
> * potential for hi-av version upgrades where we can version in a
> upgraded component and hand off the physical socket
resulting in
> no loss of availability
>
> Note that none of those features are HTTP specific.
>
> The downside of course is that it may weaken integration
between the
> listener and the container being embedded; for some
containers they may
> be so closely coupled that doing this will actually make things
> difficult. For example, I think doing this would be fairly
easy for
> Jetty, I don't know how easy it would be for Tomcat, OpenEJB,
JMX,
> ActiveMQ etc.
This sounds like a good idea. I assume we aren't forcing
containers to use this mechanism, so if someone want to
integrate container X but doesn't initially want to go to this
much effort, they can use X's socket listener and change to
use Geronimo's in the future (although this migration will
impact their configuration).
If we do end up going down this path, it would be worthwhile
talking with the Derby project about SSL and authentication
for the network server. AFAIK, this work hasn't been started
yet, so it would probably be a good time to talk with them.
See the mail thread from the links in http://issues.apache.org/
jira/browse/ GERONIMO-842 .
John
>
> --
> Jeremy
This e-mail message and any attachments may contain
confidential, proprietary or non-public information. This
information is intended solely for the designated recipient
(s). If an addressing or transmission error has misdirected
this e-mail, please notify the sender immediately and destroy
this e-mail. Any review, dissemination, use or reliance upon
this information by unintended recipients is prohibited. Any
opinions expressed in this e-mail are those of the author
personally.
