Dear all, I would like to re-open the discussion about UPnP and Event Admin (EA)(see felix-68 http://mail-archives.apache.org/mod_mbox/incubator-felix-dev/200605.mbox/browser)
because I think the current implementation has some drawbacks.Basically the implementation works fine but it implies an increment of the network communication, we could avoid with a specular implementation.
From the previous discussion we all agreed that a Bridge solution is the best approach. It is compatible with the previous R3 release, and UPnPDevice developers don't have to deal with the EA details. Anyway, the current implementation forces all UPnP devices to notify their internal changes to the Bridge in order to transparently dispatch the upnpEventNotify messages to the EA.
Let me briefly introduce the original UPnP eventing mechanism to better explain why that solution implies a waste of resources. The Eventing in UPnP, like in Jini, is based on a leasing protocol in order to reduce the traffic on the network. When a Control Point needs a notification about some state variable changes, it sends a subscription message proposing a leasing time, after which it will renew the subscription. However in the leasing protocol is the UPnP device that ultimately decides the leasing, answering with the effective leasing time basing on its workload. Notice that a device is usually silent, and it delivers notification only if there are interested Control Points. From this point of view a device is not an autonomous data producer.
So far, when the Bridge registers a UPnPEventListener with a NULL filter it obliges all the UPnP devices to notify their changes. In this scenario the UPnP Base driver is a broker that, as soon as listen for the registration of such listener, has to subscribe all the physical device on the network to receive their messages and to send once again to the Bridge, that in its turn will send to the EA. The EA, if there aren't data consumer with the right topic and filter, will spent all the time discarding them. At running, on the network, we will see the exchanging of a lot of HTTP messages (notification and renewal) that are, in my opinion a waste of resources and they break the original objectives of the UPnP Eventing specification.
The solution I suggest consists of inverting the process of bridging the events, starting from the data consumers perspective. I attached a class diagram to illustrate this new approach. The Bridge listen for registration of EventHandler with UPnP topic, and registers an EventAdminAdaptor implementing the UPnPEventListener interface with the same filter used by the EventHandler. As soon as a valid UPnPDevice will notify some event to the adapter, it will delivery the message directly to the EventHandler (instead of using postEvent message). This schema works on demand without increase the trafic on the network and moreover we could also apply some optimizations. For example if there are many EventHandler registered with the same filter we could re-use the same Adaptor object to dispatch the events, that is the Adaptor can act as broker.
Some final consideration on the R4 spec.The relationship between UPnP spec. and Event Admin spec. is a little bit ambiguous. It does not state anything of wrong but my first impression, reading the EA spec, was that it came in help of the UPnP developers, being the communication mechanism it goes to propose an overcoming of the XXXListener on which UPnP spec is based. IMHO, as clarification, the coming revision of the R4 should better explain that the basic communication mechanism for the UPnP subsystem is always the same. And the UPnP developers should never deal with the EA. In the proposed scheme the postEvent message with UPnP topic is never used and it should be inhibited because any usage potentially represents a duplication of messages. The paragraph 111.9 should be moved in the EA service spec. because it only declare the properties that are used to bridging UPnP events. I my opinion the relationship between UPnP and EA is summarized in the The paragraph 113.1.1 - "OSGi events – The OSGi Framework, as well as a number of OSGi services, already have a number of its own events defined, for uniformity of processing these have to be mapped into generic event types". Hence the EA spec only come in help of users of UPnP devices (namely Control Points), they can either use the standard communication mechanism (UPnPEventLister) or the new one based on the EventHandler, if available.
As last consideration about the EA spec., I was wondering whether the Karl's implemetation of immutable events (see Dictionary class in http://svn.apache.org/viewvc/incubator/felix/trunk/org.apache.felix.eventadmin.bridge.upnp/src/main/java/org/apache/felix/eventadmin/bridge/upnp/UPnPEventToEventAdminBridge.java?view=markup could be a valid alternative to the current implementation of org.osgi.service.event.Event class (see http://svn.apache.org/viewvc/incubator/felix/trunk/org.osgi.compendium/src/main/java/org/osgi/service/event/Event.java?view=markup ). In section 113.3.2 there are warnings about mutable objects used as property values, in fact the default implementation of the Event class does a soft copy of the dictionary. In the case of UpnP Events the property value is not immutable, thus the approach used by Karl. I would be expected to see in the EA specification the definition of a contract, based for example on the serializable interface or a deep clone implementation, among EA and EA clients, but overall the approach used by Karl is more simple.
So, I would like to know your opinion on the matter and whether there is a general consensus I propose to modify the current UPnP Bridge implementation and the default implementation of the Event class.
regards, francesco
<<attachment: EventAdminBridge.JPG>>
_______________________________________________ osgi-dev mailing list osgi-dev@bundles.osgi.org http://bundles.osgi.org/mailman/listinfo/osgi-dev
