Note that all blogs have been migrated to

SOA definition, part 2

Sep 30, 2007 | George Fairbanks

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.

  • “Functionality is exposed via discoverable and/or publis’hed interfaces only.” “Picture a cloud with interface jacks sticking out of it, and that’s about it.”
  • “Component boundaries (if any) are completely hidden.” In old CBD you could tell where one component ended and another one began. Indeed to assemble an implementation you had to choose components explicitly and compose them."

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.

Why Rhino Research?

Rhino Research is devoted to improving the state of software practice. We do this by using our industrial and academic roots to give you the freshest and most practical advice in classes and during consulting engagements.

Our clients

We have taught classes for many kinds of clients, ranging from regular information technology shops, to huge internet shops, to NASA.


subscribe via RSS


Rhino Research is a training and consulting company specializing in software architecture

124 W 60th St #37L
New York, NY 10023