I have looked at it but I think that JMS is a safer bet. JavaSpaces is
more elegant but JMS was designed by companies who have been selling
production messaging systems and it is designed to work with EJBs.
I would definitely favor a JavaSpaces implementation written on top of an
EJB server with JMS though.
I agree with you that Sun has a lot of technologies that they are not
pushing very hard, not only specs but also implementations, like JSDT.
TRAMP is another example (yet another reliable multicast implementation).
I think the reason that some things are not promoted shows lack of
confidence in those products.
--------------------------------------------------------------------------
Guglielmo Lichtner (212) 627-9253 (Home)
(917) 972-2477 (Cell)
"Your quote here."
- B.Stroustrup
On Fri, 21 Jan 2000, Joe Gittings wrote:
> In this context, I thought that I should draw the attention of the list to
> JavaSpaces. The reason I mention it is that Sun is not (yet) pushing
> JavaSpaces very hard, so it is easy to overloook this technology. There is
> no mention of it either in the J2EE or JMS areas of the java.sun.com
> website.
>
> If you are thinking of using JMS it is worth considering whether JavaSpaces
> would not be a more appropriate solution. It is a more distributed model
> than JMS. In fact, it sounds like Ensemble is trying to do something very
> similar.
>
> >From the JavaSoft website:
> >>15. Isn't JavaSpaces technology just another implementation of a
> messaging system?
> >>A JavaSpace system can be thought of as an event-driven distributed
> >>cache with behavior transfer capabilities. This technology extends well
> >>beyond the base functionality of a simple messaging system.
>
> Joe
>
>
> -----Original Message-----
> From: lichtner [SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, January 20, 2000 8:17 PM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: JMS on top of Cornell's Ensemble toolkit
>
>
> I have just joined and I know that you will let me know if I should not
> post to both users and development lists.
>
> I am interested in using JMS implemented using reliable multicasting.
> I have checked your mailing list archives and I saw a handful of emails
> expressing interest but nothing else. I hope I didn't miss anything.
>
> Unless someone is working on JMS already I would propose that we write a
> JMS implementation for publish/subscribe (rather than point-to-point),
> using a reliable multicast protocol. I am specifically interested in
> synchronous replication using multicasting and distributed transactions.
> This is what Netscape Application Server, OrbixTalk, IBus and Tibco
> ObjectBus already do this - and they charge an arm and a leg. As far as I
> understand Jonas already supports distributed transactions - correct me if
> I am wrong - so it's a good candidate.
>
> I would like to propose that we deviate temporarily from a pure java
> implementation and write a JMS implementation on top of a very promising
> project developed at Cornell University, called Ensemble. This package
> handles reliable multicasting and recognized concepts like groups, joining
> and leaving a group and all that. It is written in an object-oriented
> dialect of ML, and looks very solid. It is derived from ISIS and HORUS,
> two Cornell projects that are used all over for the reliable multicasting
> they offer (stock exchanges and battle ships!). It already has a simple
> Java interface so there is probably no jni code to be written.
>
> Although Ensemble is in ML there are other pure-java toolkits (though
> probably not as well-tested), like Java Shared Data Toolkit, which uses
> LRMP, a reliable multicast protocol from INRIA. So that could be another
> option.
>
> I am a Java developer and I consult in New York City, and I would like to
> see a project like Jonas support replication because I would then use it
> in commercial settings. I am working on a world-famous group of web sites
> right now and the staff here is very availability conscious and they would
> rather go for a cluster than for huge SMP machines in order to scale up. I
> expect to see more of this type of shop in future contracts. I would like
> to get this JMS implementation out in a few months.
>
> Unfortunately I am extremely busy. Besides my day job I also have a couple
> of project going on in my spare time, so I would like to ask everyone here
> if they (perhaps a student who needs a Master's thesis) would like to
> volunteer to pore through the JMS spec and implement a minimal JMS as
> described above. Another thing that I would favor is writing the code
> myself but have someone from the main Jonas developers draft a design.
>
> Thanks for reading this long email.
>
> Guglielmo
>
> --------------------------------------------------------------------------
> Guglielmo Lichtner (212) 627-9253 (Home)
> (917) 972-2477 (Cell)
>
> "Your quote here."
> - B.Stroustrup
>
>
> ----
> To unsubscribe, send email to [EMAIL PROTECTED] and
> include in the body of the message "unsubscribe jonas-users".
> For general help, send email to [EMAIL PROTECTED] and
> include in the body of the message "help".
>
> ----
> To unsubscribe, send email to [EMAIL PROTECTED] and
> include in the body of the message "unsubscribe jonas-dev".
> For general help, send email to [EMAIL PROTECTED] and
> include in the body of the message "help".
>
----
To unsubscribe, send email to [EMAIL PROTECTED] and
include in the body of the message "unsubscribe jonas-users".
For general help, send email to [EMAIL PROTECTED] and
include in the body of the message "help".
