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
