Remoting works fine with messaging but messaging shines most in regard
to one way calls. The problem is that once you do one way then the
method of a remote call is more problem than a feature.
For example if you have 5 methods in a service and route all of them
through the same queue then you have very different data on that queue.
So after limiting yourself to oneway the next step is often that it
would be better to also limit yourself to just have one kind of data on
one queue. For remoting this means having only one method per interface.
Btw. one method also makes versioning of your service vastly easier.
So now that you have reduced remoting to one way and one method there is
no more need for a method.. and in loose coupling the method name is
pointless for your counterpart anyway.
So when thinking messaging to the end you end up with the need to
sending specified data over a channel. For this case though remoting
just is a bad match and pure eventing is a lot simpler.
There is also one other thing that (today) really speaks against
messaging. The lack of good tools. Once you do loosely coupled messaging
you start to need good monitoring and management tools. You want to be
able to have a good overview what happens on your system landscape.
Unfortunately there are almost no good tools for this case. Just today I
talked to an integration developer who mentioned they replaced a
messaging queue with a database table because they have good tools
(normal db tools) to manage the table containing the queueing data. In
fact communicating over db tables is still the most prominent way of
asynchronous communication in many companies. I would really like to see
more eventing using messaging but the tooling is a big factor delaying
this switch in architecture.
Christian
On 12.03.2014 00:29, Mike Wilson wrote:
I agree with you Christian, and I've been quite surprised not really
finding any OSGi remoting projects or libraries that integrate with
messaging/JMS. It's strange because messaging is a one-stop
solution providing anasynchronous model, load-balancing, and
configuration to discover remote servers.
Or is there a good reason for this, and messaging is not a good fit
with OSGi service remoting?
Best regards
Mike
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
