|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  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 . 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 returnsmessage 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 replicab) 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  http://wiki.eclipse.org/Distributed_EventAdmin_Service 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
Back to the top