Category: SOA/Web/Etc.

In SOA application modeling there are two basic approaches, end-to-end and hop-by-hop. The end-to-end model is based on an originating sender, a series of intermediaries and a final destination. In the hop-by-hop model each service only knows about the next hop service and nothing more. Below I argue that the end-to-end model inevitably leads to having to create a single protocol that the whole world has to support, requires a painfully sophisticated security model and all but requires that services be tightly coupled. The hop-by-hop model, on the other hand, suffers from none of these problems but does introduce extra latency. On balance I don't believe the benefits of the end-to-end model justify its costs and therefore recommend that service implementers use the hop-by-hop model.

Continue reading SOA and the End-To-End Morass

Authentication is often seen as a cheap and easy security solution but it is anything but. Authentication is a significant threat to re-use and it can cause a false sense of security that leaves services open to real threats. But when authentication is called for there are outstanding, well proven solutions that are almost certainly already in your data center – HTTP Digest and SSL. As I argue below, they are the right technologies for just about all your authentication needs.

Continue reading SOA Security: Authentication – What it really costs and what
most folks really need

SOAR-ity is intended to allow for "reliable" (this term is almost always a misnomer) messaging over HTTP. It achieves this goal by introducing two new request headers, MID which provides a unique ID for a message and MsgCreate which contains the date and time on which the first instance of the message with the associated MID was sent. The purpose of the MID/MsgCreate pair is to allow any HTTP request (e.g. any HTTP method can be used) to be repeated multiple times with a guarantee that the message will be processed no more than one time. In essence it makes any HTTP method call idempotent.

The SOA-Rity specification is now available as an Internet Draft. Below I provide links to different versions of the draft that are hosted locally so as to ensure accessibility if the draft should expire.:

• a text version,
• a HTML version,
• the XML source – I used XML2RFC to generate the text and Julian's XSLT translator for the HTML version and

• the DTD – I made the organization element optional under author element to get rid of validation errors

I'd also like to take this opportunity to say that the Oxygen editor ROCKS! Make sure to check out their 'academic licenses' which are actually just for personal use in case you can't justify buying Oxygen for your job.

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.

Continue reading What is SOA? What isn't SOA?

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?

Continue reading 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.

Continue reading Enterprise SOA Priorities

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?

Continue reading Designing Service Oriented Architecture (SOA): Latency &
Re-Use, what you must get right and what you can afford to get
wrong

WS-CDL is in my opinion an example of premature standardization. WS-CDL provides multiple layers of abstraction, an enormous set of features and a simulation based design. Personally I think a purely declarative approach with little or no abstraction that focuses on making it easy to describe basic stuff would have been better. I don't know which position, mine or WS-CDL's, or which mid-point between the positions is right but I'm pretty sure that no one else does either. We just don't have enough industry experience to standardize choreography descriptions. Unfortunately the potential standardization of WS-CDL can do real harm as it will likely freeze the experimentation and learning that the industry so badly needs.

Continue reading Web Services Choreography Description Language (WS-CDL)