[Spread-users] Request/response Java API

Ben Bernhard ben.bernhard at reference-info.com
Tue Sep 2 09:51:21 EDT 2003


Hi all,

We might divide the problem into a few parts:
- Marshalling/unmarshalling the Java request/response into/from a wire
format.
- Synchronous blocking for a response and request/response correlation
- Server-side implementation registration and the associated dispatching
code.

I don't need distributed objects, just remote method calls. That means I
don't need object references, instance registration/lookup, or garbage
collection.

Preferably, the implementation would not be Java specific. In other
words, the wire format should be something a c++ application could parse
(not serialized objects for example).

It certainly looks like I can implement my needs over Spread. I'm aware
of partial solutions I could start with (SOAP for marshalling, etc), but
if somebody has a complete Spread implementation at hand, it would save
me some time. 

Thanks for any pointers,
Ben



> -----Original Message-----
> From: Daniel Rall [mailto:dlr at finemaltcoding.com]
> Sent: Monday, September 01, 2003 9:40 PM
> To: RYAN CAUDY
> Cc: Ben Bernhard; spread-users at lists.spread.org
> Subject: Re: [Spread-users] Request/response Java API
> 
> Ben wants remote procedure call semantics for Spread.  Consider
XML-RPC
> over a Spread transport, or even a simple HTTP request/response as
> examples.  I've had this same desire myself.  What's unclear is
whether
> Ben wants a synchronous or asynchronous transaction (having both would
> be convenient).
> 
> - Dan
> 
> 
> RYAN CAUDY wrote:
> > I'm not sure what you mean by request/response semantics.  Could you
> clarify for someone unfamiliar with what you mean?
> >
> > ----- Original Message -----
> > From: Ben Bernhard <ben.bernhard at reference-info.com>
> > Date: Friday, August 29, 2003 4:36 pm
> >
> >>I'm investigating spread for use in a distributed application.
> >>Messagingapplications are obvious, but some communication will be
> >>request/response. Is anybody aware of a bolt-on API that would
provide
> >>request/response semantics?





More information about the Spread-users mailing list