river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Wonderly <gr...@wonderly.org>
Subject Re: Jini, JavaSpaces, JEE, some questions, and some other development issues and ideas.
Date Sat, 30 Aug 2008 15:02:03 GMT
Thanks for the questions Wade, others will have better responses I'm sure, but 
here's my take, in line.

Wade Chandler wrote:
> If one were formulating an argument for the use of Jini and JavaSpaces versus JEE,
> what exactly would the decision maker be? I know you can use JEE inside Jini 
 > services, and thus they are complimenting each other in this regard, and then 
Jini
> services can be discoverable, but is that the real beauty of Jini versus EE?
> I guess I'm having a hard time reconciling why I should want to really dig into 
> Jini more versus just continuing to use EE. 

Jini is all about exploiting mobile code everywhere.  It provides a model and 
services that really want that to be possible, and used widely.  For me, these 
services, the specs and their availability in the network are what makes Jini 
work well.  If you do JEE, it provides a mechanism for interfacing software with 
the network.  It, itself, doesn't provide standards at the level of network 
services that Jini provides from my perspective.

> I can have remote code with EE, and I can have it clustered and running on 
 > multiple backends. Such a thing would only be done in Jini, per my
> understanding, by having a Jini front end where the code which the service 
> executes still executes in an EE environment using stateless or stateful
> beans. Too, JavaSpaces seem cool from the sense of remote memory, but 
> I'm having a hard time reconciling why JavaSpaces are any better than
> EJBs except for the fact that I don't really have server storage coding 
> for the backing JavaSpaces tuples, though for any type of application to 
> survive shutdowns and crashes data would need to be stored in some type 
> of a permanent data store such as a database. Using a database would 
> make sense anyways, so it seems tuples/entries are better suited to 
> temporary distributed memory, but again, maybe wrong here and needing
> clarity.

Javaspaces is for conveying requests between interested parties, not for storing 
data.  You would, store data somewhere more resilient, and then formulate 
requests with references to this data that would fly around between parties, 
using the Javaspace for communications so that you can plug in new players 
without others having to know they exist.

For example, if you want to insert a step into a process, you might have the 
producer of the data comming into the new step, produce a different type data, 
have the new step, consume it, and then output something that was ready for the 
original receiver to use.  By using a Javaspace, the insertion only affects the 
producer, not the consumer in this example.  It might, of course be necessary 
for the original consumer to know something new about the changes made by the 
new step.  But, it might also be a convenient versioning mechanism as well.

> I know this is a Jini dev list, but I'm trying to reconcile these things
> to make sure I want to commit resources here as I am really interested
> in the automatic discovery of services and pluggability, and I'm very 
> interested in distributed services, where service calls are distributed
> and clustered the server/service side so that multiple instances of a
> service handle different requests in the backend for a given front end,
> if this is possible with Jini services as part of the Jini 
 > specification. This would basically be clustered services.

This plugability based on "type" of message consumed is a key feature of using 
the Java type system.  It is possible in other messaging mechanisms using, say 
XML, or other programming language neutral systems.  But, you can't send "new" 
behavior without having downloaded code.  Instead, you have to make every system 
aware of any semantic meaning the data carries, which you'd rather keep abstracted.

> Something bothering me about JavaSpaces entries is they force public 
> fields/variables. To me they should operate off the same assumptions
> JavaBeans and serialization operate. EJBs work this way as well. 
> Truly those things should be compatible thus true encapsulation can
> take place. I haven't figured out why entries differ from the other
> specifications.

One of the primary issues with JavaSpaces is to that it tries really hard to not 
download code.  In doing that, the marshalling between the writer and the space, 
extracts data from the class to send down to the space.  That data needs to be 
visible for the matching mechanisms used for read/take.  In order to keep from 
downloading code, it can't really "serialize" the data in the normal way.

This works well in many cases.  I created a exploratory project at 
jspace.dev.java.net, which does two things different.  One, it separates these 
key values, used for matching, from the data.  It provides for the use of 
marshalled or unmarshalled data for keys in this regard, by also including a 
matching implementation, which might marshall/unmarshall, or package key data in 
a particular way, that is advantageous for the application.

The space part also includes an executor mechanism along with an iterator 
similar to what Javaspaces05 added.  The executor allows you to send executable 
code into the space and run it there to do things when entries match.

The design allows for downloaded code to be used if an application needs it, 
with full serialization of all data.  But, it also allows you to customize its 
use so that you get behavior very much like a Javaspace without conventional 
serialization.

> Too, do I have the wrong idea about the River incubator?

The Sun team, and other committers have the lowdown on their intents here.

Gregg Wonderly

Mime
View raw message