Transcript Lec 2 - The University of Sydney

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
– 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.
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
Eight layers of Transparency
•
•
•
•
•
•
•
•
Access
Location
Migration
Replication
Concurrency
Scalability
Performance
Failure
Six different approaches
•
•
•
•
•
•
•
Load balancing
Transaction oriented middleware
Message oriented middleware (MOM)
Remote Procedure Calls (RPCs)
Distributed Objects/Components
WEB Services
GRID computing
Load balancing
• DNS Round Robin
• Front end hardware
• Cluster software
Front end hardware
•
•
•
•
•
Rule based work allocation
Failover
SSL and TCP connections
Geographic load balancing
Ping client to establish latency
Router
Load balancer
Servers
Cluster software – Windows 2000
Router
Web
Application
server host
Database
server hosts
Shared storage
Cluster host – Windows 2000
•
•
•
•
•
•
•
Lives in each cluster host
Each host sends heart beat message
Rule/statistical work allocation
Failover
Network adaptor
Redundancy
Load balancer
To 32 hosts in a cluster
TCP/IP
Virtual IP address
Server application
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
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
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
Enrolment
process
Student
Records
DB Server
HECS
Database
DB Server
TP Monitors also provide
• Fault tolerance
• Load balancing
• Support for thousands of users, providing
short response times & high throughput
• Support for multiple servers
• Security
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
Client
processes
Server
Processes
Queue
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
Remote Procedure Call
Process
On Host A
Stub & IDL
Application layer
Process on
Host B
Presentation
Session
Stub & IDL
portman
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
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)
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
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
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
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

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
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
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
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)
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