Stuff Yaron Finds Interesting

The Enterprise SOA vision is all about composite applications. These are applications formed out of numerous independent web services all working together to provide some greater functionality. Except, how exactly do you define how 20 or 30 loosely coupled services interact to form a composite application? How do you deploy 20 or 30 services written in 20 or 30 languages for 20 or 30 different platforms in a sane way? And if you do manage to actually design and deploy the beast, how do you monitor it? The tools needed to make SOA work in the real world mostly don't exist yet. That's o.k. though because most Enterprises are just taking their first baby steps down the road to SOA. So we have a little time to get our act together. This article lays out a vision for how an architecture that will allow enterprises to maximize SOA's benefits.

Continue reading SOA Lifecycle (SOAL) – How to Make SOA Work In the
Enterprise

In a previous article I had argued that the end-to-end model was a bad one for SOA. In comments on that article Nick Gall made the point that I was using the term end-to-end incorrectly. I countered that the meaning of the term was different for application protocols than for transport protocols (where Nick's usage came from). Below I explain how HTTP's violation of the 'end-to-end principle' sent application protocols on a path where the very idea of 'end-to-end' changed with unfortunate consequences for SOA.

Continue reading End-To-End Confusion – The Changing Meaning of End-To-End in Transport and Application Protocols

In this article I first look at the use cases for encryption in SOA and explore three scenarios: hop-by-hop, end-to-end and beyond messaging. I conclude that most folks just need hop-by-hop messaging, specifically SSL. I then look at issues relating to encrypting messages outside of the enterprise and conclude that most services probably don't need encryption but they'll use it anyway so to reduce harm they should at least use SSL enabled proxies in order to make the unencrypted messages available within the corporate network. I then look at using encryption within the enterprise and strongly caution most companies to avoid it if at all possible. The bottom line is that SSL is enough for almost everything, GPG cleans up the rest and XML Encryption and the WS-Security framework are almost certainly more trouble than they are worth.

Continue reading SOA Security – Encryption

In this article I explain why (in my non-qualified opinion as a non-lawyer) I think most people are wasting their time when they worry about non-repudiation of SOA messages.

Continue reading SOA Security – The Myth of Non-Repudiation

In my search for how real people are implementing SOA I just about never see SOAP, and WSDL seems unheard of. But when I point this out I inevitably get yelled at and told SOAP and WSDL are used all the time. Which is true, but misses the point. Because what SOAP and WSDL are generally being used for is not SOA but rather RPC, specifically RPC-Encoded. Of course RPC is the text book definition of "Not SOA". So I tip my hat to Web Service's major success – as Not SOA.

Continue reading Web Services, SOA and RPC Encoded – the Exception that Proves
the Rule

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.