So my guess is that one can design a really nice exactly once reliable messaging protocol using exactly two headers (a message ID and a time stamp) along with a few standard error responses. For bonus points I can throw in a header giving an idea of how long the system remembers message IDs. Below I explain how I reached the conclusion that this is all that's needed.
Continue reading How Should An Exactly Once SOA Reliable Messaging System Be
Designed?
I believe that there is a real need for an 'exactly once' reliable messaging protocol in SOA but that the other forms of reliable messaging (e.g. at most once, at least once and ordered) do not make it into the 80% column so we shouldn't bother with them, at least in the standards world.
Continue reading Does SOA Need A Reliable Messaging Protocol?
Yaron's Definition of Service Oriented Architecture (SOA): Networked code is good. The rest, as they say, is just commentary.
When re-using someone else's service it's nice to know if that service is actually still running. Thankfully whole armies of people are out boiling the world's oceans to come up with mind boggling sophisticated systems to solve this difficult problem. But until all the water has boiled off and their universe saving contraptions are available might I suggest a simpler interim approach? Why not use SOA-Ping?
In thinking about the management challenges of utility computing (how do you manage 10,000 virtual machines anyway?) it was obvious that the right high level abstraction for management is the composite application. A composite application represents the collection of services (ala SOA) that are being brought together to perform some action. This then got me thinking about SOA in general and has led to a new project I'm working on in parallel to the utility computing work called SOA Lifecycle (SOAL). But, as with my utility computing priorities article, I like to know what my priorities are before I dive into a project. So below I explore what I believe the priorities are for SOA in the enterprise.
I really like iTunes. In general it is easy to use. Unfortunately it does have some short comings and my experience with Magnatune showed some of them. Specifically, iTunes handles m3u play lists badly and it can't handle FLAC files. But thankfully there are somewhat reasonable work arounds.
O.k., it's pet peeve time. Otherwise intelligent people seem to get really confused whenever they hear "two phase commit". They immediately assume that if one is using two phase commits then one must be implementing an ACID or at least Atomic transaction. Nonsense! A two phase commit is nothing more than a coordination mechanism. It allows one to guarantee that a group of independent systems will either all perform or all not perform a particular action. Historically the 'action' was usually some kind of ACID or at least Atomic transaction. But there is nothing in two phase commits that requires or even implies any particular action, atomic, ACID or otherwise.