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

Aha Scott, yes I'm getting there ..

So presumably I manually create a DistributedEventAdmin on each client
as well as on the server. How do I go on to specify that the the
object on the client is a replica of the object on the server?



Robert

On Mon, Nov 1, 2010 at 10:10 PM, Scott Lewis <slewis@xxxxxxxxxxxxx> wrote:
> 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
>>>
>>
>>
>
> _______________________________________________
> ecf-dev mailing list
> ecf-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/ecf-dev
>



-- 
Robert Onslow
XLegal Limited


Back to the top