Database Reference
In-Depth Information
The characteristics, goals, and benefits of
SOA
As an evolutionary approach, comprising the best of the architectural and technical solu-
tions designed in the last forty years (arguably even more), SOA nowadays in many ways
is quite well standardized with a well laid out vocabulary of meanings of technical terms.
Along the course of the entire topic, we will stick to the definition of SOA, summarized by
Thomas Erl in
Service-Oriented Architecture: Concepts, Technology, and Design, Prentice
Hall / PearsonPTR Publishing.
This is also available at
http://serviceorientation.com/whatissoa/ser-
vice_oriented_architecture
.
The complete SOA Manifesto that was developed as a result of
systematic collaboration of many experts' groups can be found at
ht-
Still, it's quite fascinating to see that debates are still being sparked and raged worldwide
regarding proper terms and their meanings. We are not going to judge or participate in any
form in these discussions. That's not the purpose of this topic. Obviously, there is one good
way to avoid that, which is to stay focused on the practical targets that SOA helps us to
achieve. No wonder these goals and benefits are quite well defined and are the sole pur-
poses and reasons why the SOA approach was proposed in the first place. Any practicing
architect who has been through several projects (even if not defined as being SOA-based)
could easily recollect the common requirements stated by both sides: Business and IT. Let's
just quickly recollect them. So, any concrete solution should have the following properties:
• They should be kept as simple as possible while still meeting the business needs [R
1]
• They should be kept flexible and consistent to support the changing enterprise-
wide business needs and enable the evolution of the company [R 2]
• They should be based on open industry standards [R 3]
• Systems and components within the proposed IT domain (architecture) will be
viewed as a set of independent and reusable assets that can be composed to provide
a solution for the company [R 4]
• They should be based on clearly defined, well-partitioned, and loosely-coupled
components, processes, and roles [R 5]
• They should be designed for ease of testing [R 6]
• They should be based on a proven, reliable technology that is used as originally in-
tended [R 7]
Search WWH ::
Custom Search