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• Without normalization

4 companies – 12 formats for the same message

What is EDI – Normalized languageWhat is EDI – Normalized language

EDIFACT normalization is part of the UNO missionsEDIFACT normalization is part of the UNO missions

ODETTE

EDISPORT

INOVERT

EDITEXT

EFOVADEANCOM

EDIFACT

Transport

Automobile Retail

Invoice

Despatch Advice

Orders

Benefits of EDIBenefits 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

• 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)

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 ImportantWhy is it Important

– For Customers: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: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 InternetBrief Introduction to the InternetWorld Wide WebCommon 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: A@www.fsktm.um.edu.my

* a blank line *

World Wide Web

- The server responds by sending:

HTTP / 1.0 200 OKDate: Wednesday, 30-September-00 23:04:12 GMTServer: NCSA / 1.1 MIME-version: 1.0Content-type: text/html* a blank line *<HTML><HEAD><TITLE>…………</TITLE>………etc.

World Wide WebThe 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.html7. 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

Distributed ApplicationsDistributed Applications

Operating System Comms

Operating System CommsNetworkNetwork

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

Distributed Applications

Middleware

Operating System Comms

(packets, bits…)

(remote calls, object invocation, messages, …)

(sockets, IP, TCP, UDP, …)

Network

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 vs. Asynchronous Messaging

– Language-specific vs. Language-independent

– Proprietary vs. Standards-based

– Small-scale vs. Large-scale

– Tightly-coupled vs. Loosely-coupled components

Distributed Computing Environment (DCE)

-The Components that constitute the DCE RPC are as follows:1. IDL and the IDL compiler2. The RPC runtime library3. Authenticated RPC4. Name Service Independent (NSI) API5. DCE host daemon6. DCE control program7. 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

research

research

The two models of accessing a component

Application•

• Multiply• Divide• Square Root

Calculator

In-process model

Application•

• Multiply• Divide• Square Root

Calculator

Network

Out-of-process model

Principle of Remote Procedure Call (RPC)

Caller

Network

Stub

Callee

Skeleton

Conceptually

Reality

1

2

3

1. marshalling; 2. transporting; 3. unmarshalling

Distributed COM (DCOM)

App

Network

Stub

COM Obj

Skeleton

Conceptually

Reality

1

2

3

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 RPC Service RPC Service RemoteFunction

call(…)

1) Marshal args

2) Generate ID3) Start timer

4) Unmarshal5) Record ID

6) Marshal7) Set timer

8) Unmarshal9)

Acknowledge

fun(…)

message

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

Exactly once (RPC system retries a few times)

• Hard error return – some failure most likely

note that “exactly once” cannot be guaranteed

Maybe or at most once (RPC system tries once)

• Error return – programmer may retry

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 functions on servers as opposed to methods on objects

fork(…)

join(…)

remote call

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

object A

proxy object B

OOM OOM

skeleton object B

object B

local remote

objectrequestbroker

/object

manager

objectrequestbroker

/object

manager

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

Client

RMI Registry RMI Service Object1

23

A Simple Overview

• Java RMI allows one Java object to call methods on another Java object in a different JVM

Local Object

Remote Object

Client JVM

Server JVM

Method parameters

Result or exception

37

Lookup in Java RMI

naming.rebind(“rmi://localhost:1099/TestService”, RemoteObjectReference)

naming.lookup(“rmi://localhost:1099/ TestService”)

RMIRegistry

ServerClient

Interface Remote Object

Client Program Server Program

38

The RMI Architecture

39

Stubs and Skeleton Layer

• Stubs and skeletons are generated from the remote interface– Using the “rmic” Java tool

• 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

Interface

Client

Stub

Server

Skel

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

OS

Applicationlib

Application

OS

Application

Basic COM Concept

Binary Code of aServer Class

Interface

Interface

Interface

Binary Code of a Client Class

COMLibrary

Basic COM Concept

COM object

Server

Interface

Interface

Interface

Basic COM Concept

COM object

Client

Basic COM Concept

OS

OS

Application

Application libApplication

Accessing a COM Object in an In-Process Server

Client Object

Client process

Accessing a COM Object in a Local Server

Proxy ObjectClient Stub

Client process Server Process

Single machine

Accessing a COM object in a Remote Server

Proxy ObjectClient Stub

Client process Server Process

Machine X 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 ComponentCOM

run-time

DCE RPC

LPC

COMrun-time

SecurityProvider

DCE RPC

LPC

SecurityProvider

Client ComponentCOM

run-time

DCE RPC

Protocol Stack

COMrun-time

DCOM network-protocol

SecurityProvider

DCE RPC

Protocol Stack

SecurityProvider

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 ArchitectureMiddleware 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

Middleware

Object

Client Server

Object

CORBA Architecture

ORB

C++ Object

Client Server

Java Object

ORBStub Object Adapter

Skeleton

• Remote-object: object implementation resides in server’s address space

Stub

• Provides interface between client object and ORB

• Marshalling: client invocation

• Unmarshalling: server response

ORB

C++ Object

Client Server

Java Object

ORB

Stub Object Adapter

Skeleton

Skeleton

• Provides iterface between server object and ORB

• Unmarshaling: client invocation

• Marshaling: server response

ORB

C++ Object

Client Server

Java Object

ORB

Stub Object Adapter

Skeleton

(Portable) Object Adapter (POA)

• Register class implementations

• Creates and destroys objects

• Handles method invokation

• Handles client authentication and access control

ORB

C++ Object

Client Server

Java Object

ORB

Stub Object Adapter

Skeleton

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)

ORB

C++ Object

Client Server

Java Object

IIOPORB

Stub Object Adapter

Skeleton

CORBA Object

Server

InterfaceIDL

C++/JavaImplementation

Interoperable Object ReferenceCORBA

Object

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

InterfaceIDL

C++/JavaImplementation

Interoperable Object ReferenceCORBA

Object

Servant

Overall CORBA Architecture

ORB

Client Server

IIOPORB

Stub Object Adapter

Skeleton

C++ Object IDL Java Object

Implementationrepository

Interfacerepository

Implementation repositoryactivates registered servers on demand and locates running servers uses the object adapter name to register and activate servers

Implementation repositoryactivates registered servers on demand and locates running servers uses the object adapter name to register and activate servers

Interface repository the interface repository provides information about registered IDL interfaces to clients and servers that require it.

Interface repository the interface repository provides information about registered IDL interfaces to clients and servers that require it.

CORBA and OMG IDL

Dynamicinvocationinterface

IDLstubs

ORBinterface

Object Adapter

Object Request Broker (ORB)

ApplicationsPrograms

IDLcompiler

Objectservants

IDLSkeletons

DynamicSkeletoninterface

IDL source

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) Define interface using IDL2) Compile interface3) Implement interface4) 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.

local messagequeues

Server App.

local messagequeues

messagequeues

Network Network Network

Message Server

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 compiler2. The RPC runtime library3. Authenticated RPC4. Name Service Independent (NSI) API5. DCE host daemon6. DCE control program7. UUID facilities

Common Object Request Broker Architecture (CORBA)

Remote Method Invocation (RMI)

Thank you