SpiritSoft announced the general availability of SpiritWave Real-Time. This real-time service bus extends the ESB with adaptable server-side grid technology. Real-Time is a combination of enterprise integration messaging, collaborative programming and shared memory using real-time caching, and distributed active management technologies.
- Posted by: Dion Almaer
- Posted on: October 08 2003 10:30 EDT
Real-Time dynamically provisions services for any J2EE container while using and extending existing management infrastructure. It is built on standards, including JMS, JCache and JMX.
SpiritWave Real-Time Service Bus Components:
- Administrative: Manual and Automated Management
- Applications: Distributed Processes & Services
- Distributed Programming Model: Service, Process & Shared Memory Model
- Virtual Operating System based on JMX & J2EE containers
Pricing for SpiritWave Real-Time begins at $6,000 per CPU.
Read the press release: SpiritSoft Delivers SpiritWave Real-Time for Next Generation Real-Time Service Bus to Rapidly Align Existing Computing Resources
- SpiritSoft Announces SpiritWave Real-Time, Enterprise Bus by Jay K on October 08 2003 12:30 EDT
- JCache compliance by Dmitriy Setrakyan on October 08 2003 21:15 EDT
I wanted to look at a demo/tutorial on SprintSoft's spiritWave, but looks like their website http://www.spiritsoft.com is down.
Also, why does "Quote Original Message" clear the message while posting the reply?
Just one bookmark - for all java related news, articles and blogs.
We're not aware of any recent problems with www.spiritsoft.com : it's certainly up at the moment. Please try again. If you continue to have problems getting hold of evaluation software please email us on sales at spiritsoft dot com.
It is built on standards, including JMS, JCache and JMX.
After carefully evaluating Cache APIs from SpiritCache and Tangosol Coherence (2 JCache compliant products) I could not help to notice that about the only thing they have in common is that they both use java.utils.Map as a basis for their caching API. However both vendors extend java.utils.Map and add significant chunk of different API/functionality to it which immediately constitutes a vendor lock-in for any end user.
So does JCache compliance simply mean implementing java.utils.Map interface? Maybe we should rename it to JMap ;-)
Anyway, I am sure both products are great with or without JCache, but I do believe that JCache compliance is used exclusively as a marketing tool right now rather than a meaningful standard.
xNova - Reusable System Services for Java and .NET
Dmitriy makes a fair point, but "JCache compliance" would have more value if the JSR actually made some progress. In spite of the active commercial interest of Tangosol and SpiritSoft (both represented), under the spec leadership by Oracle - who should know better - JSR-107 is one of the slowest in the JCP - there's been no public activity since the expert group was formed in April 2001 - not even a community review. And that's after the JSR originally anticipated a 12 week cycle (30 months ago).
I think that reflects very badly on the JCP. Surely the process should have some kind of timeout - either replacing the spec lead or closing down the whole thing if the expert group can't come to a conclusion within a reasonable timespan.
Note: I used to work at SpiritSoft - in marketing, so I know what Dmitry means :-)