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
