Bernard Szlachta: Undo revision 27407 by Bernard Szlachta (talk)

2015-07-29T06:15:43Z

Undo revision 27407 by Bernard Szlachta (talk)

New page

{{Cat|SOA|01}}
{{Soa Links}}

== Books ==
* Enterprise SOA: Best Practices für Serviceorientierte Architekturen - Einführung, Umsetzung, Praxis (2010 Dirk Krafzig)

* SOA in Practice: The Art of Distributed System Design (2009 Nicolai M. Josuttis)
* 100 SOA Questions: Asked and Answered (2010 Kerrie Holley)
http://ecx.images-amazon.com/images/I/51iS6EuBiPL._SL160_PIsitb-sticker-arrow-dp,TopRight,12,-18_SH30_OU02_AA160_.jpg
http://ecx.images-amazon.com/images/I/51aVzZ%2BtWHL._SL160_PIsitb-sticker-arrow-dp,TopRight,12,-18_SH30_OU02_AA160_.jpg
http://ecx.images-amazon.com/images/I/41zDOhuKu-L._SL160_PIsitb-sticker-arrow-dp,TopRight,12,-18_SH30_OU02_AA160_.jpg

== Need and Motivation ==
"It is not the strongest of the species that survive, nor the most intelligent, but the ones most responsive to change."

“In the struggle for survival, the fittest win out at the expense of their rivals because they succeed in adapting themselves best to their environment.”

''As quoted in The Living Clocks (1971) by Ritchie R. Ward''

== SOA and Technology ==
*SOA is NOT a technology
*SOA is NOT a new concept
*We can use it because of STANDARDS
*The power of the computers allowed us to do it
*Network speed, CPU, memory and disk space

== SOA Definition ==
'''Simple Definition'''

Service Oriented Architecture (SOA) is

a loosely-coupled architecture

designed to meet the business needs of the organization.

'''OASIS Reference Model Definition'''

Service Oriented Architecture (SOA) is

a paradigm

for organizing and utilizing

distributed capabilities

that may be under the control of different ownership domains.

'''SOA OMG Definition'''

Service Oriented Architecture (SOA) is

a way

of describing and understanding organizations, communities and systems

to maximize agility, scale and interoperability.

== SOA Components ==
* '''Services''' self-contained business functionalities
* '''Infrastructure''' usually enterprise service bus (ESB),
* '''Policies and processes''' usually have different owners.

== SOA is like an Elephant ==
{| class="wikitable"
|-
| [[File:Soa-elephant.png|300px]]
|
*The man touching the trunk believes it to be a snake
*The man touching the tusk believes it to be a spear
*The man touching the ear believes it to be a fan
*The man touching the elephant‘s side believes it to be a wall
*The man touching the tail believes it to be a rope
*The man touching the legs believes they are trees.
|-
|}

== Sheet of Paper ==
[[File:Paper sheet.jpg|300px]]
* Artist - canvas
* Poet - space for a poem
* Engineer - paper plane
* Kid - spit wad

== Conflicting definitions ==
* Every author and standards bodies provide their definitions of SOA
* Every domain (business, IT, EA) will have a definition focusing on their aspects

* '''CEO''': SOA is a set of services that can be exposed to their costumers and other parts of the organization. Services can be combined and recombined in a flexible manner to serve ever-changing business needs.
* '''CIO''': SOA will reduce the lifetime cost of the application portfolio and maximize ROI
* '''Chief Architect''': Just specific type of an Enterprise Architecture
* '''IT Architect''': SOA is a way we integrate services (like CORBA, DCE) but based on new standards and patterns
* '''Business Analyst''': SOA allow to gather requirements in an easy way and focus on business processes are the major part of requirements (rather than use cases)
* '''Programmer''': SOA is programming paradigm usually with WSDL and Web Services and Message Exchange Patterns

== SOA as an architectural pattern ==
<signavio>2e313480811446c9ab155bfb2230481f:aa551ce190f28ca568ea558ccc5d3156ec0cda07a528490a1ae4cfb7b1ef_505a2ac832f58506b39c8d7c15ee452579844ac178b2a1ebd7fb5c5288621e_59b578a0f418356afe517e3e352a2f5956f4dee14df89287236e212a4</signavio>

== Languages development ==
*Assembler
*Procedural languages (C, Pascal, etc..)
*Low-level OOL (C++, VB6...)
*High-level (machine independent) languages (Java, C#...)
*Dynamic Languages (Python, PHP...)
*Declarative languages (SQL, Prolog, XSL..)
*MDA (BPMS, BRMSS)

'''Interoperability'''
*Languages itself cannot easily exchange information
*Bridges between languages are complex and not reliable
*If you have n languages, you need n(n-3)/2+n bridges
*Difficulties with distributed environment

'''How did it start'''
*Large Distributed Systems
*Point to point connections
*CORBA, DCOM, and others

== Re-usability ==
Who decide what to reuse:
* Function (programmer)
* Class (programmer)
* Component (software architect, programmer)
* Service (Managers, Chief Architect)

== Dependencies ==
{|
|-
|
{| class="wikitable"
|-
! Systems
! Connections
|-
|2
|1
|-
|3
|3
|-
|4
|6
|-
|6
|12
|-
|50
|1225
|-
|120
|7140
|-
|n
|n(n-1)/2
|}
| [[File:Soa-dependencies2.jpg|220px]]
|}

== Making Changes ==
[[File:soa-fragile.jpg|130px]]
*Each system may depend on the other
*No one controls the dependencies

'''Making Changes and the Business'''

[[File:Soa-changes-and-business.jpg|250px]]
*Business cannot stop for a couple of weeks
*If something goes wrong the business may go bust (and I know cases where it did)

== Integration Hell ==
[[File:Soa-integration-hell.jpg|240px]]
*More money spend on integration than on new features development
*Competitors with more agile system are serious threat

== Decoupling ==
[[File:Soa-scissors.jpg|180px]]
*On of the paradigm of SOA
*Can be achieved in may ways (discussed later)

== Re-usability ==
*Function/procedure (not clear parameters)
*Class (language specific)
*Component (technology specific)
*Service (contract specific)
*Messages (Web Services, RPC, ICal, SMTP)

== Architects Dream ==
*Write functionality only once
*Use it from any application
*Orchestrate it from a diagram-driven tools

== Can you buy SOA? ==
*SOA is a concept
*SOA is free
*SOA is vendor independent by definition
*You can buy a SOA suit, but make sure that you will not be vendor locked again

== Orchestration ==
[[File:Soa-Orchestration.jpg|500px]]
*Can be simple
*Extensible
*Easy to change one component
*It is not choreography

== How to start ? ==
[[File:Soa-how-to-start.jpg|220px]]
*Is there the way?
*How can I start?
*SOA steps

== SOA sounds like... ==
[[File:Soa-way-to-heaven.jpg|250px]]
*Straight way to heaven
*Is it really so good?

== Electricity Grid → Cloud ==
[[File:Soa-electricity-grid.png|500px]]

==The Tale of the Magic Bus==
*You have to create an individual solution for each kind of connection
*Even if you only had 10 different platforms and 5 different protocols, if you wanted to enable each platform to communicate with each other platform, you would need over 100 different solutions.
*And you have many more than 10 platforms

[[File:Soa-macig-bus.png|550px]]

*Piece of software that reduces the number of connections and interfaces in your system
*point-to-point approach might require up to n × (n–1)/2 connections for n systems (and twice as many interfaces),
*the Magic Bus requires only one connection and interface for each system.
*.... 9 for 10 systems, 29 for 30 systems, and 49 for 50 systems
*It was indeed very easy to connect systems, and suddenly it became very easy to grow again.
*...until suddenly, it all broke down.
*Slack means death, so one year later, they were out of business.

==SOA Drawbacks==
* Usually it is much slower than monolithic applications or other types of integration
* Performance is the main issue in most of the cases
* Additional infrastructure to maintain
* SOA security

==Two faces of “Architecture”==
*The “Architecture” in SOA can stand for either software architecture (technical) or business architecture.
*Services and systems usually have different owners
*Communication between the owners must be enforced on the management level, hence SOA is about management

Service Oriented Architecture - Revision history

Bernard Szlachta: Undo revision 27407 by Bernard Szlachta (talk)