xuzhenbao commented on issue #515:
URL: https://github.com/apache/celix/issues/515#issuecomment-2019332332

   > Does the Event Admin need to be aware of remote events? I was considering 
the possibility that a Remote Event Admin could register an EventHandler with 
"event.topics=*". This way, the Remote Event Admin can receive any local events 
and, perhaps, even filter for events marked for remote communication (something 
like "event.filter=(celix.event.remote.enable=true)") and send them remotely. 
The counterpart of the Remote Event Admin can inject messages using the local 
Event Admin. The downside is that, from a remote perspective, the events are 
always treated as a postEvent. However, considering that remote calls can lead 
to long blocks and possible timeouts, this approach might be preferable.
   
   According to the EventAdmin specification:
   > The Event Admin service must be registered as a service with the object 
class org.osgi.service.event.EventAdmin. Multiple Event Admin services can be 
registered. Publishers should publish their event on the Event Admin service 
with the highest value for the SERVICE_RANKING service property. This is the 
service selected by the getServiceReference method.
    
   Maybe we can implement an EventAdminWrapper, which implements the Event 
Admin Service, and its service ranking is the highest. In this way, 
EventAdminWrapper can forward events to remote (use EventRemoteProvider) or to 
local (use EventAdmin). And EventAdmin can be unaware of remote events.
   
   In addition, should we consider multiple EventRemoteProviders existing? If 
yes, EventAdminWrapper can also be used to implement a strategy to select the 
perfect EventRemoteProvider to forward remote events.
   
   
   For the MQTT broker address information, it maybe requires dynamic discovery 
in my work.
   Maybe we can implement dynamic discovery in the following ways:
   1. Use the previously mentioned remote service registration mechanism. But 
it has the following two disadvantages:
       - RSA is required
       - In the case of multiple network interfaces, it can't choose which 
network interface the broker address information is exposed on.
   2. Making discovery independent of RSA and REA. The problem with this 
approach is that if discovery is implemented based on bonjour, then the MQTT 
service should have a specific service name "_mqtt._tcp" 
(https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=MQTT),
 which conflicts with the service name we have defined ("_celix-rpc._udp"). I 
haven't  a solution to this problem currently. Maybe we need to give up using 
the service name "_mqtt._tcp", otherwise discovery_zeroconf may expose the 
details of bonjour.
   3. Using the bonjour client to implement dynamic discovery of the MQTT 
broker service address.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@celix.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Reply via email to