1 / 41

Distributed Software Systems with CORBA

Distributed Software Systems with CORBA. Presented by: Shruti Srivastava 05IT6015 Under the guidance of : Prof. Debasis Samanta. What is distributed System?. “A distributed system is a collection of independent computers that appears to its user as a single coherent system”

Albert_Lan
Download Presentation

Distributed Software Systems with CORBA

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Distributed Software Systems with CORBA Presented by: Shruti Srivastava 05IT6015 Under the guidance of : Prof. Debasis Samanta

  2. What is distributed System? • “A distributed system is a collection of independent computers that appears to its user as a single coherent system” Maartin Van Steen Andrew S. Tanenbaum “A Distributed system is one in which components located at networked computers communicate and coordinate their actions only by passing messages” George Coulouris Jean Dollimore Tim Kindberg

  3. Characteristics of D.S. • Concurrency of components • Lack of Global clock • Independent failures of components

  4. Difficulty in designing D.S. • Absence of global shared memory • Absence of Global Clock • Heterogeneity of the components • Concurrency of the processes

  5. Server Client Client Server Types of D.S. Architecture • Client-server Architecture

  6. Application Coordination Code Application Coordination Code Application Coordination Code Distributed Object Architecture or peer processors

  7. Need of a D.S. • Resource Sharing • Higher Performance • Fault Tolerance

  8. Architectures for DS • DCOM • CORBA • JAVA/RMI • GLOBE – a file based system

  9. Object Management Group(OMG) • Formed in 1989 to adopt the Distributed Object System so that the Object Oriented approach of a programming language can be used to develop software for a Distributed System • Has more than 700 members- vendors, developers and end users.

  10. Object Modeling Architecture The OMA is composed of an Object Model and a Reference Model. The Object Model defines how the objects distributed across a heterogeneous environment can be described, while the Reference Model characterizes interactions between those objects.

  11. Application Interface Domain Interface Common Facilities Object Request Broker Object Services OMA Interface Categories

  12. CORBA(Common Object Request Broker Architecture) - 1995 • “CORBA is a middleware design that allows application programs to communicate with one another irrespective of their programming language, their hardware their software platforms, the network they communicate over and their implementation.” - George Coulouris, Jean Dollimore, Tim Kindberg

  13. Main Features of CORBA • ORB Core • OMG Interface Definition Language (OMG IDL) • Interface Repository • Language Mappings • Stubs and Skeletons • Dynamic Invocation and Dispatch • Object Adapters • Inter-ORB Protocols

  14. ORB hides • Object Location • Object Implementation • Object Execution State • Object Communication Mechanisms • Object Creation • Directory Service • Convert to String and Back

  15. OMG Interface Definition Language // OMG IDL interface Factory { Object create(); }; IDL is a declarative language, not a programming language, it forces interfaces to be defined separately from object implementations

  16. Interface Repository IDL Specification has to be compiled before it can be used by an application program Distributed System has to be re-build every time its specification change This is a problem when an application access a foreign object through a gateway

  17. Solution? Interface Repository - The Interface Repository provides the information about registered IDL interfaces to client and servers that requires it

  18. Language Mapping • OMG IDL is just a declarative language, not a full-fledged programming language • IDL features are mapped to the facilities of a given programming language • IDL interfaces map to C++ classes, with operations mapping to member functions of those classes, modules map to C++ namespaces

  19. Stubs and Skeleton • A stub is a mechanism that effectively creates and issues requests on behalf of a client • A skeleton is a mechanism that delivers requests to the CORBA object implementation • Dispatching through stubs and skeletons is often called static invocation

  20. Dynamic Invocation and Dispatch Interfaces for dynamic invocation: • Dynamic Invocation Interface (DII) — supports dynamic client request invocation • Dynamic Skeleton Interface (DSI) — provides dynamic dispatch to objects The DII and DSI can be viewed as a generic stub and generic skeleton, respectively.

  21. Object Adapters • An object adapter is an object that adapts the interface of another object to the interface expected by a caller.

  22. Responsibilities of object adapters • Object registration • Object reference generation • Server process activation • Object activation • Request demultiplexing • Object upcalls - Without object adapters, the ability of CORBA to support diverse object implementation styles would be severely compromised

  23. Inter- ORB Protocol • General ORB interoperability architecture is based on the General Inter-ORB Protocol (GIOP), which specifies transfer syntax and a standard set of message formats for ORB interoperation over any connection-oriented transport • IIOP (Internet IOP)determines how GIOP can be implemented using TCP/IP

  24. Problem? • Is the distributed system predictable in case of failures and asynchronous messaging ? – NO • Solution- models like: • message queue • transaction process • virtual synchrony

  25. Message Queues (MQ)

  26. Advantages This model is useful for applications that can be interconnected by an asynchronous, one way, “forward and forget” communication paradigm. The advantage of the MQ model is that it is easy to use, implement, and understand. It also supports disconnected operation of mobile equipment

  27. Transaction Processing Monitors

  28. Limitations • They introduce substantial performance overhead and excessive serialization in many situations such as groupware applications and real-time market data feeds. • They are hard to program.

  29. Virtual Synchrony Components: • Failure suspector service • Group abstraction Failure suspector service detects faulty objects on the basis of timeout It only detects crash failures and assumes that objects fail by crashing without emitting spurious messages In an asynchronous system it is impossible to distinguish a crashed object from one that is very slow

  30. A Scenario: A client application mistakenly believes a server object as faulty, due to a high temporary load on the server’s machine. However, another client application is able to interact with that server without any problem. Believing the server has crashed, the first client requests the run-time system to create a new instance of the server on another host. The result is that now two servers with an inconsistent internal state exist, and that both clients and servers believe that the system is running correctly. In reality, the clients are submitting update requests to two different servers, which places the system into an inconsistent state

  31. Solution • Group abstraction of Virtual Synchrony The object group abstraction allows programmers to assign a single object reference to a set of network objects that implement the same interface • Use Roll Forward recovery

  32. Object Group in VS Model

  33. Limitation It lacks high-level abstraction, standard APIs And framework, so applications may become hard to implement

  34. Comparison between TP, MQ, VS

  35. Feature CORBA DCOM Abstraction Level   Java Integration   OS Platform Support   All Java Implementation   Typed parameter support   Ease of configuration   Comparison between CORBA and DCOM

  36. Distributed method invocation   State across Invocation   Dynamic discovery and Metadata support   Dynamic Invocation   Performance (remote ping)   Wire level security  

  37. Wire level Transaction   Persistent object reference   URL based naming   Multilingual object Invocation   Language- neutral protocol   Intergalactic scaling   Open Standard  

  38. References • Distributed System Concept and Design – Coulouris, Dollimore, Kindberg • Distributed System Principles and Paradigms – Tannenbaum, Van Steen • Software Engineering – Sommerville • Client/Server programming with Java and CORBA – Robert Orfall, Dan Harkey • Constructing Reliable Distributed Communication Systems with CORBA - Silvano Maffeis, Douglas C. Schmidt •  CORBA: Integrating Diverse Applications Within Distributed Heterogeneous Environments - Steve Vinoski, IONA Technologies, Inc. • The Open Agent Architecture _ A Framework for Building Distributed Software Systems - David L_ Martin, Adam J_ Cheyer, Douglas B_ Moran • www.omg.org

  39. Thank You

More Related