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