[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ecf-dev] Re: pub sub example and distributed OSGI service registry
- From: Scott Lewis <slewis@xxxxxxxxxxxxx>
- Date: Tue, 18 Jul 2006 14:56:36 -0700
- Delivered-to: email@example.com
- User-agent: Thunderbird 22.214.171.124 (Windows/20060516)
Ken Gilmer wrote:
with the remote service: 1) IRemoteService.callSynch(...): which
would provide blocking call/return semantics; 2)
IRemoteService.callAsynch(...) (either one) which sends a message to
remote service, and either uses polling (AsynchResult) or
notification to receive a return value; and 3)
IRemoteService.fire(...): which would simply send a one-way message
to invoke the remote service but not expect or wait for a return value.
So there would be no explicit Java interface binding?
There could be explicit java interface binding as well (i.e. proxies).
The IRemoteService API could have a method Object
IRemoteService.getService() that by contract would expose an Object that
implemented the interfaces specified in the registerRemoteService(...)
The methods currently listed on IRemoteService is intended to allow
explicit support for one-way (fire) and asych invocation (callAsynch).
I probably should have already made this clear and added getService().
How would complex types as parameters be handled?
Through Object  parameters...using/assuming autoboxing for primitive
Personally, I feel much safer about model replication along w/ MDD/MVC
style applications rather than code calling code in a distributed
I don't understand what you mean with this Ken. Do you mean that with
model replication the service is meant to transparently look to clients
as if it's 'local'?
e.g. a client could get a local reference and cast to appropriate type:
IMyServiceInterface service = (IMyServiceInterface)
// call it...hiding the fact that the model is actually replicated locally
int result = service.getMyValue("foo");
Is this what you mean or am I misinterpreting?