On 7/30/2015 10:25 AM, Wim Jongman
wrote:
Yes that is interesting.
For my $0.03: I've never believed in a 'one-size fit all' approach
to distribution systems and rpc. As stated in the article, it is
perhaps impossible to have a single transport/distribution system
meet *all* requirements, whether functional (contract) or
non-functional (e.g. performance and security).
That is one reason I like ECF's approach of implementing a
standardized RPC (aka OSGi Remote Services/RSA), via open APIs that
allow multiple distribution systems to be easily used, extended, or
replaced entirely...at the level of each individual service. This
also allows the option of doing design, development, testing of
remote services on one transport, and using some other
transport/distribution system for deployment. I believe this can
make integration much easier and flexible, while maintaining clear,
versionable contracts (the service API and types) between service
providers and service consumers.
Of course, particularly given their ubiquity RESTful approaches are
ideal for many situations [1], so I guess I disagree with the author
somewhat, but my belief is he's trying to make the 'one size doesn't
fit all' argument as strongly as possible.
Actually, I feel that he didn't mention a couple of other areas of
potential weakness for RESTful approaches...e.g. the dynamics
support inherent in networked/unreliable service (such dynamics are
in OSGi remote services), and he does mention versioning (which is
also very nicely handled by OSGi remote services/RSA) in the
'Backward Compatibility' section. Versioning is something that I
believe justifies Remote Services over REST [1], by itself.
Like the author, it's also my view that Remote Services are not the
'whole story' of inter-process communication. There's also async
one-way, queue, multipoint/process group models, events, etc....e.g.
[2]. In any event :-), indeed an interesting article, thanks.
Scott
[1]
https://wiki.eclipse.org/Tutorial:_Creating_a_RESTful_Remote_Service_Provider
[2] https://wiki.eclipse.org/Distributed_EventAdmin_Service
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ecf-dev
|