lichtner,
We are planning a JMS implementation as part of the integration
of Enhydra and Jonas into the Enhydra Enterprise (J2EE)
application server. We have three possible ways to proceed
including your suggestion. Until we have finalized the plan we
cannot say any more at this time, but expect some news very soon.
Thanks,
Christophe
Christophe Ney mailto:[EMAIL PROTECTED]
Enhydra Open Source Project http://www.enhydra.org
Lutris Technologies http://www.lutris.com
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of lichtner
> Sent: Friday, January 21, 2000 7:22 PM
> To: Joe Gittings
> Cc: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]'
> Subject: RE: JMS on top of Cornell's Ensemble toolkit
>
>
>
> 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".
>
----
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".
