MantaRay, an open source enterprise-grade messaging middleware product, has been released.

MantaRay combines messaging system optimization and peer-to-peer architecture for improved speed, scalability, reliability, affordability, flexibility, ease of use and deployment time. It integrates JBoss, WebLogic and WebSphere, and supports TCP, SSL and HTTP transport protocols.

MantaRay also boasts persistency, durability, transaction support, security and guaranteed delivery for real-time and offline scenarios. Being serverless, it has no single point of failure or congestion and theoretically unlimited scalability. Its lightweight design enables it to be fully embeddable and manageable at the application level.

What do you think of MantaRay?

Related resources:
Frank Sommers' article, "Wither Those Tiers"

...enterprise-grade...

ENTERPRISE!!! If I never see that word again I'll be happy.

Really impressive architecture. I happened to check out Coridan's MantaRay capabilities in last year's JavaOne event and they were the *only* true p2p based integration platform providers there...

am still goinig through the architecture details, but i found it pretty easy to use as compared to other integration platforms i've worked with (which are quite heavy in terms of their footprint to say the least)!

-GT
http://gautam_tandon.home.comcast.net

Since ManataRay is a serverless who takes care of message persistence ? If the subscriber is not running who does the work of delivering messages when the subsriber comes up in case of durable subscription ?

Really impressive architecture. I happened to check out Coridan's MantaRay capabilities in last year's JavaOne event and they were the *only* true p2p based integration platform providers there

You must have missed the Apache ActiveMQ team at least years JavaOne then :). ActiveMQ's had pure peer based messaging for a few years now. James LogicBlaze Fuse: the Open Source SOA runtime

I never knew that. Doesn't seem to be a heavily touted feature of ActiveMQ, however. Why continue to use a brokered approach when you are able to perform persistent p2p messaging (which should be more performant)?

Maybe because ActimeMQ's architecture is primarily broker based? I admit that I don't have all the details but setting a flag ("embed = true") doesn't strike me as something which will make a broker play nice and become embedded that easily. MantaRay's architecture has been designed from day one to be fully distributed and embeddable. The architecture itself (which is a big differentiator) help MantaRay handle OCC (Occasionally Connected Computing) scenarios which stem from network problems quite easily. Yuval Lubowich Coridan

Interesting... how could i miss that! apache definitely has a history of credibility of producing good frameworks/products... the only issue is the amount of coding involved based on your business requirements (nevertheless, hats off for apache as they do the best to reduce the development pain). not sure, when it comes to real world implementation, would apache's activeMQ be as agile and less code intensive as MantaRay's solution... any experts out there... comments?? Thanks, GT http://gautam_tandon.home.comcast.net

Hi, the presentation of the concept of MantaRay is really interesting. Is there anyone, who has experience with MantaRay in productiv environments? So far I haven't found much sources about it (except the homepage of MantaRay). Peter

The release of MantaRay was perfect timing for us. We needed a way to integrate our JAVA application with third party APIs. The peer-to-peer architecture addressed all our concerns of speed, scalability, reliability, guaranteed delivery for real-time and offline scenarios. I was most impressed how quickly we implemented it into our code. Nice work ManatRay.

Does the network performance go down because the messages are multicasted ?

Well the short answer is no. MantaRay does not use multicast to send messages rather is uses "normal" unicast to send them. Multicast is only used in one particular plug-in; the automatic discovery plug-in. You can turn it off anytime and use other ways of discovering your "world". Use the MWB or Static configuration. Yuval Lubowich

From the reference manual: MantaRay supports two persistency strategies. File-based persistence [... and] Database Persistency In file-based, we have: Choose a memory cache option ('False' or 'True') in the force_every_entry parameter. 'False' causes MantaRay to cache the key/value pair in memory before writing the data to disk. This is the default option, which improves performance, but is less reliable, as the data may be lost in the event of a system error How's that for transaction durability? Were the fabulos preformace measurements done using this default setting? As for the database persistence, using it doesn't take us back to the "broker" architecture - throwing away the scalability, no-single-point-of-failure, etc? Anyway, does anybody know if MantaRay, as a JMS implementation, with file-based persistence can be enrolled in distributed transactions using JTA?

No, using a db does not take you back to a brokered architecture. Just set up a small DB on each machine using manta ray. The docs say it works with MySQL and Oracle -- I'd bet it would also work for Postgresql, Hypersonic SQL, etc. So you could use either something more towards the enterprise end, or an embedded database depending on your needs.

Hey, well yes and no, if you are planning on using a single database (centralized) then yes it would bring you closer to a broker approach. There are a few things I would mention. Database persistency was added to MantaRay due to client demand (some companies wanted to use their "well known databases" for persistency (they have grown used to doing DB persistency). You can always run a local database on each node (although I don't recommend that :-)). Regarding your second question, MantaRay supports both modes of transactions (user transactions and XA transactions). MantaRay has been tested extensively with file based persistency and JTA. In fact using the file based persistency raises the performance by quite a bit as can better optimize the persistency mechanism. Yuval Lubowich, Coridan