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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
