distributed components

29
Distributed Components Week 6 – Lecture 2

Upload: nola

Post on 12-Jan-2016

39 views

Category:

Documents


0 download

DESCRIPTION

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 - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Distributed Components

Distributed Components

Week 6 – Lecture 2

Page 2: Distributed Components

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 theclient host and the server host.

Page 3: Distributed Components

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.

Page 4: Distributed Components

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

Page 5: Distributed Components

Eight layers of Transparency

• Access• Location• Migration• Replication• Concurrency• Scalability• Performance• Failure

Page 6: Distributed Components

Six different approaches

• Load balancing

• Transaction oriented middleware

• Message oriented middleware (MOM)

• Remote Procedure Calls (RPCs)

• Distributed Objects/Components

• WEB Services

• GRID computing

Page 7: Distributed Components

Load balancing

• DNS Round Robin

• Front end hardware

• Cluster software

Page 8: Distributed Components

Front end hardware

• Rule based work allocation

• Failover

• SSL and TCP connections

• Geographic load balancing

• Ping client to establish latency Router

Load balancer

Servers

Page 9: Distributed Components

Cluster software – Windows 2000

Router

WebApplicationserver host

Databaseserver hosts

Shared storage

Page 10: Distributed Components

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

Page 11: Distributed Components

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

Page 12: Distributed Components

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

Page 13: Distributed Components

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

Page 14: Distributed Components

StudentRecords

DB Server

HECSDatabase

DB Server

Enrolmentprocess

Page 15: Distributed Components

TP Monitors also provide

• Fault tolerance

• Load balancing

• Support for thousands of users, providing short response times & high throughput

• Support for multiple servers

• Security

Page 16: Distributed Components

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

Page 17: Distributed Components

Clientprocesses

ServerProcesses

Queue

Page 18: Distributed Components

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

Page 19: Distributed Components

Stub & IDL Stub & IDLportman

PresentationSession

ProcessOn Host A

Process onHost BApplication layer

Remote Procedure Call

Data heterogeneity - IDLMarshalling & unmarshalling - complex data structures into byte streams

Binding can be staticOr dynamic

Server process can beActive or on demand

Page 20: Distributed Components

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)

Page 21: Distributed Components

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

Page 22: Distributed Components

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

Page 23: Distributed Components

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

Page 24: Distributed Components

History: COM+ and .NETHistory: 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

Page 25: Distributed Components

History: EJB / J2EEHistory: 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

Page 26: Distributed Components

History: CORBAHistory: 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

Page 27: Distributed Components

Why CORBA can’t compete…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

Page 28: Distributed Components

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)

Page 29: Distributed Components

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