Service Oriented Architecture
Jump to navigation
Jump to search
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)
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
|
|
Sheet of Paper
- 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
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
|
|
Making Changes
- Each system may depend on the other
- No one controls the dependencies
Making Changes and the Business
- 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
- More money spend on integration than on new features development
- Competitors with more agile system are serious threat
Decoupling
- 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
- Can be simple
- Extensible
- Easy to change one component
- It is not choreography
How to start ?
- Is there the way?
- How can I start?
- SOA steps
SOA sounds like...
- Straight way to heaven
- Is it really so good?
Electricity Grid → Cloud
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
- 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
