Comments on: Those Leaky Networks http://eclipsesource.com/blogs/2009/05/06/those-leaky-networks/ Eclipse Equinox OSGi Wed, 16 May 2012 08:22:45 +0000 hourly 1 http://wordpress.org/?v=3.3.2 By: Scott Lewis http://eclipsesource.com/blogs/2009/05/06/those-leaky-networks/comment-page-1/#comment-1509 Scott Lewis Thu, 07 May 2009 04:55:47 +0000 http://eclipsesource.com/blogs/?p=1423#comment-1509 Adrian...RE: Spring DM...I would imagine that it could be used to implement RFC 119...although I don't know Spring DM well enough to say for sure. RE: your points about OSGi's dynamic environment support...yes, OSGi's support for dynamic services is, I believe, helpful in dealing with network 'leakyness'. But, I don't believe that it actually makes remoting completely solid/non-leaky. I say this because even dynamic service arrival/departure doesn't actually capture/totally hide points 1 and 2. Yes, some version of network induced problems like 1 and 2 can be mapped to service departure, but I don't think service departure is an perfect abstraction for (e.g.) network-induced blocking (or widely varying timing/performance issues) in RPC. My $0.02. RE: dependency management...no, not as part of the ECF/RFC119 work. I am using DS in other work contexts though, and I find it very helpful/useful for local service dependency mgmt. I've not yet come to any conclusions about remote service mgmt as I haven't played around with it enough. Adrian…RE: Spring DM…I would imagine that it could be used to implement RFC 119…although I don’t know Spring DM well enough to say for sure. RE: your points about OSGi’s dynamic environment support…yes, OSGi’s support for dynamic services is, I believe, helpful in dealing with network ‘leakyness’. But, I don’t believe that it actually makes remoting completely solid/non-leaky. I say this because even dynamic service arrival/departure doesn’t actually capture/totally hide points 1 and 2. Yes, some version of network induced problems like 1 and 2 can be mapped to service departure, but I don’t think service departure is an perfect abstraction for (e.g.) network-induced blocking (or widely varying timing/performance issues) in RPC. My $0.02.

RE: dependency management…no, not as part of the ECF/RFC119 work. I am using DS in other work contexts though, and I find it very helpful/useful for local service dependency mgmt. I’ve not yet come to any conclusions about remote service mgmt as I haven’t played around with it enough.

]]> By: Adrian Sampaleanu http://eclipsesource.com/blogs/2009/05/06/those-leaky-networks/comment-page-1/#comment-1508 Adrian Sampaleanu Thu, 07 May 2009 04:23:39 +0000 http://eclipsesource.com/blogs/?p=1423#comment-1508 Scott, When developing for OSGi with an abstraction layer such as Spring DM (and others), your points 1 and 2 apply even to local services due to the indirection implied by the proxying involved and the dynamic nature of the environment. So, I suppose that when properly handling the lifecycle events in an OSGi environment wrt dependencies, the differences between local and remote services are not so great. I'm curious if Spring DM's type of abstraction (which to a large degree will be part of the 4.2 spec) could not be extended to provide the transparent layer that you say you've implemented. Are you, in fact, using spec compliant dependency management? Thanks for any insight, Adrian Scott,

When developing for OSGi with an abstraction layer such as Spring DM (and others), your points 1 and 2 apply even to local services due to the indirection implied by the proxying involved and the dynamic nature of the environment. So, I suppose that when properly handling the lifecycle events in an OSGi environment wrt dependencies, the differences between local and remote services are not so great. I’m curious if Spring DM’s type of abstraction (which to a large degree will be part of the 4.2 spec) could not be extended to provide the transparent layer that you say you’ve implemented. Are you, in fact, using spec compliant dependency management?

Thanks for any insight,
Adrian

]]>