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.
subscribe via RSS