Hey Alex
From: Alex Karasulu [EMAIL PROTECTED]
Also we have begun to separate out frontend plumbing from LDAP
specific code in Eve's frontend. This code is a TCP specific SEDA
framework.
We're going to make this into a subproject on its own so we can reuse
it for a Eve integrated Kerberos server without tight coupling (it can
also be
standalone). Trustin Lee (guy who did Netty) will be looking into
adding UDP support to this in project.
So what does this all mean for integration? Well we want to write
wrappers for this SEDA framework where Eve just plugs in as another
simple
protocol to be able to benefit from those wrappers. By writing a
geronimo wrapper for SEDA rather than an Eve specific frontend we now
allow any
protocol to be fired up within geronimo without having to
specifically integrate that protocols frontend. WDYT?
So we really want to write a SEDA framework wrapper intead of one
specifically for Eve. This also makes me think if its worth writting
wrappers for the backend of Eve and this raises several questions I
still don't have answers to but these I'll leave for other emails.
I guess it depends what you mean by SEDA. Mostly I tend to think of the
Channel abstraction in the concurrent.jar as being a pretty good
abstraction for SEDA, where the channels can be local in VM or remote
and you can put/take/poll objects - then the rest is just
implementation details. Or some folks like to abstract away the low
level SEDA like protocol of sync/async send behind a dynamic proxy to
make SEDA invisible as it were. e.g.
http://activemq.codehaus.org/maven/apidocs/org/codehaus/activemq/util/
AsyncProxy.html
If what you mean is more of a SEDA based transport framework, well
we've been working for quite some time on one of those on the ActiveMQ
project :). Last benchmark we did was 22,000 messages/second sustained
throughput on 2 2-way linux boxes with producer, broker, consumer all
going across the network for 1-2K message sizes and reasonably low CPU
usage (YMMV).
Currently we've transports for
* VM (in memory both sync true SEDA)
* TCP / SSL
* UDP multicat
* NIO through g-networks and EmberIO
* JGroups
* JRMS
* JXTA
* HTTP (for tunnelling)
* Jabber (experimental)
* AIO4J (experimental)
In addition we have discovery protocols (Zeroconf ActiveCluster) to
make peer-style clusters of auto-discoverying clients servers
(Zeroconf is particularly cute as it works nice with Apple's
Rendezvous), together with load balancing fault tolerance transports
(e.g. auto-fail over to another server in case of failure etc).
Other protocols to come are SOAP-over-TCP, FTP, SMTP, SQL and file
system when we get chance.
Details of the code are here...
http://activemq.codehaus.org/Code+Overview
Basically we have a really simple TransportChannel API which can
represent any kind of transport protocol.
http://activemq.codehaus.org/maven/apidocs/org/codehaus/activemq/
transport/package-summary.html
The minimal contract we support for application protocols is that they
must decide if a method call is sync (requiring a receipt such as a
commit()) or async (fire forget) and for async, whether a flush is
required after the send. Consuming is pluggable based on the transport
- so it decides if there is a thread, is it pull/push or how threads
multiplex such as for NIO / AIO.
Most of the transport channels can be reused as is with a pluggable
WireFormat which dictates how command objects (we use the Packet base
class) get serialized on the wire. e.g. we have a default, fast as
possible, wire format for the JMS Packets, as well as Jabber XStream
based ones etc.
The TransportChannel abstract represents about the 8th or 9th
generation of this kind of abstraction the team have used over the last
5 years or so for implementing high performance messaging SEDA
transport abstractions - so if nothing else, I'd advise you to go down
a similar route of abstraction; then at the very least you'll be able
to reuse our transports easily we can easily plugin into your stuff -
especially if you want to take advantage of our clustering, failover
replication protocols..
James
---
http://radio.weblogs.com/0112098/
