Distributed OSGi/Network Service Discovery

[Dieter Wimberger]

Hi all,

I have been reading a bit about the distributed OSGi efforts, and I  
wondered about two things:

1) Isn't network service discovery an essential element?
(With network service discovery, I am talking about what's done  
through protocols like SLP, mDNS etc.)

2) Is there any effort to standardize such service discovery services  
into an OSGi service specification?
i.e. property based network service discovery service independent of  
the actual protocol that is used?

I personally think it does make sense to have such an abstraction,  
because it could shield bundles from protocol details and the actual  
implementation that is being used at a specific site.

Any feedback is welcome.

Regards,
Dieter

[Marcel Offermans]

Hello Dieter,

On Jun 28, 2008, at 2:09 , Dieter Wimberger wrote:

> I have been reading a bit about the distributed OSGi efforts, and I  
> wondered about two things:
>
> 1) Isn't network service discovery an essential element?
> (With network service discovery, I am talking about what's done  
> through protocols like SLP, mDNS etc.)

It is.

> 2) Is there any effort to standardize such service discovery  
> services into an OSGi service specification?
> i.e. property based network service discovery service independent of  
> the actual protocol that is used?

Such an effort is indeed underway for quite some time now.

> I personally think it does make sense to have such an abstraction,  
> because it could shield bundles from protocol details and the actual  
> implementation that is being used at a specific site.

Me too, doing distributed OSGi is not rocket science in the sense that  
there are not that many different ways to do it, but standardization  
helps a lot to prevent slightly incompatible solutions here.

If you want to learn a bit more about it, check out the following links:

  - http://blogs.iona.com/newcomer/archives/000569.html
  - http://www.osgi.org/wiki/uploads/CommunityEvent2008/21_RemoteServices_OSGi_CommEvent08.pdf
  - http://www.eweek.com/c/a/Application-Development/Distributed-OSGi-Effort-Progresses/

Those should give you an idea of what the upcoming spec will contain.  
Especially the Iona blog is worth reading because they are part of the  
expert group. I talked to them in Berlin and it seems they are ironing  
out the final details.

Greetings, Marcel

[Craig Phillips-2]

Hi,
 
I've been looking in to Newton... Some one put a lot of work into it..

________________________________

From: Marcel Offermans [mailto:marcel.offermans@...]
Sent: Sat 6/28/2008 5:47 AM
To: dev@...
Subject: Re: Distributed OSGi/Network Service Discovery



Hello Dieter,

On Jun 28, 2008, at 2:09 , Dieter Wimberger wrote:

> I have been reading a bit about the distributed OSGi efforts, and I
> wondered about two things:
>
> 1) Isn't network service discovery an essential element?
> (With network service discovery, I am talking about what's done
> through protocols like SLP, mDNS etc.)

It is.

> 2) Is there any effort to standardize such service discovery
> services into an OSGi service specification?
> i.e. property based network service discovery service independent of
> the actual protocol that is used?

Such an effort is indeed underway for quite some time now.

> I personally think it does make sense to have such an abstraction,
> because it could shield bundles from protocol details and the actual
> implementation that is being used at a specific site.

Me too, doing distributed OSGi is not rocket science in the sense that
there are not that many different ways to do it, but standardization
helps a lot to prevent slightly incompatible solutions here.

If you want to learn a bit more about it, check out the following links:

  - http://blogs.iona.com/newcomer/archives/000569.html
  - http://www.osgi.org/wiki/uploads/CommunityEvent2008/21_RemoteServices_OSGi_CommEvent08.pdf
  - http://www.eweek.com/c/a/Application-Development/Distributed-OSGi-Effort-Progresses/

Those should give you an idea of what the upcoming spec will contain.
Especially the Iona blog is worth reading because they are part of the
expert group. I talked to them in Berlin and it seems they are ironing
out the final details.

Greetings, Marcel

[Didier Donsez]

Craig Phillips wrote:

>Hi,
>
>I've been looking in to Newton... Some one put a lot of work into it..
>
>  
>
Dieter

My sandbox hosts a bundle providing a service and a shell command to
publish and retrieve references with http://jmdns.sourceforge.net/.
http://svn.apache.org/repos/asf/felix/sandbox/donsez/mdns/src/site/index.html

Karl and Rick have done some work with mDNS too

    * Karl Pauls and Richard S. Hall, /Eureka - A Resource Discovery
      Service for Component Deployment/,
      http://www.inf.fu-berlin.de/inst/ag-ss/papers/eureka_cd_20040520.sxw.pdf


André Bottaro
(http://pagesperso-orange.fr/andre.bottaro/publications.html) is
preparing his PhD thesis on "distributed OSGi".

Kind regards
Didier

Remark: UPnP Base Driver provides a mean to publish and discover
OSGi-based UPnP services in an adhoc network

>________________________________
>
>From: Marcel Offermans [mailto:marcel.offermans@...]
>Sent: Sat 6/28/2008 5:47 AM
>To: dev@...
>Subject: Re: Distributed OSGi/Network Service Discovery
>
>
>
>Hello Dieter,
>
>On Jun 28, 2008, at 2:09 , Dieter Wimberger wrote:
>
>  
>
>>I have been reading a bit about the distributed OSGi efforts, and I
>>wondered about two things:
>>
>>1) Isn't network service discovery an essential element?
>>(With network service discovery, I am talking about what's done
>>through protocols like SLP, mDNS etc.)
>>    
>>
>
>It is.
>
>  
>
>>2) Is there any effort to standardize such service discovery
>>services into an OSGi service specification?
>>i.e. property based network service discovery service independent of
>>the actual protocol that is used?
>>    
>>
>
>Such an effort is indeed underway for quite some time now.
>
>  
>
>>I personally think it does make sense to have such an abstraction,
>>because it could shield bundles from protocol details and the actual
>>implementation that is being used at a specific site.
>>    
>>
>
>Me too, doing distributed OSGi is not rocket science in the sense that
>there are not that many different ways to do it, but standardization
>helps a lot to prevent slightly incompatible solutions here.
>
>If you want to learn a bit more about it, check out the following links:
>
>  - http://blogs.iona.com/newcomer/archives/000569.html
>  - http://www.osgi.org/wiki/uploads/CommunityEvent2008/21_RemoteServices_OSGi_CommEvent08.pdf
>  - http://www.eweek.com/c/a/Application-Development/Distributed-OSGi-Effort-Progresses/
>
>Those should give you an idea of what the upcoming spec will contain.
>Especially the Iona blog is worth reading because they are part of the
>expert group. I talked to them in Berlin and it seems they are ironing
>out the final details.
>
>Greetings, Marcel
>
>
>
>  
>

--
--------------------------------------------------------------
Didier DONSEZ

Laboratoire LIG, Equipe ADELE
Universite Joseph Fourier
Bat. C, 220 rue de la Chimie, Domaine Universitaire
BP 53, 38041 Grenoble Cedex 9, France
Tel : [phone]           Fax : [phone]
GPS : lat 45°11'38.3"N, lon 05°46'14.7"E, alt 223m

mailto:Didier.Donsez@...
URL: http://www-adele.imag.fr/users/Didier.Donsez
Map: http://www-adele.imag.fr/users/Didier.Donsez/map/map.html
--------------------------------------------------------------

[Dieter Wimberger]

Hi all:

Thanks for the answers.

I have been working on the isolated problem of Network Service  
Discovery and what happened is that I went from
jmdns to jslp and then I decided to write my own.

However, in doing so, I realized that if I bound my code to a specific  
API, I had to rewrite it everytime I changed to another
protocol package.

The two solutions I came up with were basically:
1) to have a protocol agnostic API that defines network service  
discovery (for a properties based lookup)
[moderate coupling]
2) to have a mechanism that uses a single interface (as type) and the  
service registry, and adds or removes the references with properties  
at the SD protocol level.
[very loose coupling]

A pro of 1 is that there is a clear specification and it could be  
easier to ensure constraints on properties (i.e. because of the OO  
model approach).
It could actually be combined with 2 using a glue bundle. A con of 1  
is that you need an API that is flexible and generic enough to cover  
what may be out there in SD protocols (i.e. needs to be a good  
abstraction).

A pro of 2 is the loose coupling, but it could be also seen as con, if  
the only specification is about the registration of certain properties  
(with implicit constraints).

Hopefully this makes sense, my intention was to get some feedback and  
thoughts on the topic.

I have actually tried to model 1 (and implement it), so if you are  
interested in the details, I have dropped the API here:
http://www.karanet.at/~wimpi/sd-api/
I think it should be flexible enough to allow for example  
implementations that are based on jmdns and jslp.

Marcel:
I have read those references, but I think that service discovery alone  
is kind of a foundation for what they are proposing when it comes to  
distributed OSGi (also, I think that it's valid by itself, sometimes  
you just need some auto-configuration or want to bind in heterogenous  
components; i.e. such that aren't implemented in OSGi or Java at all).

Craig:
I have checked out Newton; I think it is also larger scale.

Didier:
Maybe my description above makes a better point about what I was  
trying to discuss. Logically, a valid point of view would be to go for  
mDNS as a standard and that's it.

Regards,
Dieter