1 / 29

Distributed Components

Distributed Components. Week 6 – Lecture 2. A component request consists of three parts. The name of the component The service to be performed The list of parameters. Messages containing the request have to be passed between the client host and the server host. To achieve this. We need

nola
Download Presentation

Distributed Components

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 Components Week 6 – Lecture 2

  2. A component request consists of three parts • The name of the component • The service to be performed • The list of parameters Messages containing the request have to be passed between the client host and the server host.

  3. To achieve this • We need • To identify the host and process that can provide the service • To transfer messages to/from the requesting process in one host from/to the serving process in another host reliably and quickly • The messages to be understood – both syntax and semantics.

  4. Distributed component requests have a lot of work to do • Find the host for the process (resource discovery) • Resolve data heterogeneity • Synchronise client and server (parallelism) • Transfer messages across the network • Start the process if it is not active (and deactivate it afterwards) • Handle errors

  5. Eight layers of Transparency • Access • Location • Migration • Replication • Concurrency • Scalability • Performance • Failure

  6. Six different approaches • Load balancing • Transaction oriented middleware • Message oriented middleware (MOM) • Remote Procedure Calls (RPCs) • Distributed Objects/Components • WEB Services • GRID computing

  7. Load balancing • DNS Round Robin • Front end hardware • Cluster software

  8. Front end hardware • Rule based work allocation • Failover • SSL and TCP connections • Geographic load balancing • Ping client to establish latency Router Load balancer Servers

  9. Cluster software – Windows 2000 Router Web Application server host Database server hosts Shared storage

  10. Cluster host – Windows 2000 • Lives in each cluster host • Each host sends heart beat message • Rule/statistical work allocation • Failover • Redundancy • To 32 hosts in a cluster • Virtual IP address Network adaptor Load balancer TCP/IP Server application

  11. Transaction Oriented Middleware • Often called TP monitors • Optimised for high volume transaction processing • Most common products are IBM CICS and BEA Tuxedo • Supports transaction integrity across different distributed databases • To update two or more databases in the one transaction, a two phase commit is required

  12. Transactional integrity requires • ACID • Atomicity – all parts of the transaction must be completed or none at all – rolled back • Consistency – the database must move from one consistent state to another • Isolation – each transaction must be completed as if it were running alone (even though multiple transactions are being processed simultaneously). Record locking. • Durability – one the transaction is complete and committed then it must not be lost. Buffers must be flushed. Log is kept to allow roll forward from a back-up

  13. Database commit • The DBMS holds a copy of the records being updated, and if the transaction fails, then the records that have been changed are rolled back to the position they were in before the update commenced • The DBMS can look after transactional integrity for any one database, but if two databases are being updated, then a second phase of the commit process needs to occur. • The TP Monitor looks after the second phase

  14. Enrolment process Student Records DB Server HECS Database DB Server

  15. TP Monitors also provide • Fault tolerance • Load balancing • Support for thousands of users, providing short response times & high throughput • Support for multiple servers • Security

  16. Message Oriented Middleware • Exchanges messages between processes asynchronously • It uses a queue, the client(s) places the message on the queue, and the server(s) takes it off • Often used to integrate applications • It provides a neutral IDL, often XML, to support heterogeneity • The queue means that the target can be more or less transparent to the client or sender. • It can add another server process if the queue builds up • Supports persistent messages for TP applications • IBM’s MQ series is the leader, supporting 35 platforms

  17. Client processes Server Processes Queue

  18. RPCs - Remote Procedure Calls • Uses a synchronous model – i.e. the client issues the request and waits for the response before proceeding • Invented by Sun in the early 80s and adopted by the Distributed Computing Environment (DCE) & X/Open • Tends to have a low level of abstraction. Needs to be coded explicitly • Includes an IDL – this layer resolves heterogeneity • Each host that supports RPC runs a daemon called PORTMAP. Servers register their programs with PORTMAP thus clients can find the server host on a network

  19. Remote Procedure Call Process On Host A Process on Host B Application layer Stub & IDL Stub & IDL portman Presentation Session Binding can be static Or dynamic Server process can be Active or on demand Data heterogeneity - IDL Marshalling & unmarshalling - complex data structures into byte streams

  20. Distributed Component Architectures or Object Oriented middleware • Evolved from RPCs • Three main approaches • OMGs Common Object Request Broker (CORBA) • Microsoft’s Component Object Model (COM) now COM+ • Sun’s Remote Method Invocation for Java (RMI)

  21. Each tends to be appropriate for a particular situation • CORBA is more appropriate for mission critical, high availability applications probably on mainframes and large Unix machines • Java would probably be the choice for internet applications that need to be portable across a wide range of platforms • COM+ would be the choice for applications implemented on Windows operating systems

  22. A detailed discussion of each would require us all to be familiar with object oriented terminology and programming.Those with that knowledge should read chapter 3 & 4 in Emmerich

  23. There are important differences • COM+ was developed by Microsoft to support binary encapsulation and binary compatibility • COM+ dependent on Windows O/S • Java/RMI was developed by Sun to support distributed objects in different Java Virtual Machines. The Java VM resolves heterogeneity • Sun also offers Jini and Enterprise Javabeans (EJB) which provide higher level services particularly for Transaction processing

  24. History: COM+ and .NET • Evolution • COM released in 1993 • DCOM, MTS and DTC introduced in 1996, • MSMQ introduced in 1997. • COM+ bundled these services in 1999. • Application Servers introduced in 2000. • Owned and Controlled by Microsoft • Integrated into the Windows platform since 2000. • COM+ provides the programming model and runtime component services for building and executing scalable server-side component applications. • The .NET platform provides a framework designed to simplify application development in the highly distributed environment of the Internet Accenture 2001

  25. History: EJB / J2EE • Evolution • Java’s first commercial release in 1996. • Just In Time (JIT) Compilers 1997. • Specialty Frameworks 1998 • EJB introduced in 1999. J2EE in 2000. • Owned and controlled by Sun • Based on family of specifications that any company can license and implement • Supports Client and Server side services for distributed applications, with strong heritage on the mid-range environment. Accenture 2001

  26. History: CORBA • “Common Object Request Broker Architecture” • Specification introduced in 1991 • predates WWW • Created by Object Management Group (OMG), a consortium of over 500 companies • Commercial solutions not real until 1993. • Specification for building objects that communicate across a network • Quote from OMG - “Allows applications to communicate with one another no matter where they are located or who has designed them” Accenture 2001

  27. Why CORBA can’t compete… • CORBA is a documented standard, not an implementation – Implementations vary by vendor. • Has difficulty responding to today’s rapid rate of change. New version release rate is slow due to the standards body that governs changes to the standard. • CORBA - “purist” rather than “pragmatic” platform for development • Results in a complex programming environment, too complex for average enterprise-level development. • Lacks services now demanded by the market • Commerce Servers, Web Services Accenture 2001

  28. WEB Services • Builds on the WEB basics of HTTP etc • Uses XML rather than HTML to give semantic meaning to the data being exchanged • UDDI (Universal Description Discovery Integration) to describe services • WSDL (WEB Service Description Language) • SOAP (Simple Object Access Protocol)

  29. SOAP • Simple Object Access Protocol • Lightweight, XML based protocol • It has three segments • An envelope defining a framework for describing a message’s content • A set of rules for encoding application data • A convention for representing RPC and responses • Used by Microsoft, Sun and IBM

More Related