Skip to main content

[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:

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 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) 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 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.




How does that sound?


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

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)

//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

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.


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

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 crowd sourcing is the best way to get the word out
for us...



ecf-dev mailing list

Back to the top