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. Student Records DB Server HECS Database DB Server Enrolment process

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

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