felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Francesco Furfari <francesco.furf...@isti.cnr.it>
Subject Re: Again on the UPnP and Event Admin service
Date Wed, 21 Jun 2006 09:59:36 GMT
Hi Karl, (your mail was among the SPAM)
I was thinking to the Event Admin service as splitted in different 
components. In the API specification there isn't an entry "subscribe" as 
well as for postEvent, and it allows a decentralized architecture.

So taking in mind the stack of all calls among the UPnP devices and the 
final consumers, I simply thought that we could avoid to involve the 
Event Admin again. If we continue to adopt a bridge architecture, in the 
case we decide to use postEvent message, we have both the Bridge and the 
EA monitoring the same EventHandlers. I haven't make a cost evaluation 
of all it, but if you think it has a small impact on the EA and the 
runtime we could use these indirection.

I mean the Bridge is needed only to achieve the point 113.1.1 just for 
uniformity and if we adopt a "ad hoc" solution (without posting to the 
EA)  we don't break the general design.
Consider also that we are talking about an unusual way of using the EA 
service. It should be "agnostic", a data producer should put the events 
on the whiteboard and a data consumer should get them without any 
intervention of the EA. In UPnP case the EA is supposed to have some 
knowledge about the events it are managing, otherwise no data consumers 
would be activated.
For these reasons I was thinking to the bridge as a special case.


Karl Pauls wrote:
> Hi Francesco,
> l see your point and I think it is very important to fix the
> situation. I agree with parts of your proposal but I don't understand
> why you don't want to use the EventAdmin itself.
> As far as I can see your problem is not related to the EventAdmin
> being used for the dispatch but only with registering an unbounded
> UPnPEventListener.
> I think we should stick with the first part of your proposal namely,
> registering UPnPEventListeners only in the case a matching
> EventHandler is in place. The second part (that the Adapter would be
> responsible to dispatch the events too) would effectively lead to the
> Adapter becoming a specialized EventAdmin itself. That is not needed
> (unless I'm missing something).
> regards,
> Karl
> On 6/20/06, Francesco Furfari <francesco.furfari@isti.cnr.it> wrote:
>> 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

View raw message