[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [ecf-dev] ISharedObjectObjectContainer problem client side - SharedObjects not found
|
Hi Robert,
On 11/1/2010 1:32 PM, Robert Onslow wrote:
Scott.
Yes, I will definitely tell the world about ECF. In fact my target
platform is Felix, so I guess you may be hearing from me on the issue
of dependencies, and I would like to return some documentation to the
project in this area in due course.
Terrific...that would be great. At the moment, we do not have the
resources to create multiple ECF distributions (e.g. one for Felix), but
hopefully with additional documentation and perhaps other contributions,
we can get to this soon.
Ultimately I am trying to use DistributedEventAdmin in the form I
guess it was ultimately designed for. I would like calls to
EventAdmin.postEvent() on the server to be received by EventHandlers
registered in the OSGI frameworks of a number of clients.
What I guess I can't work out from the examples is the correct way to
get the proxy to end up registered on the client side, ready to drive
messages to the EventHandlers. I thought that I should create an
ecf.generic.client container on the client, then connect it to the URI
of the server. I was thinking of casting to an ISharedObjectContainer,
getting the ISharedObjectManager, then getting the EventAdmin proxy,
and registering that in the client BundleContext.
Although this is a viable model, the current DistributedEventAdmin is
slightly different in approach. I'll try to explain:
I think of the model you outline as a 'dumb proxy' approach (no offense
intended by this to anyone). A 'dumb proxy' simply turns method calls
into messages, sends the message to some remote service host, where the
host executes some associated code bloc, and returns a result. The
client-side thread typically blocks/waits until this entire sequence is
completed...so that a return value (if any) can be synchronously
returned to the caller.
The distributed event admin described here [1] is different...mostly
because it's based upon the notion of a 'smart proxy'. In the ECF
shared object API, this smart proxy is implemented as a *replica* of a
shared object...i.e. a *local* copy of a uniquely identified
object...that optionally has replicated state, and can send/receive
messages (using the enclosing container) to/from remote replicas.
For the Distributed Event Admin,. there is a shared object instance
(replica) on *every* client (as well as the server). This instance is
an instance of the DistributedEventAdmin class [2]. This class extends
BaseSharedObject (and so satisfies the ISharedObject contract), and also
implements the OSGi EventAdmin interface...which makes it able to
provide access to EventAdmin.postEvent(Event).
As mentioned, an instance of the DistributedEventAdmin class exists on
*every* container (server and all clients)...so that *local*
EventHandlers can/will be registered with the local replica EventAdmin
implementation (via the OSGi service registry/whiteboard pattern), and
used to dispatch received messages to the local EventHandlers (as per
the OSGi EventAdmin contract).
With this model, when a sender calls postEvent, it goes through the
following:
Sender calls: eventAdmin.postEvent(Event)
a) DistributedEventAdmin impl sends message to other replicas in
container/group
b) DistributedEventAdmin impl dispatches asynchronously/non-blocking
to the *local* EventHandlers (if any)
c) postEvent returns
message from sender goes over the wire...to the entire group/all
clients/server using transport implementation provided by the enclosing
container...
Then Receiver(s)
a) DistributedEventAdmin impl receives message from other replica
b) DistributedEventAdmin impl dispatches asynchronously/non-blocking
to the *local* EventHandlers (if any)
The net effect of this is:
1) The sender call to postEvent is non-blocking (i.e. it returns very
quickly...*before* all receivers and associated EventHandlers have
processes the Event
2) All EventHandlers on all clients/servers will (eventually) receive
the Event (Receiver step b).
3) The calling of postEvent is completely non-blocking. If 'dumb'
proxies are used, then this guarantee cannot be made...because a dumb
proxy can/could always potentially block.
I'm going to stop there...and make sure that this is making sense to
people before going further. If it's not please let me know.
Thanks,
Scott
[1] http://wiki.eclipse.org/Distributed_EventAdmin_Service
[2]
http://www.eclipse.org/ecf/org.eclipse.ecf.docs/api/org/eclipse/ecf/remoteservice/eventadmin/DistributedEventAdmin.html
How does that sound?
Robert
On Mon, Nov 1, 2010 at 4:21 PM, Scott Lewis<slewis@xxxxxxxxxxxxx> wrote:
Hi Robert,
On 11/1/2010 1:48 AM, Robert Onslow wrote:
<stuff deleted>
I have also successfully advertised the info representing the server
sharedobjectcontainer using the IDiscoveryAdvertiser
On the client side, I have successfully found the info using
IDiscoveryLocator, created a client ecf container and connected it to
the server
I have received an IContainerConnectedEvent in
IContainerListener.handleEvent
However, when I query the IDs of the services within the shared object
container, I find an empty array:
//this is fine
ISharedObjectContainer soc = (ISharedObjectContainer) ((IAdaptable)
container).getAdapter(ISharedObjectContainer.class);
//yup, picks up the manager OK
ISharedObjectManager manager = soc.getSharedObjectManager();
//oh dear, I find ids is an empty array
ID[] ids = manager.getSharedObjectIDs();
Am I missing a step here?
Not necessarily. A couple of questions:
1) Where/when do you create/add the shared object within the client
container? Do you do so within your own code?
2) If not, is it your intention/desire that the shared object would be added
at connect time?...i.e. by the server replicating the shared object to the
client?
2 is quite possible...and I can describe how to do it easily enough...but I
first want to understand what you are intending to have happen on the
client...are you expecting to have the shared object replicated into the
client (when connected to the server), or are you expecting to explicitly
create and add the shared object on the client (as well as on the server)?
Both are quite possible/doable...the current eventadmin example creates and
adds the shared object on the client (as well as the server), explicitly in
application-level code (partially just to be more explicit).
So please let us know what your intention/desire is for the client replica
of the shared object, and we'll figure it out.
Robert
ps thanks for a fantastic framework.
Thank you for the pleasant words. It is appreciated. If you feel
comfortable doing so, blogging about your usage of ECF would be most helpful
also.
ECF does not have any marketing resources of it's own, and IMHO EF marketing
is worse than useless when it comes to doing anything for volunteer-based
projects like ECF...so crowd sourcing is the best way to get the word out
for us...
Anyway...thanks.
Scott
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev