in the few days i've spent back at work since my holiday, i've had occasion to think a bit about soa. there's nothing revolutionary here, just my observations as i really get to grips with what everyone's talking about.

here's a verbose working definition of soa dumped straight from my own head (warning: not suitable for use as a learning aid): the compartmentalisation of enterprise application groups into individual applications that communicate using a limited, documented message set where each message corresponds to idempotent operations, and in which no physical transaction boundary spans an SOA application boundary.

by compartmentalising, we assign ownership of (that is, responsibility for and authority over) business data and business processes to specific applications.

by avoiding physical transactions boundaries which span SOA applications, we avoid the issues (e.g. deadlock, performance) associated with distributed transactions.

by only exposing messages which trigger idempotent operations, we allow client (message sending) applications the freedom to re-send a message to re-trigger an application in the event that confirmation of operation completion is never received, safe in the knowledge that even if the original operation WAS performed, the second operation will not result in an invalid transformation of the data model (e.g. a non-idempotent create would, if performed twice, create two records. an idempotent create would detect the second create attempt and not create the second row. this can be implemented by using sequence numbers.)

by documenting the message set, a server application (receiver of messages) goes part way to documenting the interface which it commits to providing. "part way" because the interface consists of more than just the message set; the transport, protocol, etc., as well as the consequences of processing each message type, form part of the contract. "contract first" fanatics tend to over-focus on the message format aspect of contracts as far as i can tell.

by specifying that soa applications should only communicate via the message interface published at the boundary of the soa apps, we ensure that one soa app is not intimately tied to the implementation details of another; implementation can then be changed so long as the interface (message syntax and semantics) is preserved. this can, of course, be costly where the majority of apps in an enterprise are based on a common tech platform. e.g. most apps in a given division of an enterprise will run off the same RDBMS; allowing direct interactions (e.g. replication) between two DBs would be significantly cheaper than a custom message-oriented replication scheme.