Again on the UPnP and Event Admin service

[Francesco Furfari <fr...@isti.cnr.it>]

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

Re: Again on the UPnP and Event Admin service

[Karl Pauls <ka...@gmail.com>]

>         I have spoken face to face with Francesco I  understood that he don't
> want to create a new EventAdmin but just a bundle that act like and
> EventAdmin. Let me clarify that.

I know.

>         The Event Admin(EA) is used to split Event Publisher(EP) from Event
> Handler(EH), so it's duty of EA to discover which EH receive a Event
> every time EP send an Event. So the EP won't even know who and if
> someone have handled the Event.
>         In our case the situation is quite different, in fact to avoid the
> overload off UPnP Network we set up a EP only when EH are present so our
> Bridge will need the code that handle such things.

Understood.

>         So because we have the code that track EH we can even avoid to go
> thought the EA for sending the event.

That is the problem right there. I understand the proposal but there
is a bit more to the EA than the plain tracking of EventHandlers.
There are for example some security aspects that the EventAdmin needs
to handle too.

>         Before say that's not correct please notice that this behavior even if
> it's not the one aspect by OSGi Analyst is not out of spec and also
> we'll avoid the duplication the execution of code that track EH. BTW, I
> know that such implementation may be not clear to understood at the
> beginning.

I understand the implementation and I already stated several times
that it is in line with the spec. Still, in order to get this right
you end-up with all the functionality of the EventAdmin. This is where
the code duplication is.

>         Finally, that's the way Francesco thought about "distributed EA"

To be perfectly clear, Francesco's proposal is a valid solution and a
good one too (IMHO). All I'm trying to do is to find the optimal
balance between reuse and the network issues.

> Stefano "Kismet" Lenzi
>
> P.S.: The only extra code need will be a tracking of EA because when
> none are present on OSGi our bridge must stop to send Event to EH

As mentioned above, its not only the tracking but the security as well.

regards,

Karl
-- 
Karl Pauls
karlpauls@gmail.com

Re: Again on the UPnP and Event Admin service

[Stefano Lenzi <ki...@interfree.it>]

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).
Hi Karl,
	I have spoken face to face with Francesco I  understood that he don't
want to create a new EventAdmin but just a bundle that act like and
EventAdmin. Let me clarify that.

	The Event Admin(EA) is used to split Event Publisher(EP) from Event
Handler(EH), so it's duty of EA to discover which EH receive a Event
every time EP send an Event. So the EP won't even know who and if
someone have handled the Event.
	In our case the situation is quite different, in fact to avoid the
overload off UPnP Network we set up a EP only when EH are present so our
Bridge will need the code that handle such things.
	So because we have the code that track EH we can even avoid to go
thought the EA for sending the event.

	Before say that's not correct please notice that this behavior even if
it's not the one aspect by OSGi Analyst is not out of spec and also
we'll avoid the duplication the execution of code that track EH. BTW, I
know that such implementation may be not clear to understood at the
beginning.

	Finally, that's the way Francesco thought about "distributed EA"

Stefano "Kismet" Lenzi

P.S.: The only extra code need will be a tracking of EA because when
none are present on OSGi our bridge must stop to send Event to EH
	
> 
> regards,
> 
> Karl
> 

Re: Again on the UPnP and Event Admin service

[Stefano Lenzi <ki...@interfree.it>]

Karl Pauls wrote:
> 
>>  To avoid the super right issue the bridge won't be able to set up an
>> event publisher on demand(only when an even handler will be avaiable on
>> the Framework) and that will end up to a degradation of the OSGi host
>> and also of the REAL UPnP Network(I mean the set of device connected on
>> network that are shown as imported on the OSGi network)
> 
> I'm not sure what you are trying to say here. Do you mean that we need
> to weigh-up whether we require an additional permission for the bridge
> v.s. causing UPnP network load? I do think the additional permission
> is acceptable in this case.
Exactly :-)

Re: Again on the UPnP and Event Admin service

[Karl Pauls <ka...@gmail.com>]

> I think that there is problem, that is: the bridge should have the
> permision: org.osgi.service.event.EventHandler, GET, that usually is not
> need by an event publisher.

True, but I think that this is acceptable. The bridge does by
definition need both, org.osgi.service.EventAdmin[GET] and
org.osgi.service.upnp.UPnPEventHandler[PUT] permission, anyways. Now
it will need an org.osgi.service.event.EventHandler[GET] permission
too.

>  To avoid the super right issue the bridge won't be able to set up an
> event publisher on demand(only when an even handler will be avaiable on
> the Framework) and that will end up to a degradation of the OSGi host
> and also of the REAL UPnP Network(I mean the set of device connected on
> network that are shown as imported on the OSGi network)

I'm not sure what you are trying to say here. Do you mean that we need
to weigh-up whether we require an additional permission for the bridge
v.s. causing UPnP network load? I do think the additional permission
is acceptable in this case.

> Stefano "Kismet" Lenzi

regards,

Karl

-- 
Karl Pauls
karlpauls@gmail.com

Re: Again on the UPnP and Event Admin service

[Stefano Lenzi <ki...@interfree.it>]

Karl Pauls wrote:
> On second thought, I guess it is sufficient to only register an
> UPnPEventListener in the bridge in case that there is at least one
> EventAdmin present and at least one EventHandler interested in a
> matching topic.
> 
> That way you end-up with two levels of degradation. First, in case no
> bridging is needed, the bridge shouldn't be installed. Second, in case
> bridging is potentially needed it is only done if at least one
> EventAdmin and one interested EventHandler is available.
> 
> I don't think that it makes much sense to do anything more
> sophisticated then that. It is a small change that I could commit as
> soon as we have consensus.
> 
> What do you think?
> 
Hi Karl,
	I think that there is problem, that is: the bridge should have the
permision: org.osgi.service.event.EventHandler, GET, that usually is not
need by an event publisher.
	To avoid the super right issue the bridge won't be able to set up an
event publisher on demand(only when an even handler will be avaiable on
the Framework) and that will end up to a degradation of the OSGi host
and also of the REAL UPnP Network(I mean the set of device connected on
network that are shown as imported on the OSGi network)

Stefano "Kismet" Lenzi

Re: Again on the UPnP and Event Admin service

[Karl Pauls <ka...@gmail.com>]

On second thought, I guess it is sufficient to only register an
UPnPEventListener in the bridge in case that there is at least one
EventAdmin present and at least one EventHandler interested in a
matching topic.

That way you end-up with two levels of degradation. First, in case no
bridging is needed, the bridge shouldn't be installed. Second, in case
bridging is potentially needed it is only done if at least one
EventAdmin and one interested EventHandler is available.

I don't think that it makes much sense to do anything more
sophisticated then that. It is a small change that I could commit as
soon as we have consensus.

What do you think?

regards,

Karl


> 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 <fr...@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
> >
> >
> >
> >
> >
> >
> >
> >
>
>
> --
> Karl Pauls
> karlpauls@gmail.com
>


-- 
Karl Pauls
karlpauls@gmail.com

Re: Again on the UPnP and Event Admin service

[Francesco Furfari <fr...@isti.cnr.it>]

  In UPnP case the EA is supposed to have some
> knowledge about the events it are managing, otherwise no data consumers 
> would be activated.

it was: ...otherwise no data producers would be activated

f

> 
> 
> 
> 
> 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 <fr...@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
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>

Re: Again on the UPnP and Event Admin service

[Karl Pauls <ka...@gmail.com>]

> > I guess the correct way of dealing with this situation is to always
> > use the EventAdmin with the highest service ranking. In case this cant
> > be done (due to no ranking at all or two services ranked equal) just
> > take an arbitrary one and stick with it until it is unregistered (then
> > start over).
>
> I think there is always a "best" service, because if all else fails,
> then lowest bundle ID is considered best.

Ah, o.k. - all the better.

> -> richard

regards,

Karl

-- 
Karl Pauls
karlpauls@gmail.com

Re: Again on the UPnP and Event Admin service

["Richard S. Hall" <he...@ungoverned.org>]

Karl Pauls wrote:
> I guess the correct way of dealing with this situation is to always
> use the EventAdmin with the highest service ranking. In case this cant
> be done (due to no ranking at all or two services ranked equal) just
> take an arbitrary one and stick with it until it is unregistered (then
> start over).

I think there is always a "best" service, because if all else fails, 
then lowest bundle ID is considered best.

-> richard

Re: Again on the UPnP and Event Admin service

[Dennis Geurts <de...@luminis.nl>]

  <reporting>
    <plugins>
      ...
      <plugin>
        <artifactId>maven-surefire-plugin</artifactId>
      </plugin>
    </plugins>
  </reporting>


On Mon, 2006-07-03 at 12:34 +0200, Marcel Offermans wrote:

> On Jul 3, 2006, at 12:19 , Francesco Furfari wrote:
> 
> > I have still to understand how to develop test case in mvn\Osgi,  
> > Marcel is working on it.
> 
> If it's a plain junit test, you can just stick it in the src/test/ 
> java folder and it will be picked up by the test framework (if you  
> run mvn test or some target that indirectly invokes the tests).
> 
> The only problem I have with these tests is that they're not yet  
> automatically included in the generated website, but that's just my  
> inexperience with Maven and I'm sure that will be fixed soon.
> 
> For "integration tests" I want to create a new Maven plugin that will  
> launch an OSGi framework and perform some tests. There might be  
> something we can use from the Knopflerfish project there (they have  
> such a framework).
> 
> Greetings, Marcel
> 





Dennis Geurts

luminis®  

___________________________________

m: +31 (0) 612 078236
e: dennis.geurts@luminis.nl
i: www.luminis.nl 
___________________________________

 

Re: Again on the UPnP and Event Admin service

[Marcel Offermans <ma...@luminis.nl>]

On Jul 3, 2006, at 13:23 , Francesco Furfari wrote:

> in my case they aren't junit tests. I would be too complicated so  
> far, but I agree that we need a plugin that launches the framework  
> with the possibility to configure the bundles to install.  
> Unfortunately in our case (UPnP) it is not always sufficient, as  
> some times we should launch external devices too, so automating the  
> tests is not so trivial :(

Creating a plugin to start the framework, install a specific set of  
bundles and run some tests would be the first step. With this in  
place we could then perhaps add bundles to simulate specific devices  
for even more advanced testing scenarios. However, I think we should  
avoid depending on specific, physical hardware for any of the  
automated tests because those would never be available on a  
continuous build server.

Greetings, Marcel

Re: Again on the UPnP and Event Admin service

[Francesco Furfari <fr...@isti.cnr.it>]

Hi Marcel,
in my case they aren't junit tests. I would be too complicated so far, 
but I agree that we need a plugin that launches the framework with the 
possibility to configure the bundles to install. Unfortunately in our 
case (UPnP) it is not always sufficient, as some times we should launch 
external devices too, so automating the tests is not so trivial :(

ciao
francesco


Marcel Offermans wrote:
> On Jul 3, 2006, at 12:19 , Francesco Furfari wrote:
>
>> I have still to understand how to develop test case in mvn\Osgi, 
>> Marcel is working on it.
>
> If it's a plain junit test, you can just stick it in the src/test/java 
> folder and it will be picked up by the test framework (if you run mvn 
> test or some target that indirectly invokes the tests).
>
> The only problem I have with these tests is that they're not yet 
> automatically included in the generated website, but that's just my 
> inexperience with Maven and I'm sure that will be fixed soon.
>
> For "integration tests" I want to create a new Maven plugin that will 
> launch an OSGi framework and perform some tests. There might be 
> something we can use from the Knopflerfish project there (they have 
> such a framework).
>
> Greetings, Marcel
>

Re: Again on the UPnP and Event Admin service

[Marcel Offermans <ma...@luminis.nl>]

On Jul 3, 2006, at 12:19 , Francesco Furfari wrote:

> I have still to understand how to develop test case in mvn\Osgi,  
> Marcel is working on it.

If it's a plain junit test, you can just stick it in the src/test/ 
java folder and it will be picked up by the test framework (if you  
run mvn test or some target that indirectly invokes the tests).

The only problem I have with these tests is that they're not yet  
automatically included in the generated website, but that's just my  
inexperience with Maven and I'm sure that will be fixed soon.

For "integration tests" I want to create a new Maven plugin that will  
launch an OSGi framework and perform some tests. There might be  
something we can use from the Knopflerfish project there (they have  
such a framework).

Greetings, Marcel

Re: Again on the UPnP and Event Admin service

[Francesco Furfari <fr...@isti.cnr.it>]

Hi Karl,
sorry to answer you so late.
Anyway I  full tested the code and it works properly.
I saw you use both the keys in the PostEvent message (UPnP.device.id and 
upnp.deviceId)  and I agree with you.
I've written  a simple test code that allows to register and update EH 
graphically.
At the moment you find it in my sandbox, I have still to understand how 
to develop test case in mvn\Osgi, Marcel is working on it.
So I'm going to close the issue.
regards
    francesco

ps:
again 4-3 ?  ;-)


Francesco Furfari wrote:
> Hi Karl,
> I  was disconnected this weekend.
> I will try some test this evening or  tomorrow
> ... of course my tests were erroneously based on the old keys too :-D
>
> francesco
>
>
>
> Karl Pauls wrote:
>>>  remind me to offer a beer next time you come in Italy ;-)
>>
>> I look forward to it :-)
>>
>>> What I've realized is that EA subscriptions are limited respect the
>>> tracking possibilities offered by the UPnP spec.
>>
>> I just realized that there is another problem with this. The spec
>> requires that the events are published with upnp.serviceId and
>> upnp.deviceId keys... it follows that our approach with the filters
>> will not work because "upnp.serviceId" != UPnPService.ID and
>> "upnp.deviceId" != UPnPDevice.ID. I will commit a patch shortly that
>> fixes this by replacing all occurrences of mentioned keys in an
>> EventHandler filter with its UPnP counterpart. That way it should work
>> again. Would be great if you could test it sometime soon.
>>
>>> thanks
>>> francesco
>>
>> regards,
>>
>> Karl
>

Re: Again on the UPnP and Event Admin service

[Francesco Furfari <fr...@isti.cnr.it>]

Hi Karl,
I  was disconnected this weekend.
I will try some test this evening or  tomorrow
... of course my tests were erroneously based on the old keys too :-D

francesco



Karl Pauls wrote:
>>  remind me to offer a beer next time you come in Italy ;-)
>
> I look forward to it :-)
>
>> What I've realized is that EA subscriptions are limited respect the
>> tracking possibilities offered by the UPnP spec.
>
> I just realized that there is another problem with this. The spec
> requires that the events are published with upnp.serviceId and
> upnp.deviceId keys... it follows that our approach with the filters
> will not work because "upnp.serviceId" != UPnPService.ID and
> "upnp.deviceId" != UPnPDevice.ID. I will commit a patch shortly that
> fixes this by replacing all occurrences of mentioned keys in an
> EventHandler filter with its UPnP counterpart. That way it should work
> again. Would be great if you could test it sometime soon.
>
>> thanks
>> francesco
>
> regards,
>
> Karl

Re: Again on the UPnP and Event Admin service

[Karl Pauls <ka...@gmail.com>]

>  remind me to offer a beer next time you come in Italy ;-)

I look forward to it :-)

> What I've realized is that EA subscriptions are limited respect the
> tracking possibilities offered by the UPnP spec.

I just realized that there is another problem with this. The spec
requires that the events are published with upnp.serviceId and
upnp.deviceId keys... it follows that our approach with the filters
will not work because "upnp.serviceId" != UPnPService.ID and
"upnp.deviceId" != UPnPDevice.ID. I will commit a patch shortly that
fixes this by replacing all occurrences of mentioned keys in an
EventHandler filter with its UPnP counterpart. That way it should work
again. Would be great if you could test it sometime soon.

> thanks
> francesco

regards,

Karl
-- 
Karl Pauls
karlpauls@gmail.com

Re: Again on the UPnP and Event Admin service

[Francesco Furfari <fr...@isti.cnr.it>]

Karl Pauls wrote:
> Francesco, Stefano,
>
> I spent the last hours coding the filter stuff. It works now and I
> don't think there is anymore I can do. It needs cleaning-up (that's
> for sure :-) and I will do that when I find some time but otherwise I
> consider it done.
great
>
> Some things to ponder:
>
> First, I was right from the start. Your approach with the 1:1 mapping,
> while nice and easy, is to nice, unfortunately. It will not work.
> Apart from the code duplication (and believe me you would end-up with
> a whole EventAdmin) section 113.7.2 of the spec calls it of. The point
> is that asynchronous events must be delivered in the same order to all
> EventHandlers. I cant see how this can be done with the proposed 1:1
> mapping.
>
 remind me to offer a beer next time you come in Italy ;-)

> Second, I'm changing the filter of the UPnPEventListener on demand and
> it turns out that the
> org.apache.felix.upnp.sample.tv.UPnPEventListener doesn't handle
> ServiceEvent.MODIFIED events. I guess this is a bug and needs to be
> fixed in order for the bridge to work correctly with the example (and
> anywhere else for that matter).
>
ya, the UPnP examples are still far to be considered best UPnP/Osgi 
practice :(
I added the missing code to track service.MODIFIED events.
I tested your code and it works fine.
I  used our examples as well as Intel devices , using both "NULL" filter 
and ServiceId based.
I haven't checked all the possible combinations but looking at your code 
it shouldn't be a problem.

What I've realized is that EA subscriptions are limited respect the 
tracking possibilities offered by the UPnP spec.
Initially I suspected it was a bug in your code, using an handler with 
the following filter:
"UPnP.service.type= urn:schemas-upnp-org:service:SwitchPower:1" the 
light switches were not reported.
But this is consequence of the UPnP events type format in which only the 
deviceId and serviceId are considered.
Hence the EA fails to match handlers with such filters.

So while in the UPnP spec the filters can be any combinations of 
deviceId,deviceType,ServiceId and serviceType,
filters used with EventHandler can be only a combination of deviceId, 
and serviceId.

> Finally, keep in mind that it will still be the case that the
> UPnPEventListener is registered with a null argument as soon as there
> is any EventHandler that doesn't specify an
> EventConstants.EVENT_FILTER. That would be needed regardless of any
> approach. The only thing that can be done about it is to tell people
> that this will lead to unnecessary network load that can be avoided if
> they use a filter that targets the devices/services they are really
> interested in.
>
well this is a user decision, in the old implementation it was an 
imposition ;-)

thanks
francesco
>

Re: Again on the UPnP and Event Admin service

[Karl Pauls <ka...@gmail.com>]

Francesco, Stefano,

I spent the last hours coding the filter stuff. It works now and I
don't think there is anymore I can do. It needs cleaning-up (that's
for sure :-) and I will do that when I find some time but otherwise I
consider it done.

Some things to ponder:

First, I was right from the start. Your approach with the 1:1 mapping,
while nice and easy, is to nice, unfortunately. It will not work.
Apart from the code duplication (and believe me you would end-up with
a whole EventAdmin) section 113.7.2 of the spec calls it of. The point
is that asynchronous events must be delivered in the same order to all
EventHandlers. I cant see how this can be done with the proposed 1:1
mapping.

Second, I'm changing the filter of the UPnPEventListener on demand and
it turns out that the
org.apache.felix.upnp.sample.tv.UPnPEventListener doesn't handle
ServiceEvent.MODIFIED events. I guess this is a bug and needs to be
fixed in order for the bridge to work correctly with the example (and
anywhere else for that matter).

Finally, keep in mind that it will still be the case that the
UPnPEventListener is registered with a null argument as soon as there
is any EventHandler that doesn't specify an
EventConstants.EVENT_FILTER. That would be needed regardless of any
approach. The only thing that can be done about it is to tell people
that this will lead to unnecessary network load that can be avoided if
they use a filter that targets the devices/services they are really
interested in.

regards,

Karl

-- 
Karl Pauls
karlpauls@gmail.com

Re: Again on the UPnP and Event Admin service

[Francesco Furfari <fr...@isti.cnr.it>]

Karl Pauls wrote:
> Francesco, you are right. The intention was to make a start - maybe I
> should have made that more clear.
>
ok, I didn't get it .
>> but you are still registering  an UPnPEventListener with a NULL filter
>> thus *all* UPnP devices will start to send upnpEventNotify messages to
>> the Bridge .... the same drawbacks for the network
>
> That is not true in general, because now the UPnPEventListener is
> registered only in case at least one EventAdmin and at least on
> (applicable) EventHandler is present. Granted, once theses conditions
> are met, it is registered with a NULL filter.
>
that's true
>> You could also registering only an instance of UPnPEventListener but you
>> should to update its filter every time a new EventHandler is registered
>> or modified.
>
> That was the ultimate goal. I'm still working on that part.
>
take your time
>> In any case you should always
>> create a new UPnPeventListener if there are subscriber that want to
>> receive events from all the devices ( they would register an handler
>> with NULL filter).
>
> Given the one UPnPEventListener with an ever updating "concatenated"
> filter why would I ever want to register a "new" UPnPEventListener.
> Isn't it sufficient to set the filter to null on the original one
> (whenever at least one EventHandler is interested on all events)?
>
well, effectively if you want to use the same  listener you could clear 
the filter  and save the old one in the case the "NULL" subscriber is 
removed.
You  should anyway update any change in the filters of the other 
handlers or rebuild it when the "NULL" handler is removed.
Using a secondary UPnPListener seems to me more simply ....
>> Following up the previous discussion concerning postEvent or a direct
>> call to  the eventHandle, consider that the UPnP spec already states
>> that the uppnpEventNotify messages must be sent asynchronously so should
>> be enough safe (uhu aha :-) ) to call directly the eventHandle ...
>
> Well, as I mentioned in my reply to Stefano, there is a bit more that
> it would need to do. Specifically, it would need to check that the
> EventHandler has the appropriate permissions to receive the event.
> Useful to know, however, that the UPnPEventListener is  called
> asynchronously already.
>
Ok I trust you because I don't know EA details deeply ;-)  ... thanks 
Stefano too
 
>> ciao
>> francesco
>
> Give me a bit more time to give the "one UPnPEventListener with an
> ever updating concatenating filter" approach a shot. In case that
> won't fix it, I'm open to try different approaches.
>

Some consideration to help you in this concern.
Doing a mapping 1:1 between handlers and listeners is simple and, most 
importantly, you delegate the responsibility about the threading and the 
secure event copy to the event source, namely UPnPDevices and Base 
Driver.  Here the goal is to provide a wrapper of UPnPEventListener to 
EventHandler users.

Doing a n:1 mapping you effectively go to play with EA role and 
potentially you can do some optimizations. But you have to face the 
threading, hence postEvent is obviously the best solution to avoid 
duplication of code, but you fail with the secure event copy because EA 
don't know nothing about UPnP events and there isn't a clear contract 
about mutable properties in the spec :(

regards,
francesco
>

Re: Again on the UPnP and Event Admin service

[Karl Pauls <ka...@gmail.com>]

Francesco, you are right. The intention was to make a start - maybe I
should have made that more clear.

> but you are still registering  an UPnPEventListener with a NULL filter
> thus *all* UPnP devices will start to send upnpEventNotify messages to
> the Bridge .... the same drawbacks for the network

That is not true in general, because now the UPnPEventListener is
registered only in case at least one EventAdmin and at least on
(applicable) EventHandler is present. Granted, once theses conditions
are met, it is registered with a NULL filter.

> You could also registering only an instance of UPnPEventListener but you
> should to update its filter every time a new EventHandler is registered
> or modified.

That was the ultimate goal. I'm still working on that part.

> In any case you should always
> create a new UPnPeventListener if there are subscriber that want to
> receive events from all the devices ( they would register an handler
> with NULL filter).

Given the one UPnPEventListener with an ever updating "concatenated"
filter why would I ever want to register a "new" UPnPEventListener.
Isn't it sufficient to set the filter to null on the original one
(whenever at least one EventHandler is interested on all events)?

> Following up the previous discussion concerning postEvent or a direct
> call to  the eventHandle, consider that the UPnP spec already states
> that the uppnpEventNotify messages must be sent asynchronously so should
> be enough safe (uhu aha :-) ) to call directly the eventHandle ...

Well, as I mentioned in my reply to Stefano, there is a bit more that
it would need to do. Specifically, it would need to check that the
EventHandler has the appropriate permissions to receive the event.
Useful to know, however, that the UPnPEventListener is  called
asynchronously already.

> ciao
> francesco

Give me a bit more time to give the "one UPnPEventListener with an
ever updating concatenating filter" approach a shot. In case that
won't fix it, I'm open to try different approaches.

regards,

Karl

-- 
Karl Pauls
karlpauls@gmail.com

Re: Again on the UPnP and Event Admin service

[Francesco Furfari <fr...@isti.cnr.it>]

Hi Karl,
but you are still registering  an UPnPEventListener with a NULL filter 
thus *all* UPnP devices will start to send upnpEventNotify messages to 
the Bridge .... the same drawbacks for the network
I was suggesting something like this pseudo code:
....
      case ServiceEvent.REGISTERED:  // listener for EventHandler
               new *EventAdminAdaptor*(event.getServiceReference());
               break;
....

public class *EventAdminAdaptor* implements UPnPEventListener {

    public EventAdminAdaptor (ServiceEvent RegisteredEventHandler)
   {
          take the EventHandlerFilter;
          register an UPnPEventListener with the same Filter;
          register a framework listener for any change of the EventHandler;
   }

   public void notifyUPnPEvent(final String deviceId, final String 
serviceId,
        final Dictionary events)
  {
        send postEvent to the EA;
        or alternatively call eventHandle of  a saved m_reference to the 
EventHandler;
  }

   public void serviceChanged(final ServiceEvent event) // listener for 
EventHandler changes
   {
       if service is modified , update the UPnPEventListener filter if 
needed
       if service is unregisterd unregister the UPnPEventListener
   }

} // end EventAdminAdaptor class
  

in this way we pull only the required events ...
You could also registering only an instance of UPnPEventListener but you 
should to update its filter every time a new EventHandler is registered 
or modified. It ease to compose the new filter concatenating them, 
lesser if there are filter modification. In any case you should always  
create a new UPnPeventListener if there are subscriber that want to 
receive events from all the devices ( they would register an handler 
with NULL filter).
A second approach is to use the same UPnPeventListener for all the 
handlers that use the same filter.
(in the class diagram I posted these alternatives are represented by the 
cardinality 0..n / 0..1)

Following up the previous discussion concerning postEvent or a direct 
call to  the eventHandle, consider that the UPnP spec already states 
that the uppnpEventNotify messages must be sent asynchronously so should 
be enough safe (uhu aha :-) ) to call directly the eventHandle ...

ciao
francesco





Karl Pauls wrote:
> Hi Francesco,
>
> I've committed the changes to trunk. Basically, the bridge now tracks
> available EventAdmins and EventHandlers and registers/unregisters an
> UPnPEventListener based on whether there is at least one of both
> present.
>
> regards,
>
> Karl
>

Re: Again on the UPnP and Event Admin service

[Karl Pauls <ka...@gmail.com>]

Hi Francesco,

I've committed the changes to trunk. Basically, the bridge now tracks
available EventAdmins and EventHandlers and registers/unregisters an
UPnPEventListener based on whether there is at least one of both
present.

regards,

Karl

-- 
Karl Pauls
karlpauls@gmail.com

Re: Again on the UPnP and Event Admin service

[Francesco Furfari <fr...@isti.cnr.it>]

mmmm I've made a mistake ... sorry !
Anyway the problem was that the EA spec. states that properties must not 
be mutable, while in the new UPnP spec. the upnp.events property is a 
mutable dictionary. Thus Karl has used in the Bridge the following final 
Dictionary implementation instead of doing a copy.
------------------------------------------------------------------------
                    final Dictionary immutableEvents = new Dictionary(){

                         public int size()
                         {
                             return events.size();
                         }

			.....

                         public Object get(Object arg0)
                         {
                             return events.get(arg0);
                         }

                         public Object put(Object arg0, Object arg1)
                         {
                             throw new IllegalStateException("Event 
Properties may not be changed");
                         }

                         public Object remove(Object arg0)
                         {
                             throw new IllegalStateException("Event 
Properties may not be changed");
                         }

			.....

                     };
--------------------------------------------------------------------

I was wondering if the same approach could be used for the general Event 
class.  But I figured out just now that it is not a correct solution.
In fact a client can always get() a reference of a mutable object and 
modifies its value. :(

so forget the question that I have raised !! sorry again.

francesco



Richard S. Hall wrote:
> Karl Pauls wrote:
>> There are three issues with this. First, I don't think we can provide
>> a different implementation of org.osgi.service.event.Event; It's a
>> given and changing it is out of the question (unless I'm very much
>> mistaken).
> 
> We can provide a different implementation as long as it doesn't change 
> the semantics in such a way that it would violate spec compliance. There 
> are already some classes we provide different implementations for, such 
> as AdminPermission and FrameworkUtil.
> 
> Of course, I cannot say that I totally understand what is at issue here.
> 
> -> richard

Re: Again on the UPnP and Event Admin service

["Richard S. Hall" <he...@ungoverned.org>]

Karl Pauls wrote:
> There are three issues with this. First, I don't think we can provide
> a different implementation of org.osgi.service.event.Event; It's a
> given and changing it is out of the question (unless I'm very much
> mistaken).

We can provide a different implementation as long as it doesn't change 
the semantics in such a way that it would violate spec compliance. There 
are already some classes we provide different implementations for, such 
as AdminPermission and FrameworkUtil.

Of course, I cannot say that I totally understand what is at issue here.

-> richard

Re: Again on the UPnP and Event Admin service

[Karl Pauls <ka...@gmail.com>]

> and what about the org.osgi.service.event.Event class implementation?
> Do you think a different implementation could be useful?
>
> francesco

There are three issues with this. First, I don't think we can provide
a different implementation of org.osgi.service.event.Event; It's a
given and changing it is out of the question (unless I'm very much
mistaken).

Second, I'm not convinced that we need to do anything about it in the
first place. The spec clearly states that event properties must not be
mutable. For me that implies that they should not be mutated by event
receivers too. By this rationality, a receiver that mutates event
properties violates the contract and should be prevented from
receiving events to begin with. It follows that this is a case for
security. In other words, don't use mutable objects as event
properties, if you need to do it (as is it necessary due to the spec
in this case) make sure that untrustworthy bundles don't have the
required permissions to receive this kind of events. Granted, that
implies that security is present - but that is a different story :-)

Third, I don't see that we can come-up with a good solution at all.
Let's face it, Java has some flaws and one of it is arguably that you
can't just "freeze" an Object (as it is possible for example like in
ruby or smalltalk etc.). To make matters worse there is no (build-in)
way to create a proxy dynamically (except for Java Interfaces) and no
really acceptable workaround either (short of byte-code engineering
the heck out of the standard library - doable but questionable).
Furthermore, due to Cloneable not being part of the Object contract
and Serializable neither, a deep-copy is out of the question as well
(in case one could put-up with the semantically differences in the
first place - that is).

In short, I don't think this is the right place to tackle the problem.
Maybe you should raise the question in osgi-dev. The integration of
the EventAdmin with some parts of the spec does appear to be rather
fuzzy around the edges :o)

regards,

Karl

-- 
Karl Pauls
karlpauls@gmail.com

Re: Again on the UPnP and Event Admin service

[Francesco Furfari <fr...@isti.cnr.it>]

ok.

and what about the org.osgi.service.event.Event class implementation?
Do you think a different implementation could be useful?

francesco



Karl Pauls wrote:
>> One last question. I guess the same problems exists with framework'
>> events. If there are many EAs, the subscribers will receive multiple
>> messages.
> 
> It is true that in a scenario where more then one EventAdmin is
> present each individual EventHandler will see the events #EA times.
> 
>> Have you already tackled this situation? Is it the framework that posts
>> the events?
>> otherwise if you are using an adaptor maybe it would be
>> convenient to make it universal and available as separate bundle too.
> 
> No on both accounts. The situation is different here due to the
> adoption of {Framework, Bundle, Service, Log} messages adoption being
> specifically required by the spec (and to be done by the EventAdmin
> too). In other words, notwithstanding future spec improvements, there
> is no other option then either to don't install more then one
> EventAdmin or live with duplicated events.
> 
> The same applies in regard to out-factoring those adaptors to separate
> bundles. The spec requires them to be inside the EventAdmin. I
> wouldn't mind introducing a property for our EventAdmin that can be
> used to turn off adoption for any of the aforementioned events but the
> question is whether it is likely that one ends-up in the situation
> where there is more then one EventAdmin active at any given time in a
> specific framework. I dare to say that this sounds like an unlikely
> situation hence, I'd defer it until we get an actual complaint from
> someone (preferable, together with a convincing use-case) or the spec
> becomes more clear, respectively.
> 
>> francesco
> 
> regards,
> 
> Karl
> 

Re: Again on the UPnP and Event Admin service

[Karl Pauls <ka...@gmail.com>]

> One last question. I guess the same problems exists with framework'
> events. If there are many EAs, the subscribers will receive multiple
> messages.

It is true that in a scenario where more then one EventAdmin is
present each individual EventHandler will see the events #EA times.

> Have you already tackled this situation? Is it the framework that posts
> the events?
> otherwise if you are using an adaptor maybe it would be
> convenient to make it universal and available as separate bundle too.

No on both accounts. The situation is different here due to the
adoption of {Framework, Bundle, Service, Log} messages adoption being
specifically required by the spec (and to be done by the EventAdmin
too). In other words, notwithstanding future spec improvements, there
is no other option then either to don't install more then one
EventAdmin or live with duplicated events.

The same applies in regard to out-factoring those adaptors to separate
bundles. The spec requires them to be inside the EventAdmin. I
wouldn't mind introducing a property for our EventAdmin that can be
used to turn off adoption for any of the aforementioned events but the
question is whether it is likely that one ends-up in the situation
where there is more then one EventAdmin active at any given time in a
specific framework. I dare to say that this sounds like an unlikely
situation hence, I'd defer it until we get an actual complaint from
someone (preferable, together with a convincing use-case) or the spec
becomes more clear, respectively.

> francesco

regards,

Karl

-- 
Karl Pauls
karlpauls@gmail.com

Re: Again on the UPnP and Event Admin service

[Francesco Furfari <fr...@isti.cnr.it>]

One last question. I guess the same problems exists with framework' 
events. If there are many EAs, the subscribers will receive multiple 
messages.
Have you already tackled this situation? Is it the framework that posts 
the events? otherwise if you are using an adaptor maybe it would be 
convenient to make it universal and available as separate bundle too.

francesco


Karl Pauls wrote:
>> Hence the client will receive many copies of the message depending from
>> the number of EA installed.
>>
>> The solution with direct dispatching overcomes this problem.
>> Of course  you could to select just the first EA (switching to the
>> others as soon as it is unisinstalled)   mmmm :)
> 
> I guess the correct way of dealing with this situation is to always
> use the EventAdmin with the highest service ranking. In case this cant
> be done (due to no ranking at all or two services ranked equal) just
> take an arbitrary one and stick with it until it is unregistered (then
> start over).
> 
>> Is not clear to me whether the Felix Bridge is thought as universal
>> bridge (for all the EA implemenations), or every EA service will install
>> its upnp bridge. What do you have in mind?
> 
> For me, the nice aspect about the separate bridge bundle is that it
> really is up to the user (or the management agent or whatever) to make
> that decision. The EventAdmin doesn't install the upnp bridge. It's
> the user hence, we don't need to worry about that. In other words,
> yes, I think it is bound to be a universal bridge.
> 
>> Should even this aspect clarified by the specification?
> 
> Definitely. The hole situation needs to be revisited if you ask me but
> we arrived at that conclusion the last time already :-)
> 
>> francesco.
> 
> o.k., then I'm going to implement the changes sketched-out above
> (i.e., post the event using the EventAdmin ranked highest) and the
> previously discussed approach (to only register an UPnPEventListener
> if needed). Objections anyone?
> 
> regards,
> 
> Karl
> 

Re: Again on the UPnP and Event Admin service

[Karl Pauls <ka...@gmail.com>]

> Hence the client will receive many copies of the message depending from
> the number of EA installed.
>
> The solution with direct dispatching overcomes this problem.
> Of course  you could to select just the first EA (switching to the
> others as soon as it is unisinstalled)   mmmm :)

I guess the correct way of dealing with this situation is to always
use the EventAdmin with the highest service ranking. In case this cant
be done (due to no ranking at all or two services ranked equal) just
take an arbitrary one and stick with it until it is unregistered (then
start over).

> Is not clear to me whether the Felix Bridge is thought as universal
> bridge (for all the EA implemenations), or every EA service will install
> its upnp bridge. What do you have in mind?

For me, the nice aspect about the separate bridge bundle is that it
really is up to the user (or the management agent or whatever) to make
that decision. The EventAdmin doesn't install the upnp bridge. It's
the user hence, we don't need to worry about that. In other words,
yes, I think it is bound to be a universal bridge.

> Should even this aspect clarified by the specification?

Definitely. The hole situation needs to be revisited if you ask me but
we arrived at that conclusion the last time already :-)

> francesco.

o.k., then I'm going to implement the changes sketched-out above
(i.e., post the event using the EventAdmin ranked highest) and the
previously discussed approach (to only register an UPnPEventListener
if needed). Objections anyone?

regards,

Karl

-- 
Karl Pauls
karlpauls@gmail.com

Re: Again on the UPnP and Event Admin service

[Francesco Furfari <fr...@isti.cnr.it>]

There is another problem due to the asymmetry of the EA API, that is the 
subscription is for all the EAs while the publishing is for a specific EA.

The client interested to some UPnP events registers an EventHandler with 
the framework. If we have multiple EA installed, they all monitor the 
handlers and will receive a postEvent Message from the bridge.
In that's way for each UPnP events (UPnPEventNotify) received by the 
Bridge we duplicate the event posting the message to every EA service.
Hence the client will receive many copies of the message depending from 
the number of EA installed.


The solution with direct dispatching overcomes this problem.
Of course  you could to select just the first EA (switching to the 
others as soon as it is unisinstalled)   mmmm :)

 >
 > As you pointed out the EventAdmin approach and the UPnPEventHandler
 > approach are in conflict to some degree (i.e., the network load issue)
 > but that is why we now have aforementioned two level of degradation:
 > don't install the bridge and only bridge in case of interest.


Is not clear to me whether the Felix Bridge is thought as universal 
bridge (for all the EA implemenations), or every EA service will install 
its upnp bridge. What do you have in mind?
Should even this aspect clarified by the specification?

francesco.


Karl Pauls wrote:
>> 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.
> 
> There is no problem with involving the EventAdmin. That is what is in
> the spec and why we created the bridge in the first place.
> 
>> 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.
> 
> True. This clearly is an optimization for this special case namely, to
> ease network load pain.
> 
>> 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.
> 
> Basically, all that it takes is one more ServiceEventHandler. There is
> no noticeable impact whatsoever.
> 
>> 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.
> 
> In my opinion you don't gain anything with this. In fact, quite the
> opposite, your are creating yet another EventAdmin that will have to
> run in parallel with a "normal" one.
> 
> It is true that this wouldn't break the design as such - nevertheless,
> it be a duplication of efforts (both, in terms of runtime and code).
> 
>> 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.
> 
> I understand where you are coming from; it nevertheless stands to
> reason that if someone decided to use the EventAdmin to receive
> UPnPEvents she specifically asks for the EventAdmin semantics.
> Otherwise, she would have used the UPnPEventHandler approach.
> 
> As you pointed out the EventAdmin approach and the UPnPEventHandler
> approach are in conflict to some degree (i.e., the network load issue)
> but that is why we now have aforementioned two level of degradation:
> don't install the bridge and only bridge in case of interest.
> 
>> regards,
>> francesco
> 
> In summary, yes, there is a difference between the EventAdmin approach
> and the UPnPEventHandler approach due to the former assuming a push
> based model while the later apparently targeting a pull based scenario
> in order to ease network load. They don't play along too well together
> but I think with a separate bundle for the bridge plus the bundle only
> registering an UPnPEventHandler in case at least one EventAdmin and at
> least one interested EventHandler is present we should have our bases
> covered.
> 
> regards,
> 
> Karl

Re: Again on the UPnP and Event Admin service

[Francesco Furfari <fr...@isti.cnr.it>]

ya, its right. UPnP eventing is a pull based scenario, but I'm not sure 
it is correct to say that EA is push based. It depends from who 
initiates the communication process ... publish-subscribe perhaps is the 
right definition for EA, and I agree they don't play very well together :(

francesco

> In summary, yes, there is a difference between the EventAdmin approach
> and the UPnPEventHandler approach due to the former assuming a push
> based model while the later apparently targeting a pull based scenario
> in order to ease network load. They don't play along too well together
> but I think with a separate bundle for the bridge plus the bundle only
> registering an UPnPEventHandler in case at least one EventAdmin and at
> least one interested EventHandler is present we should have our bases
> covered.
> 
> regards,
> 
> Karl

Re: Again on the UPnP and Event Admin service

[Karl Pauls <ka...@gmail.com>]

> 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.

There is no problem with involving the EventAdmin. That is what is in
the spec and why we created the bridge in the first place.

> 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.

True. This clearly is an optimization for this special case namely, to
ease network load pain.

> 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.

Basically, all that it takes is one more ServiceEventHandler. There is
no noticeable impact whatsoever.

> 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.

In my opinion you don't gain anything with this. In fact, quite the
opposite, your are creating yet another EventAdmin that will have to
run in parallel with a "normal" one.

It is true that this wouldn't break the design as such - nevertheless,
it be a duplication of efforts (both, in terms of runtime and code).

> 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.

I understand where you are coming from; it nevertheless stands to
reason that if someone decided to use the EventAdmin to receive
UPnPEvents she specifically asks for the EventAdmin semantics.
Otherwise, she would have used the UPnPEventHandler approach.

As you pointed out the EventAdmin approach and the UPnPEventHandler
approach are in conflict to some degree (i.e., the network load issue)
but that is why we now have aforementioned two level of degradation:
don't install the bridge and only bridge in case of interest.

> regards,
> francesco

In summary, yes, there is a difference between the EventAdmin approach
and the UPnPEventHandler approach due to the former assuming a push
based model while the later apparently targeting a pull based scenario
in order to ease network load. They don't play along too well together
but I think with a separate bundle for the bridge plus the bundle only
registering an UPnPEventHandler in case at least one EventAdmin and at
least one interested EventHandler is present we should have our bases
covered.

regards,

Karl
-- 
Karl Pauls
karlpauls@gmail.com

Re: Again on the UPnP and Event Admin service

[Francesco Furfari <fr...@isti.cnr.it>]

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.

regards,
francesco




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 <fr...@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
>>
>>
>>
>>
>>
>>
>>
>>
> 
> 

Re: Again on the UPnP and Event Admin service

[Karl Pauls <ka...@gmail.com>]

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 <fr...@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
>
>
>
>
>
>
>
>


-- 
Karl Pauls
karlpauls@gmail.com

Re: Again on the UPnP and Event Admin service

[Francesco Furfari <fr...@isti.cnr.it>]

the mailer system has blocked the image.
take a look at 
http://issues.apache.org/jira/secure/attachment/12335667/EventAdminBridge.JPG

francesco


Francesco Furfari 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
> 
> 
> 
> 
> 
>