Case Studies

Chapter 9

CORBA: Overview• CORBA: Common Object Request Broker Architecture.

• Example for an object-based distributed system.

• Rather a specification and not a system.

• Originates from OMB (Object Management Group).

• First specification in early 1990s.

• Currently in version 3.

The global architecture of CORBA.

CORBA: Overview• ORB: Object Request Broker:

– Glue between applications.

– Main part of the middleware.

– Provides communication between objects.

– Supports access and location transparency.

• Corba facilities:– Compositions of object services (see below).

– Horizontal facilities: independent of application domains e.g. services for user interfaces, information management, system management, etc.

– Vertical facilities: include services for specific application domains e.g. e-commerce, banking, etc.

• Corba services:– What the Corba middleware provides for its applications in addition to basic

communication.

– Generic services with different functionalities (compare: OS services).

CORBA: Overview

Overview of CORBA services.

Service Description

Collection Facilities for grouping objects into lists, queue, sets, stacks, etc.

Query Facilities for querying collections of objects in a declarative manner; various collections possible

Concurrency Facilities to allow concurrent access to shared objects

Transaction Flat and nested transactions on method calls over multiple objects

Event Facilities for asynchronous communication through events

Notification Advanced facilities for event-based asynchronous communication (e.g. filtering)

Externalization Facilities for marshaling and unmarshaling of objects (like Java’s serialization)

Life cycle Facilities for creation, deletion, copying, and moving of objects

Licensing Facilities for attaching a license to an object

Naming Facilities for systemwide name of objects

Property Facilities for associating (attribute, value) pairs with objects

Trading Facilities to publish and find the services an object has to offer based on constraints

Persistence Facilities for persistently storing objects; persistence transparency is provided

Relationship Facilities for expressing relationships between objects (compare database schemes)

Security Mechanisms for secure channels, authorization, and auditing

Time Provides the current time within specified error margins

CORBA: Overview

The general organization of a CORBA system.• Object Model:

– Rather “remote object” model (not “distributed objects”).

– IDL for interface definitions (syntax only).

– ORB: communication, marshalling/unmarshalling and comparing object references, finding available services.

– Clients: Static/ dynamic invocation interface. DII provides a generic invoke-method interface.

– Servers: Object adapters (request forwarding, activation policy), DSI provides implementation of invoke-methods.

CORBA: Communication

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

CORBA: Communication• Corba Event and Notification Services:

– Many applications need event-based communication in addition to object invocations.

– Corba event model:

Events corresponds to data items (e.g. object references)

Events are produced by suppliers.

Events are used by consumers.

– Two models:

Push model:

Supplier delivers event to consumers.

Consumers are interrupted when supplied events arrive (passive waiting).

Pull model:

Consumer polls event channel for events (active waiting).

Event channel polls suppliers for events.

CORBA: Communication

Push-style (top) and pull-style (bottom) event models.

CORBA: Communication

• Characteristics of the event model:– Persistent event-based communication is not supported. For example, if a

consumer connects to the event channel after the supply of an event, that event will be lost.

– Event filtering was initially not supported. A consumer attached to an event channel will receive all events supplied to that channel. Different types of events can be distinguished by providing different event channels.

– However, filtering capabilities have been added as a part of the Notification Service.

– Notification Service is also able to prevent propagation of events to channels that are not attached to consumers.

– Event propagation is unreliable. Corba does not guarantee event delivery.

CORBA: Communication

CORBA's callback model for asynchronous method invocation.

• Asynchronous communication in Corba is object-based.• Two models: callback model (see figure) and polling model.• Example for the use of the callback model:

int add(in int i, in int j, out int k);void sendcb_add(in int i, in int j); // called by clientvoid replycb_add(in int ret_val, in int k); // called by ORB

CORBA: Communication

CORBA'S polling model for asynchronous method invocation.

• In both models the object implementation (server-side) is not changed. server retains the synchronous model.

• Also, persistent communication is possible using both models.• Example for the use of the polling model:

int add(in int i, in int j, out int k); void sendpoll_add(in int i, in int j); // called by clientvoid replypoll_add(in int ret_val, in int k); // the same

CORBA: Communication

Message type Originator Description

Request Client Contains an invocation request

Reply Server Contains the response to an invocation

LocateRequest Client Contains a request on the exact location of an object

LocateReply Server Contains location information on an object

CancelRequest Client Indicates client no longer expects a reply

CloseConnection Both Indication that connection will be closed

MessageError Both Contains information on an error

Fragment Both Part (fragment) of a larger message

• For interoperability, the protocol between ORBs is standardized.

• The Corba protocol therefor is GIOP: General Inter-ORB Protocol.

• GOIP requires the use of a transport protocol that is reliable, connection-oriented, and supporting byte streams (e.g. TCP).

• Realization of GIOP on top of TCP is called IIOP: Internet Inter-ORB Protocol.

• GIOP (and thus IIOP) message types are:

CORBA: Processes• Processes in Corba are clients and servers (components).

• Clients are kept simple: proxy marshals invocationw into IIOP requests and unmarshals corresponding reply messages.

• If an object needs a specific implementation of the proxy (e.g. one with caching), interceptors are used. Interceptors are hardly seen by applications (rather part of ORB).

• Two levels of interceptors are possible (both can be used at the same time):

e.g. fragmentation

e.g. access control

Mapping of CORBA object identifiers to servants.a) Policy 1: One servant for each objects.b) Policy 2: One servant for multiple objects.

CORBA: Processes• Servers are based on Portable Object Adapters (POA).

• POA may support activation policies, transient/persistent objects, and wrappers.

• Possible policies for wrapping the objects:

Object state

CORBA's overall model of agents, agent systems, and regions.

CORBA: Processes• Corba also supports agents: it provides a framework for cooperation between agent

systems.

• Agent system should provide: creation, execution, transfer, and termination of agents.

• An agent is always located in a place (i.e. server in an agent system).

• Multiple agent systems may form a region (i.e. administrative domain).

• Each region has a finder service, which allows it to find the location of agents, places, and agent systems.

CORBA: Naming• Names: Object references and Character-based names.

• Object references:

– Clients work with language-dependent representations of references (e.g. pointers).

– ORBs work with language-independent representations of references: IOR : Interoperable Object Reference

– Mapping between IORs and “pointers” is done by ORB.

– Structure of IOR (here using IIOP):

1. To check interface spec. at runtime (in Interface Repository).2. E.g. IIOP3. Object spec. at server4. E.g. what to do if server unavailable

1 2

3 4

CORBA: Naming• Binding: direct or indirect (see figures).

• Character-based names:

– Based on the Corba naming service

– Names: sequence of (id, kind)-pairs (e.g. (shopping, dir) (server, class))

– No restrictions on the name space (tree, cycles, …)

– An initial naming context (i.e. a directory node) is required to resolve names.

Direct binding Indirect binding

CORBA: Synchronization

• Services: Concurrency control service and transaction service.

• Concurrency control service:

– Based on locks (in general a central lock manager).

– Read/Write locks are distinguished.

– Different granularities are possible (entire table, one row, etc.).

• Transaction service:

– Based on 2PC.

– Corba distinguishes:

– Transactional objects: e.g. read-only ones for which no recovery is necessary.

– Recoverable objects: For which roll-back and recovery are necessary.

• No direct support for caching and replication in Corba, except for fault tolerance.

• But applications can provide that as services: e.g. CASCADE is a Corba caching service.

• CASCADE features:

– Different client-centric consistency models are supported.

– Total ordering of updates.

– Each object may have its own consistency model.

– Caching is quasi implicit for clients.

– Implementation is based on interceptors:

CORBA: Consistency and Replication

CORBA: Fault tolerance• Corba version 3 provides mechanisms for fault-tolerance based on replication.

• Replication is transparent for clients.

• Instead of IORs, IOGRs (Interoperable Object Group Reference) are used.

• Structure of IOGR:

Example for the use of the Components field to

specify the role of a replica

An example architecture of a fault-tolerant CORBA system.

CORBA: Fault tolerance

(Message-level)

CORBA: Security

The general organization for secure object invocation in CORBA.

• Security services: What services can be used for security (e.g. authorization, authentication) depends on the administrative domain (or client policies).

• Policies: client(or server)-specific information (e.g. how to protect messages, what are trusted parties).

CORBA: Security

Implementation of security services using interceptors.

• Access control interceptor: request-level interceptor for authorization.– Access objects: actual authorization methods.

• Secure invocation interceptor: message-level interceptor for secure communication.– Security context object: offers, for example, methods for encryption and decryption.

– Vault objects: called by invocation interceptor to create a security context (policy information may be also used at creation time).

• World Wide Web (WWW): Document-based distributed system.

• Started at CERN (European Particle Physics Lab).

• Popularity increased in the early 1990s.

WWW: Overview

Overall organization of the Web.

• Documents include:– Text and multimedia information, scripts, …

– Hyperlinks: references to other documents.

• Languages:– HTML: Hypertext Markup Language

– XML: Extensible Markup Language

• An example for an HTML document:

WWW: Overview

<HTML> <!- Start of HTML document --><BODY> <!- Start of the main body --><H1>Hello World/H1> <!- Basic text to be displayed --><P> <!- Start of a new paragraph --><SCRIPT type = "text/javascript"> <!- identify scripting language --> document.writeln ("<H1>Hello World</H1>; // Write a line of text</SCRIPT> <!- End of scripting section--></P> <!- End of paragraph section --></BODY> <!- End of main body--></HTML> <!- End of HTML section-->

“Hello World” displayed twice, directly and using a script.

• An example for an XML document:– Unlike HTML which emphasizes the layout of documents (e.g. font, font size, etc.),

XML emphasizes the structure of the document’s data.

– XML is typically embedded in HTML documents or a special formatting language

XSL (Extensible Style Language) is used.

– Following example reflects the structure of a library document:

WWW: Overview

(1) <!ELEMENT article (title, author+,journal)>(2) <!ELEMENT title (#PCDATA)>(3) <!ELEMENT author (name, affiliation?)>(4) <!ELEMENT name (#PCDATA)>(5) <!ELEMENT affiliation (#PCDATA)>(6) <!ELEMENT journal (jname, volume, number?, month? pages, year)>(7) <!ELEMENT jname (#PCDATA)>(8) <!ELEMENT volume (#PCDATA)>(9) <!ELEMENT number (#PCDATA)>(10) <!ELEMENT month (#PCDATA)>(11) <!ELEMENT pages (#PCDATA)>(12) <!ELEMENT year (#PCDATA)> article.dtd

An XML definition for referring to a journal article.

(1) <?xml = version "1.0">(2) <!DOCTYPE article SYSTEM "article.dtd“>(3) <article>(4) <title> Prudent Engineering Practice for Cryptographic Protocols</title>(5) <author><name>M. Abadi</name></author>(6) <author><name>R. Needham</name></author>(7) <journal>(8) <jname>IEEE Transactions on Software Engineering</jname>(9) <volume>22</volume>(10) <number>12</number>(11) <month>January</month>(12) <pages>6 – 15</pages>(13) <year>1996</year>(14) </journal>(15) </article>

• An XML document using the definitions in file article.dtd:

WWW: Overview

WWW: Overview

Six top-level MIME types and some common subtypes.

Type Subtype Description

Text Plain Unformatted text

HTML Text including HTML markup commands

XML Text including XML markup commands

Image GIF Still image in GIF format

JPEG Still image in JPEG format

Audio Basic Audio, 8-bit PCM sampled at 8000 Hz

Tone A specific audible tone

Video MPEG Movie in MPEG format

Pointer Representation of a pointer device for presentations

Application Octet-stream An uninterrupted byte sequence

Postscript A printable document in Postscript

PDF A printable document in PDF

Multipart Mixed Independent parts in the specified order

Parallel Parts must be viewed simultaneously

WWW: Overview• Architecture:

– Simple Client/Server interactions were later enhanced.

– Added: CGI, Server-side scripts, Applets, Servlets

• The principle of using server-side CGI programs:

e.g. form datafrom browser

WWW: Overview

An HTML document containing a JavaScript to be executed by the server

(1) <HTML>(2) <BODY>(3) <P>The current content of <pre>/data/file.txt</PRE>is:</P>(4) <P>(5) <SERVER type = "text/javascript");(6) clientFile = new File("/data/file.txt");(7) if(clientFile.open("r")){(8) while (!clientFile.eof())(9) document.writeln(clientFile.readln());(10) clientFile.close();(11) }(12) </SERVER>(13) </P>(14) <P>Thank you for visiting this site.</P>(15) </BODY>(16) </HTML>

• Using Server-side scripts:

Executed by server prior to reply(User will see in this example a text document generated dynamically by the server)

WWW: Overview

Architectural details of a client and server in the Web.

• Applets: precompiled code executed by clients; e.g.:

<OBJECT codetype = “application/java” classid = “java.welcome.class”>

• Servlets: An alternative to CGI, code is executed in address space of server.

WWW: Communication

a) Using nonpersistent connections: early versions.b) Using persistent connections: newer ones.

• Communication in WWW is based on HTTP: Hypertext Transfer Protocol

• HTTP is based on TCP and is stateless.

• Connections:– Nonpersistent: a new connection for each request.

– Persistent: different requests share same connection.

WWW: Communication

Operations supported by HTTP.

Operation Description

HeadRequest to return the header of a document

e.g. get information on last modification time, etc,

Get Request to return a document to the client

PutRequest to store a document

(name and document are parameters)

Post

Provide data that is to be added to a document collection

e.g. post an article in a news group

(group name and article are parameters)

Delete Request to delete a document

WWW: Communication

HTTP request message

Operation: e.g. get, put, …

Reference: e.g. URL

Version: Client HTTP version

Message headers: optional

WWW: Communication

HTTP response message.

Version: Server’s HTTP version

Status code / Phrase: e.g.

200 / OK

400 / Bad Request

403 / Forbidden

Message headers: optional

WWW: Communication

Some HTTP message headers.

Header Source Contents

Accept Client The type of documents the client can handle

Accept-Charset Client The character sets are acceptable for the client

Accept-Encoding Client The document encodings the client can handle

Accept-Language Client The natural language the client can handle

Authorization Client A list of the client's credentials

WWW-Authenticate Server Security challenge the client should respond to

Date Both Date and time the message was sent

ETag Server The tags associated with the returned document

Expires Server The time how long the response remains valid

From Client The client's e-mail address

Host Client The TCP address of the document's server

If-Match Client The tags the document should have

If-None-Match Client The tags the document should not have

If-Modified-Since ClientTells the server to return a document only if it has been modified since the specified time

If-Unmodified-Since ClientTells the server to return a document only if it has not been modified since the specified time

Last-Modified Server The time the returned document was last modified

Location ServerA document reference to which the client should redirect its request

Referer Client Refers to client's most recently requested document

Upgrade Both The application protocol the sender wants to switch to

Warning Both Information about the status of the data in the message

WWW: Processes

Using a plug-in in a Web browser.• Clients: Most important part is the browser.

• Browsers use plug-in programs in order to cope with different document types.

• Plug-in: small program dynamically loaded by the browser.

• Examples: plug-ins to handle Java applets, scripts, XML, etc.

WWW: Processes

Using a Web proxy when the browser does not speak FTP.

• Web proxy: A client-side process used by the browser to handle application-level protocols like FTP.

• Web proxy acts as gateway that translates messages between different protocol worlds.

• However: Current browsers do not need such proxies; they are able to understand different protocols by themselves.

• Instead: Proxies are currently used for caching.

WWW: Processes

General organization of the Apache Web server.• Web servers: Analyze incoming HTTP messages and perform appropriate

operations.

• Example: Apache Web server:

• Highly configurable Web server with different modules.

• Each module may include different handlers for different types of requests.

• Request processing is divided in phases, and each handler can perform operations of a single phase

WWW: Processes

• Phases of Apache:

• Resolving the document reference to a local file name/program

• Client authentication

• Client access control

• Request access control

• MIME type determination of the response

• Handling “leftovers” (parse request, …)

• Transmission of the response

• Logging data on the processing of the request

• In general: Core module spawns a new process for each request.

• Simplest configuration of Apache:

• Without any module

• Core module does everything

• But only HTML files are supported

WWW: Processes

Principle of using a cluster of workstations to implement a Web service.• For efficiency, Web servers are replicated in a LAN.

horizontal distribution

• Problem: Front end may become a bottleneck.

• Solutions: Transport-level front ends or application-level front ends.

WWW: Processes• Transport-level front ends:

• Do as few work as possible at front end in order to avoid overloads.

• Front end’s server selection is not based on the message contents.

• Server selection is based on actual load on servers or a hardwired policy is used (e.g. Round Robin) in order to achieve load balancing.

• Application-level front ends:

• Front end inspects HTTP messages and decides which server to use based on the message contents.

• Advantages:

• Higher throughput of server is achievable. For example, if a document request is always forwarded to a server that handled it before, effectively document caching at the server is possible.

• Distribution instead of replication can be used. This approach can reduce storage capacity without entirely loosing fault tolerance advantages of replication.

Example: Dedicated servers for audio, video, or text data.

WWW: Processes

The principle of TCP handoff.• Main problem of application-level front ends is that they have to do a lot of work

( bottleneck).

• Remedy: Use of TCP handoffs (see figure)

Front end only handles requests and delegates responses to the server.

Client sees only one TCP connection.

Sufficient for non-persistent connections.

WWW: Processes

A scalable content-aware cluster of Web servers.• A hybrid solution:

• On the application level, a dispatcher selects a server based on request contents.

• On the transport level, a switch forwards messages to previously selected server.

Better suited for persistent connections.

WWW: Naming

Often-used structures for URLs.a) Using only a DNS name.b) Combining a DNS name with a port number.c) Combining an IP address with a port number.

• WWW names are called: URI (Uniform Resource Identifiers)

• URL (Uniform Resource Locator):

Location-dependent (in practice, you need only URLs)

• URN (Uniform Resource Name):

True identifiers

WWW: Naming

Examples of URLs.

Name Used for Example

http HTTP http://www.cs.vu.nl:80/globe

ftp FTP ftp://ftp.cs.vu.nl/pup/minx/README

file Local file file:/edu/book/work/chp/11/11

data Inline data data:text/plain;charset=iso-8859-7,%e1%e2%e3

telnet Remote login telnet://flits.cs.vu.nl

tel Telephone tel:+31201234567

modem Modem modem:+31201234567;type=v32

WWW: Naming

The general structure of a URN• URNs

• Scheme: “urn”

• Name space: Gives structure of names

e.g. isbn or ietf structure etc.

• Name of resource: actual identifier of resource

e.g. actual RFC article identifier

urn : ietf : rfc:2648urn : isbn : 0-13-088893-1

WWW: Synchronization

• Synchronization is not really supported because:

• Strict client/server orientation (no inter-server/client-communication).

• Updates are rare and done mostly by a single person.

• However, more support for cooperative Web authoring is emerging.

• WebDAV (Web Distributed Authoring and Versioning):

• An extension of HTTP towards synchronization.

• Locks:

Exclusive write locks

Shared write locks

• Granularity of locks: Whole document

if shared, writers should modify different parts.

• Locks are implemented using tokens that servers gives to clients.

• Clients provide server with tokens when they perform updates.

• Tokens may survive connection breakdowns and disconnections.

WWW: Caching and Replication• Both caching and replication are main issues in the WWW.

• Caching:

• Small cache at browser machine.

e.g. one cache per client

• More important proxy caches

a proxy cache in a LAN (flat) or multiple hierarchical proxies (multi-level).

• Protocols in general pull-based:

• Proxy sends “if-modified-since” header in a GET-request.

doubles number of messages but reduces amount of transferred data.

• Acceptable weaker consistency can be achieved with less number of messages.

• Active caches:

Server replies with an applet to the proxy.

Applet does the actual document transfer, if need be.

Applet is cached and activated, when same document is accessed again.

• Cooperative caching (see next slide)

• Strict client/server orientation (no inter-server/client-communication).

• Updates are rare and done mostly by a single person.

• However, more support for cooperative Web authoring is emerging.

• WebDAV (Web Distributed Authoring and Versioning)

• An extension of HTTP towards synchronization.

• Locks:

Exclusive write locks

Shared write locks

• Granularity of locks: Whole document

if shared, writers should modify different parts.

• Locks are implemented using tokens that servers gives to clients.

• Clients provides server with tokens when they perform updates.

• Token may survive connection breakdowns and disconnections.

WWW: Caching and Replication

The principle of cooperative caching

WWW: Caching and Replication• Replication:

• Using horizontal distribution (as mentioned earlier)

transparent for clients

• Mirroring:

nontransparent

• Recently, forms of server-initiated replica placement have emerged.

• Example: RaDaR Web hosting service

• A collection of servers are able to analyze client traffic.

• Servers in the proximity of a client are observed as originator of that traffic.

• Following some policy (e.g. after a frequency threshold is reached), a document is moved/copied to the corresponding server.

• Fault tolerance:• No special mechanisms are used in the Web.

• Only replication and caching as explained (even if the intention of their use was

originally to enhance performance).

• However, achieved fault tolerance in the Web is based on the use of highly available and fault tolerant services such as DNS.

WWW: Security

The position of TLS in the Internet protocol stack.

• HTTP supports security.

• However, in practice security is dealt with at the transport level.

• SSL: Secure Socket Layer is generally used for secure communication in the Web.

• Newest version of SSL is called TLS (Transport Layer Security) protocol.

WWW: Security

TLS with mutual authentication.

• Setting up a secure channel using TLS (see figure):

1. Client sends a set of possible cryptographic/compression methods it can handle.

2. Server chooses one of them.

3. Server sends a certificate (encrypted by a certification authority, CA) to client.

now server is authenticated with client.

4. Client authenticates itself with client.

5. Client sends a random number, which is used to construct a session key.