CORBA1 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

CORBA2 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!!

CORBA3 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)

CORBA4 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

CORBA5 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

CORBA6 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

CORBA7 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

CORBA8 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

CORBA9 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)

CORBA10 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

CORBA11 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

CORBA12 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 Application …. Transport …. Physical Application …. Transport …. Physical ClientServer

CORBA13 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

CORBA14 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

CORBA15 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

CORBA16 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

CORBA17 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

CORBA18 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

CORBA19 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)

CORBA20 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

CORBA21 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

CORBA22 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

CORBA23 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