Transcript Document 7195836

Middleware
(contd.)
1
What are the benefits of
middleware?
• Simplicity:
– In today's corporate computing environments, many applications
have to share data.
– Putting middleware in the middle can mean each application
needs only one interface—to the middleware—instead of a
separate interface to each application it needs to talk to.
– (However, if you're connecting just two applications to one
another, it might actually be more complicated to introduce
middleware than simply coding the two apps to talk to each
other.)
• Persistence: Middleware can capture data and hold on
to it until it has been recorded appropriately by all the
applications or databases that need the information.
2
What are the benefits of
middleware? (contd.)
• Services:
– If your data needs to be checked for integrity, printed
out, reconciled with data from other applications,
merged, split or reformatted, various kinds of
middleware can handle those tasks efficiently.
• This means you don't have to rewrite those services again
and again for each application that uses them.
– As middleware products evolve, the breadth of
services they can provide grows.
– Incidentally, vendors that sell such robust products
often try to disassociate themselves with the term
middleware.
3
Distributed Objects and
Distributed Processing
• Distributed objects have the biggest potential to solve a wide range
of challenges faced by designers of large software systems.
• Some of these challenges include
– component packaging,
– cross-language interoperability,
– interprocess communication, and
– intermachine communication.
• We separate distributed object architectures into two categories:
– component architectures and
– remoting architectures.
• Component architectures focus primarily on component packaging
and cross-language interoperability.
• Remoting architectures focus primarily on support for remote
method invocation on distributed objects.
4
Main Remoting Architectures
• Open Software Foundation’s (OSF) Distributed Computing
Environment (DCE)
– which actually is a distributed processing environment based on
the Remote Procedure Call (RPC) paradigm (purely procedural)
• Object Management Group’s (OMG) Common Object Request
Broker Architecture (CORBA).
– The notion of component packaging and deployment has only
recently been added to CORBA 3.0.
5
DCE Architecture and Services
6
The Object Management
Architecture
7
Component Architectures of
distributed systems
• Microsoft’s Component Object Model (COM)
– addresses packaging and deployment of binary component as
well as cross-language interoperability
• JavaBeans and Enterprise Java Beans (EJB) component models
introduced by SUN Microsystems.
• Both, COM and EJB address remoting to some extend:
– the COM model has been extended to Distributed COM
(DCOM) using an extended version of DCE RPC as transport.
– EJB supports client/server communication based on Java
Remote Method Invocation (RMI).
– RMI is special as it integrates closely with the Java language
without requiring a special Interface Definition Language (IDL)
to describe component interfaces accessible for remote
invocations.
• In an evolutionary sense, Microsoft’s .NET is the newest and most
advanced component architecture available in the market today.
8
Types of middleware
1. Remote Procedure Call (RPC)
Historic interest
2. Object-Oriented Middleware (OOM)
Java RMI
CORBA
Reflective Middleware
3. Message-Oriented Middleware (MOM)
Java Message Service
IBM MQSeries
Web Services
4. Event-Based Middleware
Cambridge Event Architecture
9
Remote Procedure Calls
• Remote Procedure Calls (RPCs) enable the logic of an
application to be distributed across the network.
• Most prominent examples:
– SUN RPC, introduced with the network file system (SUN
NFS),
– DCE RPC, served as technical foundation of Microsoft’s
COM.
• Object Request Brokers (ORBs) enable the objects that
comprise an object-oriented application to be distributed and
shared across heterogeneous networks.
– Extending the procedural programming model of RPC,
– Distributed object systems such as CORBA, DCOM, .NET,
and EJB enable processes to be run anywhere in the
10
network.
Remote Procedure Call (RPC)
•
•
•
•
Masks remote function calls as being local
Client/server model
Request/reply paradigm usually implemented with message passing
Marshalling of function parameters and return value
Caller
call(…)
RPC Service
1) Marshal args
2) Generate ID
3) Start timer
8) Unmarshal
9) Acknowledge
RPC Service
message
4) Unmarshal
5) Record ID
Remote
Function
fun(…)
6) Marshal
7) Set timer
11
Properties of RPC
 Language-level pattern of function call
• easy to understand for programmer
 Synchronous request/reply interaction
• natural from a programming language point-ofview
• matches replies to requests
• built in synchronisation
 Distribution transparency
• hides the complexity of a distributed system
 Various reliability guarantees
• deals with some distributed systems aspects of
failure
12
Disadvantages of RPC
 Synchronous request/reply interaction
• tight coupling between client and server
• may block for a long time
• leads to multi-threaded programming
 Distribution Transparency
• Not possible to mask all problems
fork(…)
remote call
join(…)
 Lacks notion of services
• programmer not interested in server but in service
 RPC paradigm is not object-oriented
• invoke methods on objects as opposed to functions on
servers
13
Object-Oriented Middleware (OOM)
•
•
•
•
Objects can be local or remote
Object references can be local or remote
Remote objects have visible remote interfaces
Masks remote objects as being local using proxy
objects
• Remote method invocation
local
object A
proxy
object B
OOM
object
request
broker
/
object
manager
OOM
object
request
broker
/
object
manager
remote
skeleton
object B
object B
14
Properties of OOM
 Support for object-oriented programming model
• objects, methods, interfaces, encapsulation, …
• exceptions
 Location Transparency
• mapping object references to locations
 Synchronous request/reply interaction
• same as RPC
 Services
15
Java Remote Method Invocation
(RMI)
• Distributed objects in Java
public interface PrintServer extends Remote {
int print(Vector printJob) throws RemoteException;
}
• RMI compiler creates proxies and skeletons
• RMI registry used for interface lookup
16
CORBA
• Common Object Request Broker Architecture
– Open standard by the OMG (Version 3.0)
– Language- and platform independent
• Object Request Broker (ORB)
– General Inter-ORB Protocol (GIOP) for communication
– Interoperable Object References (IOR) contain object location
– CORBA Interface Definition Language (IDL)
• Stubs (proxies) and skeletons created by IDL
compiler
– Dynamic remote method invocation
• Interface Repository
– Querying existing remote interfaces
• Implementation Repository
– Activating remote objects on demand
17
CORBA IDL
• Definition of language-independent remote interfaces
– Language mappings to C++, Java, Smalltalk, …
– Translation by IDL compiler
• Type system
– basic types: long (32 bit), typedef sequence<string> Files;
long long (64 bit), short,
interface PrintServer : Server {
void print(in Files printJob);
float, char, boolean,
};
octet, any, …
– constructed types: struct, union, sequence, array, enum
– objects (common super type Object)
• Parameter passing
– in, out, inout
– basic & constructed types passed by value
– objects passed by reference
18
CORBA Services
• Naming Service
– Names  remote object references
• Trading Service
– Attributes (properties)  remote object references
• Persistent Object Service
– Implementation of persistent CORBA objects
• Transaction Service
– Making object invocation part of transactions
• Event Service and Notification Service
– Asynchronous communication based on messaging
(cf. MOM)
19
Disadvantages of OOM
 Synchronous request/reply interaction
• So CORBA oneway semantics added and • Asynchronous Method Invocation (AMI)
• But implementations may not be loosely coupled
 Distributed garbage collection
• Releasing memory for unused remote objects
 OOM rather static and heavy-weight
• Bad for ubiquitous systems and embedded devices
20
Reflective Middleware
• Flexible middleware (OOM) for mobile and contextaware applications
• Interfaces for reflection
– Objects can inspect middleware behaviour
• Interfaces for customizability
– Dynamic reconfiguration depending on environment
– Different protocols, QoS, ...
– e.g. use different marshalling strategy over unreliable
wireless link
21
Message-Oriented Middleware (MOM)
•
•
•
•
Communication using messages
Messages stored in message queues
Optional message server decouples client and server
Various assumptions about message content
Client App.
Server App.
Message Server
local message
queues
message
queues
local message
queues
Network
Network
Network
22
Properties of MOM
 Asynchronous interaction
– Client and server are only loosely coupled
– Messages are queued
– Good for application integration
 Support for reliable delivery service
– Keep queues in persistent storage
 Processing of messages by intermediate message
server
– Filtering, transforming, logging, …
– Networks of message servers
 Natural for database integration
23
IBM MQSeries
• One-to-one reliable message passing using queues
– Persistent and non-persistent messages
– Message priorities, message notification
• Queue Managers
– Responsible for queues
– Transfer messages from input to output queues
– Keep routing tables
• Message Channels
– Reliable connections between queue managers
• Messaging API:
MQopen Open a queue
MQclose Close a queue
MQput
Put message into opened queue
MQget
Get message from local queue
24
Java Message Service (JMS)
• API specification to access MOM implementations
• Two modes of operation:
– Point-to-point
• One-to-one communication using queues
– Publish/Subscribe
• cf. Event-Based Middleware
• JMS Server implements JMS API
• JMS Clients connect to JMS servers
• Java objects can be serialised to JMS messages
25
Disadvantages of MOM
 Poor programming abstracting
• Rather low-level (cf. Packets)
• Results in multi-threaded code
• Request/reply more difficult to achieve
 Message formats unknown to middleware
• No type checking
 Queue abstraction only gives one-to-one
communication
• Limits scalability
26
Web Services
• Use well-known web standards for distributed computing
Communication
• Message content expressed in XML
• Simple Object Access Protocol (SOAP)
– Lightweight protocol for sync/async communication
Service Description
• Web Services Description Language (WSDL)
– Interface description for web services
Service Discovery
• Universal Description Discovery and Integration (UDDI)
– Directory with web service description in WSDL
27
Properties of Web Services
 Language-independent and open standard
 SOAP is best of both worlds:
• Synchronous request/reply like OOM
• Asynchronous messaging like MOM
• Supports internet transports (http, smtp, ...)
• Uses XML Schema for marshalling types
http://api.google.com/GoogleSearch.wsdl
 WSDL says how to use a web service
 UDDI helps to find the right web service
• Exports SOAP API for access
28
Event-Based Middleware
• Publishers publish events (messages)
• Subscribers express interest in events with subscriptions
• Event Service notifies interested subscribers of
published events
• Events can have arbitrary content or name/value pairs
Publisher
Publisher
Publisher
subscribe
publish
Event Service
publish
publish
notify
subscribe
notify
subscribe
notify
Subscriber
Subscriber
Subscriber
29
Topic-Based and ContentBased Pub/Sub
• Event Service matches events against subscriptions
• Topic-Based
What do subscriptions
look like?
Publish/Subscribe
– Publishers publish events belonging to topic or subject
– Subscribers subscribe to topic
subscribe(PrintJobFinishedTopic, …)
Content-Based Publish/Subscribe
– Publishers publish arbitrary events
– Subscribers provide a filter based on content of events
subscribe(type=printjobfinshed,
printer=‘aspen’, …)
• […]
30
Properties of Publish/Subscribe
 Asynchronous communication
 Publishers and subscribers are loosely coupled
 Many-to-many interaction between publishers and
subscribers
 Scalable scheme for large-scale systems
 Publishers do not need to know subscribers
 Content-based pub/sub very expressive
 Information delivered to all interested parties
31
Cambridge Event Architecture
(CEA)
• Publish-Register-Notify Paradim
– Standard middleware for building event-based
systems
– Direct communication between pubs and subs
– Event Mediators decouple pubs and subs
– Source-side filtering of events
event PrinterJobFinished {
String printer;
String printFile;
int userID;
}
• Events are typed messages
– Attributes for content-based pub/sub filtering
32
History and intro to CORBA
• CORBA is a standard for object interoperability
– Support for different languages
– Support for different platforms
– Communications over the network
– Additional services (e.g., security)
• CORBA is defined by the OMG (Object Management
Group)
– Begin since 1989
– CORBA 1 was in 1991
– Now, toward to CORBA 3
– More information: http://www.omg.org
• CORBA is a component of OMA (Object Management
Architecture)
33
What is the OMA?
• Object Model and Interfaces (e.g., Domain Interfaces,
Application Interfaces)
– Defines what a CORBA object is
• Common Object Request Broker Architecture
(CORBA)
– Standard for an ORB (Object Request Broker)
– Defines the IIOP (Internet Inter-ORB Protocol) -the standard for communication
– Defines the Language interfaces and tools
34
What is the OMA?
• Object Services -- common services
– Core services required to develop distributed
architectures
– Naming -- allowing clients to find objects based on
names
– Trading -- allowing clients to find objects based on their
properties
– Others: Security, Transactions, event notification, .
• Common Facilities -- high-level services
– e.g., Distributed Document Component Facility (DDCF)
-- OpenDoc
• Allowing for the presentation and interchange of
objects based on a document model facilitating the
linking of a spreadsheet object into a report
35
document
Some ORBs
• CORBA Software
(http://www.infosys.tuwien.ac.at/Research/Corba/softwar
e.html)
– Orbix (IONA)
– VisiBroker (Inprise)
– ObjectBroker (BEA)
– PowerBroker (Expersoft)
– ORB Plus (HP)
– ORBacus (Object-Oriented Concepts, Inc.)
– NEO/JavaIDL (SunSoft)
36
Why CORBA?
• Need to share information and
resources within and across diverse
computing enterprises
– CORBA is a Middleware Standard
– CORBA is a “Software Bus”
– CORBA is a Distributed Object
Architecture
37
CORBA is a Middleware
Standard
• Before CORBA, middleware was dominated by
proprietary tools
• CORBA provides a standard that allows you to:
– Develop applications using a common basis
– Change CORBA products with minimal rewriting of
code
– Make objects running on different CORBA products
interoperate
– Integrate third-party products that respect the
standard
• CORBA is evolving to standardize other types of
38
middleware
CORBA and the “Software Bus”
•
•
A standard architecture enabling you to plug components into
– Support different languages and platforms
– Connects everything up in a single architecture
A basis for delivering reusable components
– A CORBA component can be accessed from any client technology
– A CORBA components has a clearly defined interface
39
* Source: Java-CORBA E. Arch., expede.com
CORBA and Distributed Architectures
* Source: Java-CORBA E. Arch., expede.com
40
How Does CORBA Work?
• Step 1: Write a specification for each object
using IDL (Interface Definition Language)
• Step 2: Compile the IDL to generate client stub
and server skeleton code
• Step 3: Write the client application code.
• Step 4: Write the server object code.
• Step 5: Compile the client and server code
• Step 6. Start the server
• Step 7: Run the client application
* Source: Visibroker Progammer’s Guide
41
1
2
3
4
5
* Source: Visibroker Progammer’s Guide
42
* Source: Visibroker Progammer’s Guide
43
* Source: Visibroker Progammer’s Guide
44
What are considerations for
using CORBA?
•
•
•
•
Security
Performance
Fault-Tolerance
Scalability
45
CORBA 3.0
• Provides well-defined packaging for producing
components, quality of service, messaging
and other technologies
• Full Java and Internet support
– Java portability, XML integration
• Quality of Service management
– Messaging, Realtime, Small footprint
• Distributed Component Model
– Component-based development, scripting
* Source: Soley, OMG
Recent CORBA 3.0 Additions
• CORBA Component Model (CCM) –
– introduces the notion of server-side components into CORBA
and addresses packaging and deployment for CORBA
components.
– CCM provides for interoperability with EJB.
• Objects passable by value (valuetypes) –
– valuetypes definitely improve integration with Java and also
serve as basis for the XML/Value mapping (released as part of
CORBA 2.3).
• Java-to-IDL Mapping –
– this mapping allows Java RMI objects to interoperate over the
network like CORBA objects using CORBA object references.
• XML/Value mapping –
– standardizes the representation of an XML document as a
collection of native CORBA types.
• CORBA Firewall Specification –
– allows firewalls to be configured for CORBA using access rules 47
for IIOP traffic.
CORBA 3.0 Additions
• CORBA Messaging –
– encompasses both asynchronous and messaging-mode
invocations of CORBA objects as well as Quality of Service
Control.
• Real-Time CORBA –
– extends the CORBA architecture with resource control
mechanisms for real-time applications running on a real-time
operating system in a controlled environment.
• Fault-Tolerant CORBA –
– standardizes redundant software configurations and systems
that give CORBA robust and reliable performance (when run on
redundant hardware).
• Minimum CORBA –
– defines a small-footprint CORBA configuration that is aimed at
48
embedded and card-based systems.
COM Characteristics
• COM is a very mature component architecture that has
many strengths.
– Thousands of third-party ActiveX controls (in-process
COM components) are available in the market today.
– Microsoft and other vendors have built many tools
that accelerate development of COM-based
applications.
• Advanced services such as Microsoft Transaction
Server (MTS) and Microsoft Message Queuing Server
(MSMQ) support development of enterprise multi-tier
systems.
– Microsoft has been using the name COM+ to identify
the bundling of the COM runtime with those services.
49
Microsoft .NET Framework
50
.NET Characteristics
•
•
•
•
•
Distributed Computing:
– .NET provides a remoting architecture that exploits open Internet
standards, including the Hypertext Transfer Protocol (http), Extensible
Markup Language (XML), and Simple Object Access Protocol (SOAP).
Componentization:
– .NET extends the previous COM component model but provides a
significantly simpler way to build and deploy components.
Enterprise services:
– .NET supports the development of scalable enterprise applications
without writing code to manage transactions, security, or pooling.
Web paradigm shifts:
– Over the last few years, web application development has shifted from
connectivity (TCP/IP), to presentation (HTML), to programmability
(XML and SOAP). .NET enables software to be sold and distributed
as a service.
Maturity factors:
– Although .NET is a relatively new framework, it builds upon the mature
COM+ technology and services.
51
Future Trends: Resource Management
and Quality-of-Service
• Middleware abstractions provide resource management in a
distributed system at a high level.
– OS manages: communication, processing, storage
(memory/disks).
– Middleware abstractions also are from an end-to-end
perspective, not just of a single host, which allows for a more
global and complete view to a resource management system.
– Distributed objects are promising, as they not only encapsulate
but also cleanly integrate all three kinds of resource into a
coherent package.
– This completeness helps distributed resource management and
makes it easier to provide for load balancing, mobility
transparency, and overall system reliability.
52
New Capabilities
• Recent middleware frameworks, like the CORBA 3.0 Component
Model (CCM), or the Microsoft .NET framework, allow the
expression of non-functional component properties.
– such as resource requirements, timing and security constraints,
or fault-tolerance assumptions on the component level using
language constructs (like C# and .NET attributes) or component
meta-data (like CCM’s deployment descriptors).
• Aspect-Oriented Programming (AOP) is a relatively new discipline
that focuses on cross-cutting concerns
– targeting many components of a system simultaneously and
– non-functional component properties.
• AOP investigates software engineering approaches towards
predictable component-based systems.
– This research opens up new venues for middleware-based
architectures on the enterprise level.
53
References
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
OMG: www.omg.org/middleware/
NSF: www.nsf-middleware.org/Middleware/
CMU: www.sei.cmu.edu/str/descriptions/middleware.html
Resource center: www.middleware.org/
kbs.cs.tu-berlin.de/teaching/ ws2001/cl/middleware_4.pdf
Bernstein, Philip A. "Middleware: A Model for Distributed Services." Communications of the ACM
39, 2 (February 1996): 86-97.
"Middleware Can Mask the Complexity of your Distributed Environment." Client/Server Economics
Letter 2, 6 (June 1995): 1-5.
courses.cs.tamu.edu/cpsc689/hohin/ fall00/notes
http://www.darwinmag.com/learn/curve/column.html?ArticleID=93
www.ics.uci.edu/~muccini/ics123
http://www.iona.com/hyplan/vinoski/pdfs/IEEE-Where_is_Middleware.pdf
Internet2: middleware.internet2.edu
dsonline.computer.org/middleware/RM.htm
www.cl.cam.ac.uk/Teaching/2003/ DistSys
Eckerson, Wayne W. "Three Tier Client/Server Architecture: Achieving Scalability, Performance,
and Efficiency in Client Server Applications." Open Information Systems 10, 1 (January 1995):
3(20).
Schreiber, Richard. "Middleware Demystified." Datamation 41, 6 (April 1, 1995): 41-45.
lass.cs.umass.edu/~shenoy/courses/ spring02/lectures
54