[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ecf-dev] Re: pub sub example and distributed OSGI service registry
|
Personally, I feel much safer about model replication along w/ MDD/
MVC style applications rather than code calling code in a
distributed fashion.
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:
I mean, rather than using the OSGi Service" functionality (service
discovery, advertising, and consumption) as a way to bind isolated
runtime environments together, using a passive model (ie, no
application-level remote code calling) by which operations are
performed against a domain model, which is then replicated across
peers using something like Datashare. So I would have some sort of
model bundle that hosted a model. The model would be exposed to my
other local bundles via a traditional OSGi service interface.
However no ECF related functionality would be exposed. The model
bundle would internally use ECF to perform replication and change
notification. Of course, as said in previous emails, the
"distributed OSGi services" approach has been developed before
(flowOSGI.pdf). I would be curious to play around with distributed
OSGi services, but would be inclined to avoid them in general, mainly
due to the issues described in the "A Note on Distributed Computing".
-Ken
On Jul 18, 2006, at 5:56 PM, Scott Lewis wrote:
Hi Ken,
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(...) call.
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 types.
Personally, I feel much safer about model replication along w/ MDD/
MVC style applications rather than code calling code in a
distributed fashion.
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)
container.getRemoteService(remoteReference).getService();
// 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?
Thanks,
Scott
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev
