verteilte systeme distributed systems
play

Verteilte Systeme (Distributed Systems) Karl M. Gschka - PowerPoint PPT Presentation

Verteilte Systeme (Distributed Systems) Karl M. Gschka Karl.Goeschka@tuwien.ac.at http://www.infosys.tuwien.ac.at/teaching/courses/ VerteilteSysteme/ Some slides based on material from this book (Prentice Hall, 2005) 2 Concepts,


  1. Verteilte Systeme (Distributed Systems) Karl M. Göschka Karl.Goeschka@tuwien.ac.at http://www.infosys.tuwien.ac.at/teaching/courses/ VerteilteSysteme/

  2.  Some slides based on material from this book (Prentice Hall, 2005) 2

  3. Concepts, Paradigms, Technologies Web Services Systems Multimedia Databases Pervasive Engineering CORBA COM+ WWW GRID J2EE .NET VoIP P2P ... Communication Processes & Concurrency Naming and Discovery Coordination & Agreement Replication & Consistency How is naming and Dependability and FT discovery realized in Transactions COM+ technology? Security (Persistency, Durability) 6

  4. Paradigms and Characteristics (1)  Classifications mixed and not orthogonal!  Focused entity: Data item, tuple, file, document, object, component, service, resource, stream, ...  Communication mechanisms: Transparency vs. coordination-based  Request/reply  Message-passing (document exchange)  DSM and associative tuple spaces  Event and notification systems: publish/subscribe; subject-based, (interupt signaling/exception handling) 7

  5. Paradigms and Characteristics (2)  Communication patterns:  synchronous (blocking) vs. asynchronous (non- blocking)  transient vs. persistent  Time: real-time vs. non-real-time, sync vs. async, ...  Coupling: tight vs. loose (temporal, referential, ...)  Scale and granularity: Client/server – pervasive  Mobility and topology: Structured, unstructured, ad-hoc, overlay, ...  Technologies, standards, and big players: OMG, J2EE, Microsoft, IBM, SAP, IETF, ITU, ... 8

  6. Communication coupling e.g. transient message- e.g. persistent passing; RPC; RMI message-passing e.g. „ad-hoc“ communication; e.g. tuple spaces; event and subject-based; persistent DSM; publish/subscribe; associative; TIB/Rendevous JavaSpaces A taxonomy of coordination models 9

  7. Technology Overview  Distributed object-based systems  Components and EAI  Coordination-based systems  WWW, SOA, Grid, P2P  Lecture summary

  8. Distributed object based systems  CORBA  ORB  IDL (language mapping)  DCOM  Builds ORPC on top of DCE RPC  Integration of binary components from different languages (e.g. Visual Basic, Java, C++)  Java  RMI  Single-language middleware 12

  9. CORBA Object Model The general organization of a CORBA system. 16

  10. CORBA Language Mapping IDL IDL Compiler Object Client Stub Skeleton Implementation Code Code Code Code In programming language „A“ In programming language „B“ Language „A“ Language „B“ Compiler and Linker Compiler and Linker Server Client Object generates Stub Skeleton reads Object Request Broker 22

  11. Portable Object Adapter OID: POA assigned or user assigned Thread per request, connection, object,... Policy Multiple OIDs  single servant 1. separated from Activation 2. One servant for all objects explicit or 3. Single servant, many objects on demand mechanism! and types (DSI) Mapping of CORBA object identifiers to servants. a) The POA supports multiple servants. b) The POA supports a single servant. 43

  12. Object References The organization of an IOR with specific information for IIOP  binding! 46

  13. CORBA Services Service Description A key to success for each Collection Facilities for grouping objects into lists, queue, sets, etc. technology is the set of Query Facilities for querying collections of objects in a declarative manner Concurrency Facilities to allow concurrent access to shared objects services and development Transaction Flat and nested transactions on method calls over multiple objects support it provides! Event Facilities for asynchronous communication through events Notification Advanced facilities for event-based asynchronous communication Externalization Facilities for marshaling and unmarshaling of objects Life cycle Facilities for creation, deletion, copying, and moving of objects Licensing Facilities for attaching a license to an object Naming Facilities for systemwide name of objects Property Facilities for associating (attribute, value) pairs with objects Trading Facilities to publish and find the services on object has to offer Persistence Facilities for persistently storing objects Relationship Facilities for expressing relationships between objects Security Mechanisms for secure channels, authorization, and auditing Time Provides the current time within specified error margins Overview of CORBA services. 49

  14. COM Object Model DCOM CORBA The difference between language-defined and binary interfaces. 62

  15. Type Library and Registry ~ CORBA ~ CORBA interface implementation repository repository The overall architecture of DCOM. 64

  16. Java RMI  Integrated into the language (homogeneous)  interface construct used to define remote objects  remote interface indicates remotely callable object  Objects are passed between JVMs  Marshaling = serialization (homogeneous)  rmic = IDL compiler  rmid = daemon listening for rmi incoming calls  rmiregistry ~ directory service (supports binding)  Similar to CORBA but supports only one language  Subtle differences local/remote: Cloning (server only), synchronize (proxy only)  Remote object passed by reference (refers to proxy implementation) (implementation handle) (  only one language + class loader facility) 78

  17. Technology Overview  Distributed object-based systems  Components and EAI  Coordination-based systems  WWW, SOA, Grid, P2P  Lecture summary

  18. Enterprise Application Integration  Today we are developing tomorrow‘s legacy systems, that have to be integrated the next day  Approaches to replace N technologies by one new technology usually end up with N+1 technologies   Enterprise Application Integration (EAI) is the creation of business solutions by combining applications using common middlewares, interfaces, standards, and toolchains.   Integration at presentation, data, or functional layer 84

  19. Legacy Systems they work proven functionality tested code often highly efficient and robust historical Investment 85

  20. Where can we agree?  There will be no consensus on hardware.  There will be no consensus on operating system.  There will be no consensus on network protocols.  There will be no consensus on programming language.  There must be consensus on interfaces and interoperability (interaction and composition)!   Standards, virtualization, components, services 87

  21. Virtualization in Distributed Systems (b) A virtual machine monitor, (a) A process virtual with multiple instances of machine, with multiple (applications, OS) instances of (application, combinations. E.g., VMware, runtime) combinations. Xen E.g., JVM. 88

  22. Why use components? “Avoid developing software – use components“ OMG Tagung, Wien 2001 “Components are for composition“ C. Szyperski  Concentration on the core competence  Encapsulation of solutions in components  Open for COTS products  Re-Use of components Components are well- known and proven in other domains 93

  23. Component-based Software Engineering „Buy before build. Reuse before buy“ Fred Brooks 1975(!) Components: CBSE and Product Lines 94

  24. Product Line Components of Mercedes E class cars are 70% equal. Components of Boeing 757 and 767 are 60% equal.  most effort is integration istead of development! Application A Application B Quality, time to market, but complexity  re-use 95

  25. Component vs. Object  Component  Object  Independent Development  Banana – gorilla problem   Third party development Local development   Source integration Binary integration   Object + Object Component + Component != Object == Component  Connection through  Connection through references composition  (homogeneous)  heterogeneous  white-box re-use through  black-box re-use inheritance Klasse Komponente 97

  26. Component Granularity cost-effectiveness of use and reuse match to requirements, flexibility/speed of change Proportion of application addressed by component 0 100% Routine/ Coarse-grained Application Program/ operation component package class 98

  27. Component lifecycle Component Model Component-based Architecture for field devices Component Composition Run-time Repository environment environment 101

  28. Enterprise Java Beans: Ziele  EJB as integration technology  The following concepts are most relevant:  EJB – Enterprise Java Beans,  RMI – Remote Method Invocation,  JNDI – Java Naming and Directory Interface,  JMS – Java Messaging Service,  JDBC – Access to databases,  SQLJ – static embedded SQL for Java,  JDO – Java Data Objects,  J2EE Connector (for Legacy Integration),  JTS/JTA – Java Transaction Service and Java Transaction Architecture. 110

Recommend


More recommend