Database Reference
In-Depth Information
SOA principles
Don't worry, we will not be reinventing the terms here again. After more than ten years of
implementation, the principles are quite well declared and explained. The consolidation
done by Thomas Erl has been accepted de facto by most of the top market players, and
what is most important for this exercise is that it has been accepted even by Oracle. You
can refer to it at
http://serviceorientation.com/serviceorientation/index
.
Here, we will mostly focus on the relation of the principles and characteristics and the con-
sequences that will follow if the principles are neglected. Jumping ahead, it would be right
to say that the patterns are really needed when principles are not implemented as they are
intended. The reasons for this could be different, which are mentioned as follows:
• The already existing burden of legacy systems prevents us from implementing
more reusable solutions immediately. We really do not want any revolutions.
• The obvious political reasons of all kinds, usually caused by strong focus on tactic-
al goals, temptation to pick the low-hanging fruit, and show quick results even if
they are based on another silo in the app's stack.
• Most interestingly, patterns would be required to resolve the conflicts that arise
during the implementation of different principles from the same technological area.
Yes, principles can contradict and must be applied in a meaningful context.
It is also important to recognize that all these architectural principles are generic, common,
and universal for the selected technological area (SOA in this case). Principles are also tan-
gible, well recognized, and limited in number.
Some may say that our top-ten requirements can be perceived as principles as well. Even
all illities could be principles because of their universality and simplicity. Unfortunately,
simplicity here cannot help. We, as architects, should give strict, precise, and most import-
antly, tangible guidance to developers, and be able to follow our own recommendations.
The measurable outcome is the result of proper guidance, and the principles here are
closest to the physical implementation and must be understood and followed. Some prin-
ciples could be less tangible than others and could just present the results for collective im-
plementation principles with lesser abstraction, but still the results of the implementations
can be measured. Let's take the most common illities such as
reliability
or
flexibility
and
try to explain to your developers (or yourself) in just few words how to code your compon-
ents in order to achieve them.
Search WWH ::
Custom Search