Download Chapter 11-middleware

DISTRIBUTED COMPUTING
MIDDLEWARE
Chapter 11
Distributed Computing Systems
Distributed Computing Systems Overview
• Distributed Computing Middleware
• Distributed Computing Environment (DCE)
• Common Object Request Broker Architecture (CORBA)
• Java and Remote Method Invocation (RMI)
• Metacomputing – middleware for high-performance
distributed computing
• Research projects around the world
• Nexus
• Globus
• WWW technologies for DHPC
What is Middleware?
• Various meanings, but generally a higher-level software
layer that provides a standardised interface to a
collection of distributed, disparate, proprietary,
non-standardised programs, services, etc.
• Developers write applications that interface to the
middleware, rather than multiple lower-level interfaces.
• Software “glue” to join together different parts of an
application.
• Connectivity software for distributed systems,
abstracting over differences in lower-level layers such as
network protocols and operating systems.
• Used to specifically enable distributed computing across
different platforms.
• Enhances portability and functionality, but often at the
expense of performance.
Examples of Middleware
• Database connectivity products - e.g. ODBC, Java’sdatabase connectivity API (JDBC).
• Remote computation products - e.g. remote procedurecall (RPC) and Java Remote Method
Invocation (RMI).
• Message-oriented middleware - e.g. messaging systemssuch as Isis and Horus are more
robust and fault-tolerantpackages than raw MPI or PVM, targeted more at distributed
computing rather than parallel computing.
• Distributed Computing Environment (DCE) products.
• Object Request Brokers - e.g. CORBA.
• Microsoft’s COM and ActiveX.
• Java Jini.
• The World Wide Web is probably the most widely used
middleware system - defines a standard high-level
message-passing protocol (HTTP), a mechanism for
addressing remote files from any computer (URL), a
mechanism for invoking remote procedure calls (CGI),
and data formatting standards (HTML and XML).
• Web browsers are becoming a standard interface foraccessing and viewing documents
(using plug-ins or external viewers).
IDC Report on Middleware
International Data Corporation Report (HPCWire, Sept. 97)
• Middleware - future of distributed business applications;
• Spares business applications developers from each network
technologies idiosyncrasies.
• Total (middleware) markets US$5.275 billion by 2001 (416%
growth).
• Distributed programs talk to middleware not network.
• Middleware markets:
– desktop access;
– data access (largest market area through 2001);
– remote procedure call;
– message oriented (growing, due to application integration
needs);
– distributed transaction processing;
– object (fastest growth).
• Middleware consumption highest in multiuser Unix OS
environments.
• Internet is key factor.
• Need for two way scalability.
• Renewed respect for legacy systems.
• Application integration requirements.
• Household name vendor impact (IBM, Microsoft, Sun, Oracle,
BEA Systems, TIBCO, Sybase and Intersolv)
DH
PC
Distributed Computing Systems
Technical Issues for a DHPC Middleware
• Latencies over long distances.
• Remote access/invocation - action at a distance.
• Exploit legacy (and high-performance) compute
platforms.
• Integrate storage with compute (large timely data sets).
• Put high bandwidth where it can make a difference.
• Services approach - high granularity to alleviate
overheads and latencies.
• Port or build new codes, or use wrappers?
• How to “glue” together legacy applications?
• What do you build glue from? - Java and CORBA.
Distributed Computing Environment
The Distributed Computing Environment (DCE) is a software system developed in the early
1990s by a consortium that included Apollo Computer (later part of Hewlett-Packard), IBM,
Digital Equipment Corporation, and others.
The DCE supplies a framework and toolkit for developing client/server applications.
The framework includes a remote procedure call (RPC) mechanism known as DCE/RPC,
a naming (directory) service, a time service, an authentication service and a distributed file
system (DFS) known as DCE/DFS.
• DCE has multiple components integrated to work closely together:
– Remote Procedure Call (RPC);
– Cell and Global Directory Services (CDS and GDS);
– Security Service;
– DCE Threads;
– Distributed Time Service (DTS);
– Distributed File Service (DFS) - Optional.
• DCE is distributed computing “middleware” or “enabling technology”
• not intended to exist alone
• should be integrated or bundled into a vendor’s operating system
• DCE security and distributed filesystem can completely replace vendor’s non-network
analogs.
• O’Reilly books - Understanding DCE by Rosenberry etal.
• http://www.opengroup.org/tech/dce/
• DCE developed out of Kerberos research project
• Produced by Open Software Foundation - group of companies
• cell concept - manageable local set of resources – trusted and local
• servers and services concepts - service replication
• intra cell services - standalone unit
• inter cell services for wide areas and across trust
boundaries
• RPC and interface definition layers (see RPCs) and application programming interface
• good functionality but products tend to be cumbersome, and slow
• has limitations, some products not fully defined/implemented
• DCE and specific DCE products (e.g. security service) still used but most distributed
computing applications are now being developed using CORBA and Java
• A lot of ideas in CORBA are based on DCE, but with an O-O flavour
CORBA
The Common Object Request Broker Architecture (CORBA) is a standard defined by
the Object Management Group (OMG) that enables software components written in
multiple computer languages and running on multiple computers to work together, i.e. it
supports multiple platforms.
- CORBA is a mechanism in software for normalizing the method-call semantics between
application objects that reside either in the same address space (application) or remote address
space (same host, or remote host on a network).
- Version 1.0 was released in October 1991.
- CORBA uses an interface definition language (IDL) to specify the interfaces that objects will
present to the outside world.
- CORBA then specifies a “mapping” from IDL to a specific implementation language like C++
or Java.
- Standard mappings exist for Ada, C, C++, Lisp, Ruby, Smalltalk, Java, COBOL, PL/I and
Python.
- There are also non-standard mappings for Perl, Visual Basic, Erlang, and Tcl implemented by
object request brokers (ORBs) written for those languages.
CORBA vs RMI - Advantages
Advantages of Java and RMI:
• Java is a true Object-Oriented language.
• Portability.
• Can use CORBA with Java, but easier to do distributed computing in Java using RMI.
• Don’t need an ORB on client and server (but Netscape browser and JDK 1.2 now come
with built-in ORBs).
• Java is free, commercial ORBs are not (but some good free ORBs are now available for
non-commercial use).
• Lots of momentum behind Java.
Advantages of CORBA:
• Easy invocation of objects in different languages, very useful for integration of legacy
systems (main reason for development of CORBA) – Java requires wrappers and
native method invocation or system exec calls.
• Easy to extend for new languages and well specified.
• Different ORBs can communicate.
• IDL provides nice abstraction layer over operations.
• Many useful services such as Trading Service, Security
Service, etc.
• Open standard developed by international consortium.
DHPC
CORBA and Java RMI
CORBA vs RMI - Disadvantages
Disadvantages of Java:
• Implementation is still immature, specification is continually evolving.
• Still limited mainstream acceptance (but perhaps growing faster than CORBA?).
• Limited number of services, but these are being developed (e.g. security API, Java Jini for
trader services, etc).
• Portability between different JVMs (esp Sun vs Microsoft) may be a problem.
• Performance can be slow.
Disadvantages of CORBA:
• Implementations are still immature and continually evolving.
• Still limited mainstream acceptance.
• Many ORBs do not provide full functionality (of services and interfaces) of the CORBA
2.0 specification.
• Interoperability between different ORB implementations can be a problem - code written
for one ORB may need modification for use with another ORB.
• Performance can be slow.
CORBA and Java RMI
Java and CORBA
• Efforts in new versions of Java and CORBA to make the two more compatible.
• idl2java compilers provide CORBA stubs and skeletons for Java programs.
• Some ORBs are now written in Java.
• Java 1.2 provides RMI over IIOP and a very basic ORB from Sun.
• CORBA and RMI target different applications:
– CORBA is aimed at for glueing together legacy
applications that can be written in many different
languages.
– Java RMI is aimed at applications written mainly in
Java.
• A white paper on “Java, RMI and CORBA” by David
Curtis compares and contrasts Java RMI and CORBA:
http://www.omg.org/news/wpjava.htm