Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] Problem regarding hello.ds examples. 
 Hi Jeff,

On 9/16/2010 3:28 PM, Jeff Hamm wrote:

<stuff deleted>
By 'making calls to several machines at once in broadcast fashion'...what exactly do you mean/expect occur with the *results* of the remote call?  That is, if I invoke a method on 3 pub/sub group members, and all three return an Integer, what result(s) do you expect on the service consumer?  This is the part of the pub/sub model that is not a direct fit to 'normal' OSGi remote services (which is basically remote method call)...as the assumption in the OSGi service model (java method call) is that there is but one return value.

I think in the case of a broadcast message, my supposition would be that these type of commands fall into the asynchronous realm where I am telling a class of client to "run" or "stop" or some other generic type of command where the responses back would all be of the same type. For the client responding to the admin, my expectations are the same in that each client will be sending "status" type information back that needs to be displayed. The tricky part may be segregating the messages to the right handler for display back to the ui but that's just hash tables and iterators :)
The tricky bit about multiple responses is typically timing. For example, how long should it be possible for a response to be processed before something is assumed to have gone wrong? 


Likewise, the clients will need to be able to respond back to the server with the synch and async events autonomously creating a byway set of communication bridges for lack of a better term.

This is sounding more like a message bus...where the assumption is that messages are sent to n receivers...all of which are in the same pub/sub 'group' (in jms it's referred to as a 'topic', in JavaGroups it's a
'group').   The assumption with this model is that all messaging is
asynchronous (no blocking/waiting for return values...at least partially since there could be n return values), all group participants can be both senders and receivers (at least conceptually).

You're right. I have referred to it as a message bus in the architecture diagrams. The part that I am concerned with is that I need to support the cases where when I am dealing with an individual client and it has discovered some piece of information that it needs to satisfy in order to continue. In this case, it needs to send a very pointed message to the admin and basically wait until it has an answer to proceed. In this use case, I can't dump a message on the bus and proceed on.

OSGi has direct support for the 'group' model via the EventAdmin service, which has the notion of asynchronously 'posting' a message to a given topic.  Of course these messages to EventHandlers can easily result in local method call...and messages sent in reply.

Interesting concept. Might need to explore this idea some more.


Yeah, it sounds like EventAdmin might prove useful for you.


<stuff deleted>

Does this make sense? Let me know if there are more questions...although I may not be able to provide full support given my own time constraints.

It's starting to ( I think ).  I did a sample implementation using activemq but the idea of having a separate server to manage the messages kindof turned me off. We are trying to make this as lightweight as possible and easy to manage. (not a design constraint just a best practice).
Well, one thing to note...it is possible to use the ECF generic server for distributed EventAdmin...as well as ActiveMQ/JMS. That might allow you to be more lightweight (ECF generic server), but support larger installations as well (e.g. JMS/ActiveMQ). 



At some point I will need to go back and look at the discovery components. I'm thinking that this will be the best way to detect and manage the services that are exposed by the clients in the peer-peer connections. When I get that point I'd love to have another discussion such as this one.
Ok. Like everything else in ECF the discovery API is provider independent...so that it's possible to use the network discovery protocol of your choice. We currently have zeroconf, slp, xml-file-based, apache zookeeper (quite popular these days), dns-sd based discovery providers. These providers differ in the specifics of lan/wan support, security characteristics, dependency on other services (e.g. dns, etc). And of course, if you want to create your own custom discovery provider and use it underneath then that's an option as well. 

Scott

Back to the top