Service-oriented architecture within an application

Ted Neward: "I submit to you that, as a simple measure, SOA == components + context-complete communication. Whether your services are in-proc or out-, the key is to understand the boundaries you wish to define and enforce."

Don Box likes to talk about four key tenets of SOA: explicit boundaries, autonomy of services, share schema not class and policy-based compatibility. To me, the boundary issue is the least interesting for in-process services -- from this point of view, in-process services look very similar to boring old components. But I am interested in what the SOAP style of messaging brings in terms of policy-based compatibility.

Let's recap. Services interact by sending messages. In the Smalltalk world, objects (components) also interact by sending so-called messages, but these "messages" are quite limited compared to SOAP and pretty much come down to method calls. In the .NET and Java worlds, components do interact using method calls: these can get translated into messages along the way, but actually using that messaging layer is a bit of a black art, and the callee still ends up receiving it as a plain old a method call. So in practice in-process messaging consists only of a method and a payload of arguments: effectively, the SOAP body.

In SOAP services, however, messages are much richer, with headers defining policies and demands that must be processed before the server can even look at the "method call" payload. Is there value in extending this behaviour to components?

I guess that depends on what sort of policies we can envisage affecting component compatibility. In the wild world of the network, issues like reliable delivery and security are obviously very important because the service is out there in some ill-understood cloud. Within a process, these policies seem rather redundant. What is the point of signing messages that are travelling only within your own memory space? Isn't reliable delivery a given within a process?

And yet compatibility clearly is an issue in the component world. Components can and do want to have guarantees of their peers' capabilities and behaviour. Perhaps, at a simple level, this is just proxy information for service policies -- for example, if a caller demands reliable delivery, the callee can bounce that request immediately because it knows it will not be demanding reliable delivery from the service to which it forwards messages.

I have to admit that I am struggling to come up with any truly compelling case for using header-plus-body messaging within a process as opposed to traditional body-only messaging. But it does seem to me that this is an avenue which bears investigation.