1. Middleware (contd.)

2. 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.

3. 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.

4. 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.

5. 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.

6. DCE Architecture and Services

7. The Object Management Architecture

8. 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.

9. 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

10. 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 network.

11. 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
RPC Service
RPC Service
Remote
Function
1) Marshal args
2) Generate ID
3) Start timer
message
4) Unmarshal
5) Record ID
call(…)
fun(…)
8) Unmarshal
9) Acknowledge
6) Marshal
7) Set timer

12. Properties of RPC Language-level pattern of function call
easy to understand for programmer
Synchronous request/reply interaction
natural from a programming language point-of-view
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

13. 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
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
fork(…)
remote call
join(…)

14. 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
OOM
OOM
remote
object
request
broker /
manager
object
request
broker /
manager
object A
skeleton
object B
proxy
object B
object B

15. 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

16. 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

17. CORBA Stubs (proxies) and skeletons created by IDL compiler
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

18. 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), long long (64 bit), short, 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
typedef sequence<string> Files;
interface PrintServer : Server {
void print(in Files printJob); };

19. 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)

20. 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

21. Reflective Middleware
Flexible middleware (OOM) for mobile and context-aware 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

22. 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

23. 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

24. IBM MQSeries MQopen Open a queue MQclose Close a queue MQput
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

25. 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

26. 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

27. Web Services Communication Message content expressed in XML
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

28. 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
WSDL says how to use a web service
UDDI helps to find the right web service
Exports SOAP API for access

29. 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
subscribe
publish
Publisher
Subscriber
notify
Event Service
subscribe
Publisher
publish
Subscriber
notify
subscribe
Publisher
publish
Subscriber
notify

30. Topic-Based and Content-Based Pub/Sub
Event Service matches events against subscriptions
What do subscriptions look like?
Topic-Based 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’, …)
[…]

31. 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

32. 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
Events are typed messages
Attributes for content-based pub/sub filtering
event PrinterJobFinished {
String printer;
String printFile;
int userID; }

33. 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:
CORBA is a component of OMA (Object Management Architecture)

34. 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

35. 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 document

36. Some ORBs
CORBA Software (
Orbix (IONA)
VisiBroker (Inprise)
ObjectBroker (BEA)
PowerBroker (Expersoft)
ORB Plus (HP)
ORBacus (Object-Oriented Concepts, Inc.)
NEO/JavaIDL (SunSoft)

37. 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

38. 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 middleware

39. 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
* Source: Java-CORBA E. Arch., expede.com

40. CORBA and Distributed Architectures
* Source: Java-CORBA E. Arch., expede.com

41. 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

42. 1 2 3 4 5
* Source: Visibroker Progammer’s Guide

43. * Source: Visibroker Progammer’s Guide

44. * Source: Visibroker Progammer’s Guide

45. What are considerations for using CORBA?
Security
Performance
Fault-Tolerance
Scalability

46. 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

47. 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 for IIOP traffic.

48. 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 embedded and card-based systems.

49. 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.

50. Microsoft .NET Framework

51. .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.

52. 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.

53. 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.

54. References OMG: www.omg.org/middleware/
NSF:
CMU:
Resource center:
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):
"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
Internet2: middleware.internet2.edu
dsonline.computer.org/middleware/RM.htm
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):
lass.cs.umass.edu/~shenoy/courses/ spring02/lectures