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/
