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.
In designing a SOA based system I believe the number one concern should be latency. As I discuss in my article on RPCs and Protocols, getting latency right is extraordinarily hard. So my advice to people designing SOA systems is – worry about latency. If you manage to get past latency then you can spare a thought for re-use, this is where loose coupling and versioning come in. But in my opinion most people can safely ignore both issues. After all, even if you try to tackle them you're likely to get it wrong (and no, that's not an insult, the 'experts' who design nothing but protocols and protocol implementations screw it up all the time) so why waste time and energy when you could be focused on shipping your service?
And now, dear readers, I ask a favor. I have a PC (for work) and a Mac (for life) in my home and they share the same keyboard, mouse and monitor. I have an old PS/2 KVM box that works really well so when I bought the Mac I wanted to hook it in to the KVM. The problem is that the Mac only uses USB peripherals. So I made the mistake of buying the Y-Mouse, an adapter that converts PS/2 connections into USB connections. As I explain here, the Y-Mouse does not work very well for me. So what I'd really like to do is buy a USB KVM. I actually don't care about the "M" (e.g. Monitor) part, I have a HP 2335 and use its built in monitor switch (which guarantees me the absolute best image possible). So what I really need is a USB Keyboard/Mouse switch.
I did some research and all I could find were complaints about USB KVMs, the main issue being switching time. It seems that switching between machines can take several seconds. Does anyone know of a good quality USB KVM that can switch really fast? If so please drop a comment on this article. Thanks!
N.B. I am aware of Synergy. But Synergy has never worked very well on Mac's and my PC is actually running a VPN which ends up meaning that the keyboard and mouse commands would have to be routed over the open Internet, this is both a security and a performance nightmare.
One of the reasons I bought a Mac for myself and my wife is that I could never get printer sharing working between Linux and Windows. I figured if Marina and I both had Macs then the problem would be solved. Unfortunately, I was wrong. While Apple has mostly embraced Bonjour technology there is still one major area that is left out – Apple's Printer Server (e.g. the open source CUPS) which uses its own multicast based discovery solution. When I hooked my USB printer to my OS X box and turned on printer sharing I couldn't get my wife's Mac to see the printer! The problem turned out to be that both my wife and I's computers have unique IP addresses that we get from our ISP's DHCP server. Unfortunately the ISP's DHCP server gave us addresses in different subnets! CUPS default configuration does not allow printer sharing between machines that are not on the same subnet. The CUPS configuration can be overridden fairly trivially but I don't want to because it would either mean hard coding in my wife's IP address (which changes) or allowing the whole world to print on my printer (which I'd rather not). Thankfully there was a really trivial solution to the problem that was pointed out to me by Stuart Cheshire, the father of Bonjour.
Continue reading Sharing Printers Between OS X Boxes in a Screwed Up Local
Network