river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Sarman" <johnsar...@gmail.com>
Subject Re: Jini, JavaSpaces, JEE, some questions, and some other development issues and ideas.
Date Wed, 03 Sep 2008 21:11:06 GMT
Wade Chandler wrote:

> *) Jini provides, while not something designed for long term
>> persistence, JavaSpaces, and JEE provides EJB persistence which can
>> be used as short or long term storage.
>>
>
> You might want to reconsider storage via JavaSpace again in terms of
> loosely coupled communication.   While JavaSpaces aren't meant for long-term
> storage, you can easily enough create a worker that pulls "StorageEntries"
> from space and writes them to some persistent data store.
>
> You can even have multiple worker processes each dedicated to absorbing
> different entries and storing them to (perhaps) different locations. Each
> worker could evaluate whether to store or discard the data on its own
> criteria without worrying about changing the code that is generating the
> entries for storage.   Workers could even do post-processing of the data
> before storage, potentially freeing up some computational resources on the
> system that requests the storage.
>
> I wouldn't suggest that this is a system that you'd want to use every time;
> just wanted to point out a potential methodology.
>
> James

In Fact I do not see what would prevent a scenerio such as

@Entity
public class Person extends AbstractEntry {

@Id()
 public Long id;

@Column()
public String firstName;

@Column
 public String lastName;

public String getFirstName(){
  return firstName;
 }

 //..getter here
//lastname setter
//lastname getter
}

where the class is both an Entry for the JavaSpace and properly annotated
for the Persistance API

more food for thought on that supposing you would want to use the JavaSpace
for short term storage and have a service that can
pull entries and write them to a database without having to add extra code
to map from an entry to a database.

>I have read some on proxies in the specifications, but haven't really dug
there. Are Jini proxies a single end point or at least a distributed >end
point which collectively manages all the calls so they may be limited or
threaded to
> support high throughput just as EE servers do? I don't guess it really
matters, proxy interfaces, I assume, can do what ever they need to >do in
the back ground including communicating with some kind of a central
management application.

I would describe a smart proxy as a technique to allow the service to run
either fully on the the client, fully on the server or a mixture of both.
Suppose in JEE you have a JNLP client that uses a Remote EJB. If you wanted
to run some of the code locally, well you would write that code in the
client of the JNLP and call the Remote service for any server side stuff.
This requires maintenance on both the client code and the server code.  With
a smart proxy, you can use the clients JVM for some of the processing and
the server JVM for some of the processing, but all the code is maintained on
the server side.  The client gets the proxy from the lookup
service(discoverable). So if the admins need to update the algorithm, all a
client has to do is rediscover the service(assuming the service interface is
not altered) and voila the client is updated without having to recompile.
That too me is one of the powers of Jini.  Also these smart proxies can be a
property in an Entry, which means the possibilities for JavaSpaces usages
goes way beyond a simple mechanism for data storage.

-
John Sarman

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message