Lecture 04 - Loose Coupling

1,158 views

Published on

Lecture 04 - Loose Coupling

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,158
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
31
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Lecture 04 - Loose Coupling

  1. 1. Book Author: Nicolai M. Josuttis Chapter Four: Loose CouplingIT-Slideshares http://it-slideshares.blogspot.com/
  2. 2. 4.0 Loosely Coupling (SOA) SOA APPLIES TO LARGE DISTRIBUTED SYSTEMS. SCALABILITY AND FAULT TOLERANCE ARE KEY TO THE maintainability of such systems. Another important goal is to minimize the impact of modifications and failures on the system landscape as a whole. Thus, loose coupling is a key concept of SOA.
  3. 3. 4.1 The need for Fault Tolerance If youre not fast enough, flexible enough, and cheap enough, youll soon find yourself out of the market. Fast and cheap solutions, however, cant be well designed and robust. Cost of opportunity or money when systems are down. Fault tolerance is key for large distributed systems. When problems occur, it is important to minimize their effects and consequences.
  4. 4. 4.2 Possible Forms of Loose Coupling concepts Tight Coupling Loose CouplingPhysical Connection Point-to-Point Via MediatorCommunication Style Synchronous AsynchronousData Model Common Complex types Simple Common typesType System Strong WeakInteraction Pattern Navigate through Data-centric, self- complex object trees contained messageControl of Process Logic Central Control Distributed ControlBinding Statically DynamicallyPlatform Strong platform Platform Independent dependenciesTransactionality 2PC (two-phase commit) CompensationDeployment Simultaneous At different timeVersioning Explicit upgrades Implicit upgrades
  5. 5. 4.2.1 Asynchronous Communication •Asynchronous communication usually means that the sender of a message and its receiver are not synchronized. •One problem with asynchronous communication occurs when the sender needs a reply. •Programming, testing, and debugging all the possible eventualities can be very complicated and time consuming. • How ESB handles message queues
  6. 6. 4.2.2 Heterogeneous Data Types The harmonization of data types over distributed systems (argument against SID model) Large distributed systems typically have different owners, it was tough to reach agreements. “Analysis paralysis": if you try to achieve perfection when analyzing all requirements, youll never finish the job. The price of harmonization becomes too high. Keeping all the systems in sync is simply too expensive in terms of time and money. You need data type mappings (which include technical and semantic aspects). Although mapping adds complexity, it is a good sign in large systems because it demonstrates that components are decoupled.  The advantage is that systems can modify their data types without directly affecting other systems (modified service interfaces affect only corresponding consumers).  The drawback is that you have to map data types from one system to another.
  7. 7. 4.2.3 Mediators In principle, there are two kinds of mediators:  The first type tells you the correct endpoint for your service call before you send it. That is, you still have point-to-point connections, but with the help of these mediators, you send your service calls to different addresses. Such a mediator is often called a broker or name server. You ask for a service using a symbolic name, and the broker or name server tells you which physical system to send your request to. This form of mediation requires some additional intelligence at the consumer site.  The second type chooses the right endpoint for a request after the consumer sends it. In this case, the consumer sends the request to a symbolic name, and the infrastructure (network, middleware, ESB) routes the call to the appropriate system according to intelligent routing rules. Web Services are technically point-to-point connections, where you typically use a broker to find the physical endpoint of a request, and/or you insert some so-called interceptors that route your request at runtime to an available provider.
  8. 8. 4.2.4 Weak Type Checking In order for the SOA infrastructure (ESB) to check types, it needs to have some information about those types. Modifications of the interface requires synchronize updates to all adapters and ESB  tighter dependencies Solutions: make ESB generic and impose type checking only on the consumer/provider based on contract (those who publish/subscribe to the service)  Make judgment based on the stability of the data  Find the ‘right’ kind of coupling (loose or tight … ?)
  9. 9. 4.2.5 Binding Binding (the task of correlating symbols of different modules or translation units) allows a form of loose coupling that is similar to weak type checking. Again, you have to decide between early binding, which allows verification at compile or start time, and late binding, which happens at runtime.
  10. 10. 4.2.6 Platform Dependencies You have more freedom of choice if platform- independent solutions are preferred over strong platform dependencies.
  11. 11. 4.2.7 Interaction Patterns Recommend to have a basic set of fundamental types that you can compose to other types (structures, records) and sequences (arrays). Be careful with enumerations (an anachronism from the time when each byte did count—use strings instead), inheritance, and polymorphism (even when XML supports it).  Are only strings supported, or can other fundamental data types (integers, floats, Booleans, date/time types, etc.) be used?  Are enumerations (limited sets of named integer values) 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)? The more complicated the programming constructs are, the more abstractly you can program. However, you will also have more problems mapping data to platforms that have no native support for a particular construct.
  12. 12. 4.2.8 Compensation 2PC vs. compensation 2PC may lead to delays and deadlocks Compensation approach modifies the first backend, and then modify the second backend; if only one modification is successful, you then "compensate" for the problem appropriately. The drawback of compensation is that you have to explicitly provide and call services that revert previous services or programs for manual error handling. BPEL, the process execution language of Web Services, directly supports compensation.
  13. 13. 4.2.9 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. Failure of such a central component will stop the whole process. On the other hand, if you have decentralized or distributed control (where each component does its job and knows which component will continue after) you avoid bottlenecks, and if some systems fail, others can still continue to work.
  14. 14. 4.2.10 Deployment Whether you require that system updates be deployed simultaneously, or at different times, is related to coupling. Of course, systems are bound more tightly to each other if it is required that they update synchronously. 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.
  15. 15. 4.2.11 Versioning If the provider introduces a new type version, the consumer will have to upgrade explicitly to this new type; otherwise, the provider will have to support both types. If, on the other hand, the provider just adds the attribute to the existing type, this might cause binary compatibility issues, and require the consumer to recompile its code or use another library. With a more loosely coupled form of data type versioning, the consumer wont have to do anything as long as the modifications are backward compatible.
  16. 16. 4.3 Dealing with Loose Coupling To avoid asynchronous communication whenever possible, based on the experience that it led to race conditions at runtime that were very hard, or even impossible, to reproduce in a development environment, and therefore almost impossible to fix. Synchronous calls were allowed only for reading service calls because the performance was not good enough for writing service calls. ESB should be separated from a backend via a protocol, or via an API.  via an API usually means that the ESB provides libraries each backend or backend adapter has to use. So, deployment and binding become issues.  On the other hand, using a common API (protocol), you can hide some aspects of synchronous or asynchronous communications inside the ESB.
  17. 17. 4.4 Summary  Loose coupling is a fundamental concept of SOA (and large distributed systems in general) 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 thats 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.IT-Slideshares http://it-slideshares.blogspot.com/

×