Distributed Software Systems

1. Distributed Software Systems • Any software system can be physically distributed • By distributed coupling we get the following: • Improved performance & fault tolerance • Localized computation at point of use • Resource availability is localized • Maximum concurrency

2. Distributed Software Systems • Breaking a system into distributed specialized components forces you to have: • High cohesion within components • Loose coupling between them • Distribution gives specialization • DBMS on a hardware optimized machine • Presentation components not tied to heavy load computation (DBMS) • Business logic can be treated as a separate set of services Tiers!!

3. Distributed Components • Components are designed to offer a set of services • These services form the components interface • Other components use this interface independent of the location of the component (local or remote)

4. Evolution of Distribution • Distributed systems arise naturally from the structure and process of a business • Geographic separation • Legacy integration • Merger, acquisition • The supporting technology has matured • Faster networks • Higher level protocols & APIs • Use of Internet and Intranet • Client/Server

5. Evolution of Distribution • Enterprise solutions are needed to support new management structures • Technology was initially used to automate manual processes • The redesign of company structure and work practice is aimed at adding value • Legacy backbone must be used (cost) so we need system that can integrate and migrate • Hence the growth of distributed computing

6. Consequences of Distribution • Operations execution is no longer trivial • Failure modes more complex than local cases • Communication can dominate computation • All activities are intrinsically concurrent • The ratio of communication to computation is a major factor that must be considered in the architecture • The ANSA (Advanced Network System Architecture) lists some inappropriate assumption for distributed systems

7. ANSA Inappropriate Assumptions • Global Shared Memory • Message passing, distributed memory • Sequential Execution • Concurrency is intrinsic • Total Failure • Components can continue to function • Synchronous Interaction • Network latency may force use of synchronous calls • Locality of Interaction • Interaction local or remote, with increased scope for failure • Fixed Location • Components may migrate Global Consistency

8. Principles of Distribution • Previous research has identified principles and architectures (ANSA, ISO) • Reference models are frameworks for development • OSI 7 layer model • ODP viewpoint and projections • FTP at Application, RPC at Session, TCP at Transport etc • Open Distributed Processing (ODP) is a reference model that defines concepts for distributed development

9. Transparency Mechanisms • We need transparency to reduce development complexity • This can simplify both the job of the architect and the implementer • To achieve transparency support is required at every stage • Infrastructure and Architecture • Design and Implementation • The aim of transparency is to mask districted phenomenon (systems are never completely seamless)

10. Transparency Mechanisms • Access • Access to local and remotes services must be the same • Location • No knowledge of where a service resides is needed • Replication • For performance service replication may be necessary • Failure • Faults don’t propagate through the entire system

11. Transparency Mechanisms • Migration • Movement of services does not impact applications • Scalability • Performance must scale with size • Transaction • Services can be shared without interference from other client • No partial states. A transaction is an atomic unit of work

12. Application Application …. …. Transport Transport …. …. Physical Physical Programming Distributed Systems • Different abstraction levels available for programming • Lower level: More control but more complexity • Higher Level: Closer to problem domain but potentially inflexible and/or propriety Client Server

13. Programming Distributed Systems • Inter-Processor communication happens at the physical layer • Ideal programming layer is the application layer • Programmers deal with the abstraction of business objects and moves down to implement sockets etc • This level (layer 3,4) is not suitable for the high level abstractions and introduces too much complexity for developing the entire application here

14. Programming Distributed Systems • In theory the lower layers should be encapsulated • In practice this is not achievable so specialist programmers for the relevant layers are required • This leads to the requirement for much integration testing • The distributed computing model tries to provide a simple and uniform model for communication to directly address the needs of the developers at each layer

15. Distribution Mechanisms • Middleware is the software used to enable distributed computing • It is a set of common business-unaware services and allow components to interact over a network • Often referred to as the “plumbing” • Middleware should make networks irrelevant to applications and end users • Solely a technology product: transaction managers, message querying systems etc

16. RPCs • Extends the concept of a basic function call • Layered onto of an underlying transport system such as TCP/IP • Convenient methods for implementing client/server applications • Used for message passing • Powerful feature of RPC is transparency • Foundation for full enterprise and scalable distributed systems

17. Distributed Object Systems • Object technology can be applied • Tactically • Strategically • Objects are encapsulated entities that interact by passing messages through defined interfaces • Intrinsic properties makes objects ideal for distribution • Refinements and clarifications still tend to be needed

18. Distributed Object Systems • Encapsulation makes object suitable for distribution • The separation of interface and implementation means interaction can only take place in ways determined by the developer • With distributed systems there is also no access to the actual representation

19. Distributed Object Systems • A good OO design allows for the separation of visual, business and technical components • Distribution simply allows these components to be placed on the most suitable hardware available without having to alter the application (in theory)

20. Distributed Object Technologies • Different standards available • OMG CORBA (from previous work with disparate systems) • Microsoft DCOM (network COM) • Java RMI (homogenous components with JVMs) • Each technology has its own origins, strengths and area of application • Distributed object model offers finer granularity than RPC model

21. Distributed Object Technologies • The tasks of the selected middleware technology are: • Locate available objects • Route messages independent of network, operating systems and languages • Transaction handling across objects • Therefore different standards have developed to achieve these tasks

22. Classes of Distributed Support Services • Distributed presentation services • Distributed processing services • Remote data access service • Remote file access service • Distributed data management • Distributed object management services

23. Summary • Distribution is intrinsic in many systems and needs to be exploited • References models provide guidelines and common concepts at every level • Flexibility and open standards are required to build seamless heterogeneous systems • Distributed objects are the obvious evolution of OO systems