SOA definition, part 2

I got a great email from my friend Alan B. today about my SOA definition blog posting. He too has been concerned about its definition and offers the following to work towards a definition.

These are very good, but I’m not sure how I handle identity problems when we hide components. For example, the personnel service would look identical for two different divisions of the company unless you knew the component identity. Perhaps this could be handled with appropriate service definitions.

He also discusses a third lurking requirement. It would be possible, but undesirable, to simply wrap everything you’ve already built with an interface and call it SOA. Taking the SQL interface to your DB and publishing it would violate this unnamed third requirement. Slightly less objectionable, but perhaps still not within the SOA spirit, would be wrapping CRUD (Create, Read, Update, Delete) operations on data structures and publishing them as an interface.

Let me propose that this third requirement is something like this:

Interfaces should present operations in the domain of the resulting system, and hide the technology used to implement it.

Architectural styles should be viewed as Platonic Ideals(, not as engineering artifacts. Almost no deployed system perfectly conforms to a single architectural style. Perhaps, for those that do, we should coin a new term, like “embodied style”. The NASA MDS system would be an example of an embodied style. So even if our ideal SOA style is compromised in practice, that’s ok and even expected. Plato never built software, and if he did he’d be programming in ML anyway.