SOA can deliver strategic value to companies willing to change (part of) their enterprise, not just their IT systems! Many companies however have tried and failed delivering SOA with the promised reduced IT burden and ROI. Some companies are even treating SOA like a disease. This is not fair. SOA is a way of thinking applied to supporting tools and not a tool on itself.
I hope this collective set of topics will help companies decide whether this SOA thing is blessing or burden.
Friday, September 21, 2012
SOA, Separation of concerns and agnosticism (5/5)
concerns and abstraction
Any service that we build should have a certain level of
abstraction. Abstraction comes in many kinds but they are all intended to provide
separation of concerns.
As an example. if a service accesses a database and the
database has an VARCHAR2() field for a numeric value called DBLADR2FLD, then it
should not matter to the service consumer what the underlying datatype and
column name of the database field is. In essence the service abstracts from the
implementation to prevent this.
Additionally, a VARCHAR2() datatype is a specific vendor
technology datatype. The service should also abstract from the specific
database vendor technology.
Why we do this can be answered pretty simple and
straight-forward: the underlying data model and the database vendor technology
can change over time or be replaced by a completely different system or
technology, and this should not matter to the consumer of the service. This is
the most important reason why we have abstraction. By doing contract-first
approach, we can already make sure that up-front no implementation-specific or
technology-specific dependency can trickle into the contract and as a
consequence into the service consumer logic (see )
Another form of abstraction is the quality of service
abstraction: not all quality of service information does need to be known to
the consumer of a service. Important QoS attributes are the availability and
the reliability of a service, how much load it can handle and what the average
and peak duration of execution is.
Not important however is the fact that the service had 4
failures in the past hour, as this does not say anything about how it will
behave in the future and also it might even make the service look unattractive.
In a sense we need to be shielding these kind of runtime concerns from
potential service consumers. This can be done by creating SLAs that cover the
quality of service in a constructive way with meaningful performance
Many more types of abstraction can be applied - if I can find some more time I will update this article.