Hey James, I'm still processing all this to see what we can use and how best we can integrate. Thanks for taking the time to write such a thorough email. I'll get back to you shortly.
Alex > From: [EMAIL PROTECTED] > Date: 2004/09/10 Fri PM 04:05:40 EDT > To: [EMAIL PROTECTED] > Subject: RE: Eve integration with Geronimo > > 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/ > >
