[
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
|
Hi Peter,
Peter Nehrer wrote:
Hi Scott, Ken,
I agree that this mechanism (sketched out in the Pub/Sub example)
could be used to implement something like distributed OSGi services.
In the simple case, any OSGi service could be exposed through a remote
replica, which acts as a "dumb proxy" -- simply forwards all calls to
the master. However, the architecture also allows us to use "smart
proxies" for appropriate OSGi services -- instead of simply forwarding
all method invocations to the master, the replica may perform some of
the logic itself and communicate with the replica on its own terms
(e.g., to sync up some state, or what have you).
Yes, I agree. Replication makes possible 'dumb proxys'...the usual for
RPC...OR 'smart proxies'...those with replicated state/code.
Note that I'll still probably make some minor changes to the API. For
example, I think I'll have the "Subscription" object communicate with
the replica only, post-replication, rather than always with the master
(I was trying to avoid imposing any sort of an interface on service
replicas, but I don't think that's necessary). Also, I think I'll
expose some of the replica lifecycle events to the client, especially
the unexpected disposal (so that the client doesn't have to find out
the hard way -- getting an exception upon service invocation). Lastly,
I think I'll pass the replica reference itself to the client upon
successful subscription, so that the client doesn't have to do the
lookup on their own. Anyway, just thinking out loud...
Seem like good ideas to me.
At the right point, it may make sense to move these pubsub apis into
either a) core; b) datashare; c) a new pubsub API plugin.
Scott
You may notice that even though the silly example app makes use of the
IPublishedServiceDirectory, the actual pub/sub mechanism doesn't
depend on that directory. If your application has a reason to believe
that there's a service with a fixed ID published in some container,
then it may subscribe to it w/ out making use of the directory.
Alternatively, one might want to use a different "directory" mechanism
in their application (though the one provided is generic and could be
quite useful).
--Peter
Scott Lewis wrote:
Hi Ken,
Ken Gilmer wrote:
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.
OK, I see.
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".
OK. I don't disagree with you Ken...as I have similar concerns
(based upon ANODC and other papers critical about transparency) about
RPC-based systems in general...including RPC for remote OSGi
services. Believe it or not, ANODC and other such papers critical of
network transparency is really one of the major reasons why ECF is
replication/asynch messaging based to begin with.
But I/we have gotten input that a remote OSGi services API is
desireable for some and perhaps many, and of course a model like
ECF's can support the creation of RPC APIs (e.g. through 'trivial
replications'...i.e. proxies). So I would at least like to see if
there is something useful ECF could do here...and what/whether people
would be interested in ECF doing such a thing.
Thanks for clarification/explanation,
Scott
-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
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev
