karaf-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Lewis <sle...@composent.com>
Subject Re: Opinionated...
Date Sat, 14 Jan 2017 16:14:20 GMT
On 1/14/2017 5:19 AM, Brad Johnson wrote:
> Scott,
> It’s funny that you mention OSGi Remote Services as that was sort of 
> in the back of my mind.   I think I recall Christian said he was 
> working on a Remote Services implementation as well. But I don’t know 
> enough about it yet to include it in the discussion.  I suspect what 
> I’m going to do is set up a GitHub project with a basic project and 
> then a set of appliances for a variety of enterprise integration 
> purposes.  That baseline has to be in place before lower levels can be 
> addressed
> But I do think that a communications abstraction is going to be 
> necessary.  A next generation of communications pipes should abstract 
> protocols away from the OSGi programmer. Or as the great and powerful 
> Oz put it “never mind the little man behind the curtain”.

I don't think Remote Services would be accurately characterized as 
attempting to make networking transparent.   The spec does go to some 
trouble to provide standardized meta-data about a service to allow 
service implementers to characterize the service for consumers...i.e. in 
terms of it's network characteristics (e.g. whether it's a remote 
service or local service to begin with).

In any event, although I would argue that rpc is not the only 
communications abstraction, it is a useful and common one...and 
re-building a service n times with different transport implementations 
doesn't seem to me like a good way to go either.

WRT Camel, it could (and probably should) be used to implement a remote 
services distribution provider.   It would be a simple matter to do so.


View raw message