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. ecommerce, 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
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
Overview of CORBA services.
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
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
Invocation models supported in CORBA.
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 client
void 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 client
void replypoll_add(in int ret_val, in int k); // the same
CORBA: Communication
• 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:
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
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. access control
e.g. fragmentation
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
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
• 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's overall model of agents, agent systems, and regions.
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
2
3
4
1. To check interface spec. at runtime
(in Interface Repository).
2. E.g. IIOP
3. Object spec. at server
4. E.g. what to do if server unavailable
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.
CORBA: Consistency and Replication
• 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: 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
CORBA: Fault tolerance
(Message-level)
An example architecture of a fault-tolerant CORBA system.
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).
WWW: Overview
Overall organization of the Web.
• World Wide Web (WWW): Document-based distributed system.
• Started at CERN (European Particle Physics Lab).
• Popularity increased in the early 1990s.
WWW: Overview
• Documents include:
– Text and multimedia information, scripts, …
– Hyperlinks: references to other documents.
• Languages:
– HTML: Hypertext Markup Language
– XML: Extensible Markup Language
“Hello World” displayed twice,
directly and using a script.
• An example for an HTML document:
<HTML>
<BODY>
<H1>Hello World/H1>
<P>
<SCRIPT type = "text/javascript">
document.writeln ("<H1>Hello World</H1>;
</SCRIPT>
</P>
</BODY>
</HTML>
<!- Start of HTML document -->
<!- Start of the main body
-->
<!- Basic text to be displayed -->
<!- Start of a new paragraph -->
<!- identify scripting language -->
// Write a line of text
<!- End of scripting section -->
<!- End of paragraph section -->
<!- End of main body
-->
<!- End of HTML section
-->
WWW: Overview
• 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:
(1)
(2)
(3)
(4)
(5)
(6)
(7)
(8)
(9)
(10)
(11)
(12)
<!ELEMENT article (title, author+,journal)>
<!ELEMENT title (#PCDATA)>
<!ELEMENT author (name, affiliation?)>
<!ELEMENT name (#PCDATA)>
<!ELEMENT affiliation (#PCDATA)>
<!ELEMENT journal (jname, volume, number?, month? pages, year)>
<!ELEMENT jname (#PCDATA)>
<!ELEMENT volume (#PCDATA)>
<!ELEMENT number (#PCDATA)>
<!ELEMENT month (#PCDATA)>
<!ELEMENT pages (#PCDATA)>
<!ELEMENT year (#PCDATA)>
An XML definition for referring to a journal article.
article.dtd
WWW: Overview
• An XML document using the definitions in file article.dtd:
(1)
(2)
(3)
(4)
(5)
(6)
(7)
(8)
(9)
(10)
(11)
(12)
(13)
(14)
(15)
<?xml = version "1.0">
<!DOCTYPE article SYSTEM "article.dtd“>
<article>
<title> Prudent Engineering Practice for Cryptographic Protocols</title>
<author><name>M. Abadi</name></author>
<author><name>R. Needham</name></author>
<journal>
<jname>IEEE Transactions on Software Engineering</jname>
<volume>22</volume>
<number>12</number>
<month>January</month>
<pages>6 – 15</pages>
<year>1996</year>
</journal>
</article>
WWW: Overview
Type
Text
Image
Audio
Video
Application
Multipart
Subtype
Description
Plain
Unformatted text
HTML
Text including HTML markup commands
XML
Text including XML markup commands
GIF
Still image in GIF format
JPEG
Still image in JPEG format
Basic
Audio, 8-bit PCM sampled at 8000 Hz
Tone
A specific audible tone
MPEG
Movie in MPEG format
Pointer
Representation of a pointer device for presentations
Octet-stream
An uninterrupted byte sequence
Postscript
A printable document in Postscript
PDF
A printable document in PDF
Mixed
Independent parts in the specified order
Parallel
Parts must be viewed simultaneously
Six top-level MIME types and some common subtypes.
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 data
from browser
WWW: Overview
• Using Server-side scripts:
(1)
(2)
(3)
(4)
(5)
(6)
(7)
(8)
(9)
(10)
(11)
(12)
(13)
(14)
(15)
(16)
<HTML>
<BODY>
<P>The current content of <pre>/data/file.txt</PRE>is:</P>
<P>
<SERVER type = "text/javascript");
clientFile = new File("/data/file.txt");
Executed by server prior to reply
if(clientFile.open("r")){
(User will see in this example
while (!clientFile.eof())
document.writeln(clientFile.readln()); a text document generated
dynamically by the server)
clientFile.close();
}
</SERVER>
</P>
<P>Thank you for visiting this site.</P>
</BODY>
</HTML>
An HTML document containing a JavaScript to be executed by the server
WWW: Overview
• 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.
Architectural details of a client and server in the Web.
WWW: Communication
• 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.
a)
b)
Using nonpersistent connections: early versions.
Using persistent connections: newer ones.
WWW: Communication
Operation
Description
Head
Request 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
Put
Request 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
Operations supported by HTTP.
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
400
403
/ OK
/ Bad Request
/ Forbidden
 Message headers: optional
WWW: Communication
Header
Some HTTP
message
headers.
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
Client
Tells the server to return a document only if it has been
modified since the specified time
If-Unmodified-Since
Client
Tells 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
Server
A 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
• 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
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: Naming
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
Examples of URLs.
WWW: Naming
urn
urn
:
:
ietf
isbn
:
:
rfc:2648
0-13-088893-1
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
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)
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
•
•
•
•
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.
The position of TLS in the Internet protocol stack.
WWW: Security
• 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.
TLS with mutual authentication.