Download chapter02 - GEOCITIES.ws

Chapter 2
Technologies for E-commerce
 E-commerce Models
 The Internet
Distributed Computing
Summary
 E-commerce Models
Business-to-Business
Electronic Data Interchange (EDI)
Just-in-time (JIT)
Commercial Auction
Business-to-Consumer
Online Shopping Cart
Online Banking
Person-to-person Auction
Business-to-Business
• Factors
– Just-In-Time Delivery Requirement
• Reduce Inventory, Cycle Times
• Reduced Costs
– International Trade (Globalization,
Deregulation)
– Move to Automated Transactions
– Developing Trust
• With New Partners
• Contract Protocols: Formal, Creative
– Low-Cost, Secure Large Transactions
– Sharing Minimum Required Operational
Information
Electronic Data Interchange (EDI)
• What is EDI?
– Electronic Data Interchange, or EDI, is the computer-to-computer
exchange of business documents using a standard format
– a method of transmitting business data from one computer to another,
without the need to re-key data
• Without normalization
4 companies – 12 formats for the same message
What is EDI – Normalized language
EDIFACT normalization is part of the UNO missions
EDIFACT
EDITEXT
EDISPORT
INOVERT
Orders
EFOVAD
EANCOM
Despatch Advice
ODETTE
Invoice
Transport
Automobile
Retail
Benefits of EDI
 Improves the speed of information exchanged
between companies
 Reduces operational costs
 Minimized potential for error
 Confirmation on the exchange of documents
 Minimized paper use and storage
Just-in-time (JIT)
• Try to reduce the system operational inefficiencies and the
resulting waste by identifying the sources of these inefficiencies
and working proactively to eliminate them as much as possible.
• In the emerging philosophy, inventories should be carefully
controlled and they should not function as the mechanism for
accommodating the system inefficiencies => Just-In-Time (JIT)
• The aforementioned effort should be an ongoing process
towards continuous improvement rather than one-time/shot
effort.
Just-in-time (JIT)
The financial benefits of JIT production are:
• Lower investment in inventories.
• Reduction in carrying and handling costs of inventories.
• Lower investment in plant space for inventories and
production.
• Reduction in set-up time and total manufacturing costs.
• Reduction in wastes and spoilage.
• Higher revenues as a result of faster response to
customers.
 Online Banking
• Why is it Important
– For Customers:
– There’s a seemingly receptive audience out there waiting
– Most don’t feel the need to have a face-to-face conversation
with tellers or think its important to have a checking account
with a local branch office.
– For Banks:
–
–
–
–
The most important reason being ECONOMICS.
Each Internet transaction typically costs the bank one cent
Compare that with 27 cents for each ATM transaction
USD 1.07 every time you go up to a tellers window !!!
Online Banking
 The Internet
Brief Introduction to the Internet
World Wide Web
Common Gateway Interface (CGI)
Perl
C++
Server Side Include (SSI)
ASP
PHP
Client Side Include (CSI)
Java Script
Visual Basic Script
Brief Introduction to the Internet
-The Word Internet comes from the term
internetwork, which means “to communicate
between networks”.
-The Internet’s naming convention is stated in
the Domain Name Service (DNS). A DNS
name has the following format:
subdomain.subdomain.[…].domain
Brief Introduction to the Internet (cont…)
- The distributed database and software that
make up the DNS name resolution system is
comprised of the following basic parts:
 Domain name space
 Name servers
 Resolvers
Name Servers
Part of the DNS name space showing the
division into zones.
Part of the DNS name space showing the division into zones.
World Wide Web
- The client sends the
following text to the
server:
GET /docu2.html HTTP/1.0
Accept: www/source
Accept: text/html
Accept: image/gif
User-Agent: Lynux/2.8.1 libwww/2.14
From: [email protected]
* a blank line *
World Wide Web
- The server responds by sending:
HTTP / 1.0 200 OK
Date: Wednesday, 30-September-00 23:04:12 GMT
Server: NCSA / 1.1 MIME-version: 1.0
Content-type: text/html
* a blank line *
<HTML><HEAD><TITLE>…………</TITLE>………etc.
World Wide Web
The steps that occur between the user’s click and the page
being displayed are as follows:
1. The browser determines the URL (by seeing what was
selected)
2. The browser asks DNS for the IP address of www.w3.org.
3. DNS replies 18.23.0.23.
4. The browser makes a TCP connection to port 80 on
18.23.0.23.
5. It then sends a GET /hypertext/topics.html command.
6. The www.w3.org server sends the file topics.html
7. The TCP connection is released.
8. The browser displays all the text in topics.html.
9. The browser fetches and displays all images in topics.html.
Server-Side Include (SSI)
ASP
<@ LANGUAGE=“VBSCRIPT” %>
<HTML>
<TITLE>My First ASP!</TITLE>
<BODY>
<CENTER>Hello World ASP! <BR>
<% Response.Write(“Hello World for ASP!”) %><BR>
All done! <CENTER>
</BODY>
</HTML>
Server-Side Include (SSI)
(cont…)
PHP
<html>
<head>
<title>My Sample Page</title>
</head><body>
<?php $greeting “Hello World”;
echo $greeting; ?>
</body>
</html>
 Distributed Computing
To develop a framework for the programmers design and
implement new applications for heterogeneous distributed
environment different interest groups produce different distributed
computing frameworks.
Example:
 Distributed Computing Environment (DCE) by OSF Foundation)
 Distributed Component Object Model (DCOM) by Microsoft
 Common Object Request Broker Architecture (CORBA) by OMG
 Remote Method Invocation (RMI) by Sun Microsystem
Introduction to Middleware I
• What is Middleware?
– Layer between OS and distributed applications
– Hides complexity and heterogeneity of distributed system
– Bridges gap between low-level OS commands and programming language
abstractions
– Provides common programming abstraction and infrastructure for
distributed applications
DistributedApplications
Applications
Distributed
Distributed
Applications
Middleware
OperatingSystem
SystemComms
Comms
Operating
Operating
System Comms
Network
Network
Network
(remote calls, object invocation,
messages, …)
(sockets, IP, TCP, UDP, …)
(packets, bits…)
Introduction to Middleware II
• Middleware provides support for (some of):
–
–
–
–
Naming, Location, Service discovery, Replication
Protocol handling, Communication faults, QoS
Synchronisation, Concurrency, Transactions, Storage
Access control, Authentication
• Middleware dimensions:
–
–
–
–
–
Request/Reply
Language-specific
Proprietary
Small-scale
Tightly-coupled
vs.
vs.
vs.
vs.
vs.
Asynchronous Messaging
Language-independent
Standards-based
Large-scale
Loosely-coupled components
Distributed Computing Environment (DCE)
-The Components that constitute the DCE RPC are as follows:
1.
2.
3.
4.
5.
6.
7.
IDL and the IDL compiler
The RPC runtime library
Authenticated RPC
Name Service Independent (NSI) API
DCE host daemon
DCE control program
UUID facilities
DCE Provide Services:
•
DCE Directory Service
•
DCE Distributed File Service (DFS)
•
DCE Distributed Time Service (DTS)
•
DCE Security Service
Outline
• Part I: Remote Procedure Call (RPC)
– Historic interest
• Part II: Object-Oriented Middleware (OOM)
– Java RMI
– CORBA
– Reflective Middleware
• Part III: Message-Oriented Middleware (MOM)
– Java Message Service
– IBM MQSeries
– Web Services
• Part IV: Event-Based Middleware
– Cambridge Event Architecture
– Hermes
The two models of accessing a component
Application
•
• Multiply
• Divide
• Square Root
Calculator
In-process
model
• Multiply
• Divide
• Square Root
Application
•
Calculator
Network
Out-of-process model
Principle of Remote Procedure Call (RPC)
Conceptually
Caller
1
Stub
Callee
Reality
3
2
Skeleton
Network
1. marshalling; 2. transporting; 3. unmarshalling
Distributed COM (DCOM)
Conceptually
App
1
Stub
COM Obj
Reality
3
2
Network
Skeleton
Remote Procedure Call (RPC)
• Masks remote function calls as being local
• Client/server model
• Request/reply paradigm usually implemented with
message passing in RPC service
• 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
6) Marshal
7) Set timer
Remote
Function
fun(…)
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 (no-failure case)
• hides the complexity of a distributed system
 Various reliability guarantees
• deals with some distributed systems aspects of failure
Failure Modes of RPC
• Invocation semantics supported by RPC in the light of:
network and/or server congestion,
client, network and/or server failure
note DS independent failure modes
• RPC systems differ, many examples, local was Mayflower
Maybe or at most once (RPC system tries once)
• Error return – programmer may retry
Exactly once (RPC system retries a few times)
• Hard error return – some failure most likely
note that “exactly once” cannot be guaranteed
Disadvantages of RPC
 Synchronous request/reply interaction
• tight coupling between client and server
• may block for a long time
• leads to multi-threaded programming
fork(…)
 Distribution Transparency
remote call
• Not possible to mask all problems
 Lacks notion of services
join(…)
• programmer not interested in server but in service
 RPC paradigm is not object-oriented
• invoke functions on servers as opposed to methods on objects
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
Properties of OOM
 Support for object-oriented programming model
• objects, methods, interfaces, encapsulation, …
• exceptions (also in some RPC systems e.g. Mayflower)
 Location Transparency
• mapping object references to locations
 Synchronous request/reply interaction
• same as RPC
 Services
The Goal of RMI
• To extend the Java Object model to support
programming with distributed Objects
• The intention is to make distributed programming as
easy as standard Java programming
– Focus on application logic not distribution
35
RMI: Remote Method Invocation
1
RMI Service Object
RMI Registry
2
3
Client
A Simple Overview
• Java RMI allows one Java object to call methods
on another Java object in a different JVM
Method parameters
Client JVM
Local
Object
Remote
Object
Result or exception
Server JVM
37
Lookup in Java RMI
Interface
Remote Object
Client Program
Server Program
naming.lookup(“rmi://localhost:1099/
TestService”)
naming.rebind(“rmi://localhost:1099/TestS
ervice”, RemoteObjectReference)
Server
Client
RMIRegistry
38
The RMI Architecture
39
Stubs and Skeleton Layer
• Stubs and skeletons are
generated from the remote
interface
– Using the “rmic” Java tool
Interface
Client
Stub
Server
Skel
• Stub communicates with a skeleton rather than the remote
object
– This a Proxy approach
– Marshalls the parameters and results to be sent across the wire
– After java 1.1 skeletons were made obsolete and RMI now uses reflection to
direct a request to an object
40
Parameter Passing
• Parameter Passing in Java RMI is different from
standard Java
– Reminder: In Java, primitives are passed by value,
Objects are passed by reference
• In Java RMI
– Objects and primitives are passed by value
– Remote objects are passed by reference
• You must be aware of the differences!
– Otherwise you'll generate logical bugs that are difficult
to identify
41
Parameter Passing (2)
• RMI-Pass by Value
– All ordinary objects and primitives are serialised and a
copy is passed
– Any changes to the copy do not affect the original
– It is your job to ensure your Objects can be serialised!
• RMI-Pass by Reference
– Remote Object is the parameter, a stub (reference) is
sent
– the stub is used to modify the object, the original object
is modified
42
RMI
• Protocol: Java Remote Method Protocol (JRMP) on the
top of TCP/IP
• RMI Server:
– Define an interface
– Expose a set of methods
• RMI Client:
– Lookup a server object reference in RMIRegistry
– Invoke methods in the server object
• RMI Registry
– Holds information about available server objects
– Naming mechanism: URL
RMI is not a component model
• RMI is more a communication standard than a
component model
• Java component models which are built on RMI
– Java Embedded Server
– Java Dynamic Management Kit
– InfoBus
– JavaBean Activation Framework
– Enterprise JavaBean
Java Remote Method Invocation (RMI)
• Covered in 1B Concurrent Systems
• 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
• All system written in Java (single-language
system)
Component Object Model
• How should one chunk of software access the services provided
by another chunk of software?
• COM: A standard approach to access all kinds of software
services, regardless of how they are provided
• COM is transforming the way software is constructed
• Benefits of COM
– Offers the benefits of object orientation
– Provides consistency
– Is language independent
• COM defines a binary interface that objects must support
– Simple and efficient versioning
– Available on Windows, Windows NT, Macintosh, MVS up to
now
– DCOM allows COM objects on all kinds of systems to
interact
Communications between Software
lib
Application
Application
OS
Application
OS
Basic COM Concept
Interface
Binary Code of
a Client Class
COM
Library
Interface
Interface
Binary Code of a
Server Class
Basic COM Concept
Interface
Interface
COM object
Interface
Server
Basic COM Concept
COM object
Client
Basic COM Concept
Application
lib
Application
OS
OS
Application
Accessing a COM Object in an InProcess Server
Client
Object
Client process
Accessing a COM Object in a Local
Server
Client
Proxy
Stub
Object
Server Process
Client process
Single machine
Accessing a COM object in a Remote
Server
Proxy
Client
Client process
Machine X
Stub
Object
Server Process
Machine Y
Distributed Component Object Model (DCOM)
• Designed by Microsoft
• Based on Component Object Model (COM)
• Addresses issues such as:
– Interoperability
• Different applications, platforms, languages
– Versioning
• Compatibility between a new version of a server and old versions
of clients
– New interfaces should preserve the old interface
– Naming
• Use Globally unique identifiers
History
• DDE  OLE1  COM  OLE  DCOM
• Dynamic Data Exchange (DDE)
– For data exchange between any application through clipboard package
– Originally for Windows 2.1
• Object Linking and Embedding (OLE v1.0)
–
–
–
–
A compound document can embed objects belonging to other applications
E.g., an Excel spreadsheet in a Word document
An embedded object is linked to its original application
Restricted to document objects
History (continued)
• Component Object Model (COM)
– Interoperability of components
– Ability to share non-document based components
– Object-based technology
• Identity, polymorphism (multiple interfaces to a component),
interface inheritance
• OLE
– Layered on top of COM (and DCOM)
– Links the application layer to the underlying COM architecture
Object Model
• The difference between language-defined (CORBA)
and binary interfaces (DCOM)
DCOM Properties
• Distributed shared memory management
– DCOM provides interfaces for distributed components to
share memory
• Network interoperability and transparency
• Dynamic loading and unloading
– DCOM manages reference counts to objects
– Unloads objects whose reference count is 0
• Status reporting
– Of remote execution using HRESULT struct
DCOM Services
• DCOM is responsible for initializing a connection
between components, and
– Negotiating protocols for communication
• DCOM provides support for persistent storage
– Objects can persist
• Components can be assigned “intelligent names”
called monikers
Distributed Component Object Model (DCOM)
Client
COM
run-time
Security
Provider
COM
run-time
DCE RPC
Security
Provider
LPC
Client
DCE RPC
LPC
COM
run-time
Security
Provider
Component
COM
run-time
DCE RPC
Security
Provider
Protocol Stack
DCE RPC
Protocol Stack
DCOM netw orkprotocol
Component
DCOM Architecture
• SCM: Service Control Manager
Creating objects
• Classes of objects have globally unique identifiers
(GUIDs)
– 128 bit numbers
– Also called class ids (CLSID)
• DCOM provides functions to create objects given
a server name and a class id
– The SCM on the client connects to the SCM of the
server and requests creation of the object
MIDL
• An extension of DCE’s IDL
• The MIDL compiler generates the client and server
stub files
• Every DCOM interface inherits from an interface
known as IUnknown
– Interface names start with I
– IUnknown has three methods
• AddRef(), Release() and QueryInterface()
• AddRef() and Release() are used to manage reference counts
(for memory management)
Events
• Event processing in DCOM.
Passing an Object Reference in DCOM
(with custom marshaling)
Monikers
• Object names (as opposed to class names) are called monikers
• A moniker distinguishes one instance from another of the same
class
• Monikers themselves are objects
• Each moniker has its own persistent data, which contains
everything the moniker needs to start and initialize the single
object instance the moniker identifies
• When a client passes a moniker to access an object, COM looks
up a Running Object Table (ROT) for the moniker name
– If it exists, a pointer to the object is returned
– Else, a new object instance is created, its state is restored, its
reference is entered in ROT, and a pointer to the object is returned to
the client
• Monikers contain reference to the object’s persisted state
Why We Need CORBA?
Need a solution to develop, deploy, and integrate systems
in a distributed heterogeneous environment.
•
Diverse OS – Unix, Windows, MacOS etc.
•
Diverse Network – TCP/IP, Ethernet, ATM, etc.
•
Diverse Programming Language – applications
programmed in C++, JAVA, COBOL etc.
•
Diverse Hardware Platform.
•
Coexist with legacy systems.
What is CORBA?
CORBA – Common Object Request Broker Architecture
Middleware that provides the necessary framework and
API for developing distributed applications
Main Components of CORBA
ORB Core
CORBA Objects
OMG Interface Definition Language (OMG IDL)
Stubs and Skeletons
Dynamic Invocation Interface, Dynamic Skeleton Interface
Object Adapter (Portable Object Adapter)
Interface Repository
ORB Interoperability
Introduction to CORBA
 What is CORBA?
 A system providing interoperability between objects in a distributed
environment
 Specification of a standard architecture for object request brokers
(ORBs)
 OMG’s open, vendor-independent architecture
 Middleware to help development of distributed object systems.
 What does CORBA do?
 Provides interoperability among corba-based programs independent of





vendor
programing language
computer(hardware)
operating system
network
The OMG
• The Object Management Group (OMG) was formed in 1989. Its aims
were:
– to make better use of distributed systems
– to use object-oriented programming
– to allow objects in different programming languages to communicate
with one another
• The object request broker (ORB) enables clients to invoke methods in a
remote object
• Developed by the OMG (Object Management Group)
– A consortium of over 700 companies.
– Goal - to develop, adopt, and promote standards for the development and
deployment of applications in distributed heterogeneous environments.
 Incompatibility between compilers
 Differences in object models
 Differences in platforms
 Solution:
CORBA
•
CORBA
 Where is CORBA used?




Servers handling large number of clients
Mainframes
Websites
Embedded real time system
 How does CORBA work?
 CORBA applications are composed of objects
 For each object type, an interface in IDL(interface definition language) is
defined
 Clients use this IDL interface to invoke an operation on the object
 The same interface is used on the object side to perform the requested
operation
 The interface definition is then used to direct the results to their trip
back till they reach their destination
 The IDL (interface definition language) is independent of programming
language but maps to all of the popular programming languages.
 For remote invocations, the client's ORB and object's ORB must agree
on a common protocol – IIOP( Internet Inter-ORB Protocol)
Characteristics of CORBA
 Interoperability
 Seperates interface from implementation by IDL
 Encapsulation: The data and the running code in the object
is hidden from the rest of the system by the strict interface
 Location transparency : The ORB can tell from the object
reference that the target object is remote, the client can not.
CORBA
• Common Object Request Broker Architecture.
– Open standard
– 1991 – version 1.0
• Initial version.
– 1995 – version 2.0
• IIOP
• OMA
• More languages support
– 2002 – version 3.0
• Corba Component Model (CCM)
• Scripting languages support
Generic Architecture
Client
Server
Object
Object
Middleware
CORBA Architecture
• Remote-object: object implementation resides in server’s address space
Client
Server
Java Object
C++ Object
Skeleton
Stub
Object Adapter
ORB
ORB
Stub
• Provides interface between client object and ORB
• Marshalling: client invocation
• Unmarshalling: server response
Client
Server
Java Object
C++ Object
Skeleton
Stub
Object Adapter
ORB
ORB
Skeleton
• Provides iterface between server object and ORB
• Unmarshaling: client invocation
• Marshaling: server response
Client
Server
Java Object
C++ Object
Skeleton
Stub
Object Adapter
ORB
ORB
(Portable) Object Adapter (POA)
•
•
•
•
Register class implementations
Creates and destroys objects
Handles method invokation
Handles client authentication and access control
Client
Server
Java Object
C++ Object
Skeleton
Stub
Object Adapter
ORB
ORB
Object Request Broker (ORB)
• Communication infrastructure sending messages between objects
• Communication type:
– GIOP (General Inter-ORB Protocol)
– IIOP (Internet Inter-ORB Protocol) (GIOP on TCP/IP)
Server
Client
Java Object
C++ Object
Skeleton
Stub
Object Adapter
ORB
IIOP
ORB
CORBA Object
Server
CORBA
Interoperable Object Reference
Object
Interface
IDL
C++/Java
Implementation
Servant
IDL
•
Interface Definition Language
–
–
–
Defines all object interfaces in a common language
Bindings are available for C, C++, Java, Python, Smalltalk,
Cobol, etc…
An IDL compiler generates stubs and skeletons.
•
Stubs:
–
–
–
•
Looks like local object
Marhals arguments
Forwards all invocations through ORB to target object
Skeletons:
–
–
–
–
Receives invocations from ORB
Unmarshals arguments
Invokes target methods
Sends back return value
Interface Definition Language (IDL)
• Describes interface
• Language independent
• Client and server platform independent
Server
CORBA
Object
Interoperable Object Reference
Interface
IDL
C++/Java
Implementation
Servant
Overall CORBA Architecture
Client
C++ Object
Implementation Interface
repository
repository
IDL
Server
Java Object
Interface repository
the interface repository provides information about registered IDL interfaces to
Skeleton
clients and servers that require it.
Stub
Object Adapter
Implementation repository
IIOP
activates registered servers on demand and locates running servers
ORB
ORB
uses the object adapter name to register and activate servers
CORBA and OMG IDL
IDL source
Applications
Programs
Dynamic
invocation
interface
IDL
stubs
IDL
compiler
ORB
interface
Object Request Broker (ORB)
Object
servants
IDL
Skeletons
Dynamic
Skeleton
interface
Object
Adapter
Example of CORBA Services
• Naming: Keeps track of association between object names and
their reference. Allows ORB to locate referenced objects
• Life Cycle: Handles the creation, copying, moving, and deletion
objects
• Trader: A “yellow pages” for objects. Lets you find them by the
services they provide
• Event: Facilitates asynchronous communications through events
• Concurrency: Manages locks so objects can share resources
• Query: Locates objects by specified search criteria…
Object Invocation Models
• Invocation models supported in CORBA
Request type
Failure semantics
Description
Synchronous
At-most-once
Caller blocks until a response is
returned or an exception is raised
One-way
Best effort delivery
Caller continues immediately
without waiting for any response
from the server
Deferred
synchronous
At-most-once
Caller continues immediately and
can later block until response is
delivered
Security
• Transparency: application-level objects should be unaware
of security services which are used
• Control: client/object should be able to specify security
requirements
• Security polices: specified by policy objects
• Administrative domain where client/server is executed
determines set of security services
Secure Object Invocation in CORBA
CORBA Application
1)
2)
3)
4)
Define interface using IDL
Compile interface
Implement interface
Instantiate server:
•
Register object as a CORBA object
5) Instantiate client:
•
•
Invoke CORBA object
Example using a Java client and server
CORBA Services (selection)
• 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), not integrated programming model with general IDL
messages
CORBA vs. DCOM (1)
Issue
CORBA
DCOM
Design goals
Interoperability
Functionality
Object model
Remote objects
Remote objects
Services
Many of its own
From environment
Interfaces
IDL based
Binary
Sync. communication
Yes
Yes
Async. communication
Yes
Yes
Callbacks
Yes
Yes
Events
Yes
Yes
Messaging
Yes
Yes
Object server
Flexible (POA)
Hard-coded
Directory service
Yes
Yes
Trading service
yes
No
CORBA vs. DCOM (2)
Issue
CORBA
DCOM
Naming service
Yes
Yes
Location service
No
No
Object reference
Object's location
Interface pointer
Synchronization
Transactions
Transactions
Replication support
Separate server
None
Transactions
Yes
Yes
Fault tolerance
By replication
By transactions
Recovery support
Yes
By transactions
Security
Various mechanisms
Various mechanisms
Disadvantages of OOM
Synchronous request/reply interaction only
• 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
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
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
Java Message Service (JMS)
• API specification to access MOM implementations
• Two modes of operation specified:
– 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
Disadvantages of MOM
 Poor programming abstraction (but has evolved)
• Rather low-level (cf. Packets)
• Request/reply more difficult to achieve
• Results in multi-threaded code
 Message formats unknown to middleware
• No type checking (JMS addresses this – implementation?)
 Queue abstraction only gives one-to-one
communication
• Limits scalability (JMS pub/sub – implementation?)
Distributed Computing Environment (DCE)
-The Components that constitute the DCE RPC are as
follows:
1. IDL and the IDL compiler
2. The RPC runtime library
3. Authenticated RPC
4. Name Service Independent (NSI) API
5. DCE host daemon
6. DCE control program
7. UUID facilities
Common Object Request Broker Architecture
(CORBA)
Remote Method Invocation (RMI)
Thank you