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.

About

George Fairbanks is a software developer, designer, and architect living in New York city

Contact

gf-web@georgefairbanks.com
124 W 60th St #37L
New York, NY 10023
+1-303-834-7760 (Recruiters: Please do not call)
Twitter: @GHFairbanks