At the Austin Architect Council, Ron Jacobs spoke about an SOA pattern that hit home: The Document Processor. Here is how he described it:
Think back to before computers ran everything. Units of work (like a work order) were represented by a business form. These documents normally had several carbon copies. After the form was completed, copies were sent to different departments. If it was a work order, perhaps the maintenance department received the document. Receipt of the document kicked off the task, and the work got done. Ron says that this is how service interfaces should operate. The schema (message) should consist of the entire business document. In this way, the service's implementation is hidden (such as what database is used). With the business document as the message, the service can be easy to consume from any platform, and one call can represent a single unit of work.
In this way, a communication failure doesn't leave the service in an incomplete state. Does this mean that you can't do transacted services???? YES!!! If you need transactions, then stop looking at SOA to solve that problem.
The benefit of the Document Processor pattern is that client developer only have to think about sending a document.