All valid points, Christian. In the current system I'm working on services are more often local than remote, so we opt for classic multi-method interfaces everywhere. For the stateless part we then allow ourselves to partition some work to remote services. I can definitely envision using a design where all services (even local ones) have a messaging interface and a message queue, f ex when using Actor-based designs (Akka and friends). Then JMS could be used to handle the remote queues. Best regards Mike Christian Schneider wrote:
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 an asynchronous 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
