Izabela Szlachta at 18:44, 8 November 2012

2012-11-08T18:44:19Z

New page

{{Cat|SOA|30}}
{{Soa Links}}

==Scalability==
*Scalability can be understood as:
**an ability to add new features
**increase the utilization (number of users, requests, the size of data, etc..) of an existing system
*Minimizing the impact of modifications and failures on the system landscape as a whole
*Maintainability

==The Need for Fault Tolerance==
*No time for well-elaborated, robust system designs.
*Changing requirements
*A flight booking system failure may cost $100,000 an hour, a credit card system breakdown may cost $300,000 an hour, and a stock-trading malfunction may cost $8 million an hour.

== Loose Coupling==
*The aim of loose coupling is to minimize dependencies.
*When there are fewer dependencies, modifications to or faults in one system will have fewer consequences on other systems.
*Loose coupling is a principle; it is neither a tool, nor a checklist

==Forms of loose coupling==
{| class="wikitable"
|-
!
! Tight Coupling
! Loose Coupling
|-
! Physical connections
| Point-to-point
| Via mediator
|-
! Communication style
| Synchronous
| Asynchronous
|-
! Data model
| Common complex types
| Simple common types only
|-
! Type system
| Strong
| Weak
|-
! Interaction pattern
| Navigate through complex object trees
| Data-centric, self-contained message
|-
! Control of process logic
| Central control
| Distributed control
|-
! Binding
| Statically
| Dynamically
|-
! Platform
| Strong platform dependencies
| Platform independent
|-
! Transactionality
| 2PC (two-phase commit)
| Compensation
|-
! Deployment
| Simultaneous
| At different times
|-
! Versioning
| Explicit upgrades
| Implicit upgrades
|}

==Asynchronous Communication==
[[File:Soa-asynchronous-communication.png|150px]]

*The systems exchanging service messages do not have to be online at the same time
*Long answering times don’t block the service consumer
*Logic of the service consumer gets (much) more complicated

==Heterogeneous Data Types==
*Systems can modify their data types without directly affecting other systems (modified service interfaces affect only corresponding consumers)
*You have to map data types from one system to another

==Mediators==
*First type is when sender may know the physical address of the called system (broker or name server). You ask for a service using a symbolic name, and the broker or '''name server'''.
*The second type chooses the right endpoint for a request after the consumer sends it. The consumer sends the request to a symbolic name, and the infrastructure (network, middleware, ESB) routes the call to the appropriate system.
<signavio>db15170c373443ddb86acbb951d7831e:6b917110afabbb9222984d181c713f027eae6441f5d27f2b37cef37f79b4670_da11319251f89a85b7c12d4c0a9415975eeccaf58a2d7568bdc8b5b458afac9_e3769e91c9c32c5ddcd4c9edd315e675eefe328de711f781791d911c8befe</signavio>

==Weak Type Checking and Binding==
*Early and late binding
*Generic ESB
**ESB isn't coupled with any of the systems
**only general statistics
**general routing
*Type specific ESB
**Details statistics
**Routing based on specific conditions (type, value in a element, source, etc..)
**There is a dependency between the type and the ESB

==Interaction Patterns==
*Are only strings supported, or can other fundamental data types (integers, floats, Booleans, date/time types, etc.) be used?
*Are enumerations supported?
*Can you constrain possible values (e.g., define certain string formats)?
*Can you build higher types (structures, records)?
*Can you build sequence types (arrays, lists)?
*Can you design relations between types (inheritance, extensions, polymorphism)?

==Compensation==
*Two-phase commit (2PC)
*If only one modification is successful, you then “compensate” for the problem appropriately
*System updates don’t have to be performed synchronously
*You have to explicitly provide and call services that revert previous services or programs for manual error handling
*BPEL supports compensation

==Control of Process Logic==
*Process-control decisions can also lead to different forms of coupling. Having one central component controlling the whole process logic creates a bottleneck because each involved system must connect with it (Orchestration, BPM)
*Decentralized or distributed control (where each component does its job and knows which component will continue after) you avoid bottlenecks (Choreography, CEP)

==Deployment==
*Simultaneous deployment creates dependency
*The more loosely coupled approach of updating at different times, however, leads to a very important drawback: the need for migration, which leads to versioning

==Versioning==
With a more loosely coupled form of data type versioning, the consumer won’t have to do anything as long as the modifications are backward compatible.

==Summery==
*Loose coupling is a fundamental concept of SOA aimed at reducing dependencies between different systems.
*There are different forms of loose coupling, and you will have to find the mixture of tight and loose coupling that’s appropriate for your specific context and project.
*Any form of loose coupling has drawbacks. For this reason, loose coupling should never be an end in itself.
*The need to map data is usually a good property of large systems.

Loose Coupling - Revision history

Izabela Szlachta at 18:44, 8 November 2012