TCOM510 ClientServer Architectures and Applications - PowerPoint PPT Presentation

Title: TCOM510 ClientServer Architectures and Applications


1
TCOM-510Client/Server Architectures and
Applications

• Instructor Dr. Peter Pachowicz
• phone 993-1552 email
  ppach_at_gmu.edu
• Office ST2, Rm. 253
• Office Hours Tuesday 2-400pm (and by an
  appointment)
• Syllabus

2
CONTENTS

• Introduction to middleware and distributed
  computing
• C/S model and principles of interprocess
  communication
• Distributed objects and remote invocation
• Basic C/S middleware
• C/S transaction processing
• Internet and web middleware
• Distributed object technology

3
MOTIVATION

• Business-driven computing revolution
• Shift in computing paradigm
• Traditional computing paradigm vs.
  Internet-based computing paradigm
• Top-level decomposition
• Serious system integration issues for a
  distributed multi-computer environment

4
CLIENT-SERVER ARCHITECTURE / MODEL

• The most important and basic architecture of a
  distributed system
• Communication request/reply invocation/result

request
CLIENT
SERVER
reply
request
SERVER/CLIENT
SERVER
reply
5
C/S Characteristics

• Service
• A relationship between two computers
• The server is a provider of services
• The client is a consumer of services
• Shared resources
• A server can serve many clients providing the
  same resources
• Asymmetrical protocols
• Clients always initiate the dialog
• Servers are passively awaiting requests from
  clients
• Callback - a client can pass a reference to a
  callback object and a server can invoke it. So,
  the client becomes a server.
• Transparency of location
• Computers can be anywhere but connected to the
  network
• Users do not need to know servers location

6

• Mix-and-match
• Independence from hardware and software platforms
• Message-based exchanges
• Clients and servers are loosely coupled systems
• Interactions through message-passing mechanism
• Encapsulation of services
• The server is a specialist and decides how to
  get the job done
• Servers can be upgraded without affecting clients
  as long as the published interface is not changed

7
C/S BUILDING BLOCKS

• The three basic building blocks
• Figure II-3-6
• Server
• Server side of the application - typically
• SQL database server TP Monitors Groupware
  servers Object servers The Web
• Support for Distributed System Management (DSM)
• A simple agent
• A managed PC

Client
Server
Middleware
8

• Client
• Client side of the application - for example, web
  browser
• Non-GUI clients
• Without multitasking - ATM machines, barcode
  reader, cellular phones, fax machines, etc.
• Requiring multitasking - robots, testers, etc.
• GUI clients
• Graphical windows with dialog boxes - Fihure
  II-5-8
• Object Oriented User Interfaces (OOUI)
• More sophisticated environments, highly iconic,
  with interactive manipulation of graphical
  components
• A visual desktop metaphore - Figure II-5-9
• The GUI/OOUI evolution - Figure II-5-10
• From Web pages to Shippable Places (virtual
  world) - Figure II-5-11

9

• Middleware
• The nervous system of a C/S infrastructure
• Three categories - Figure II-3-6
• Transport Stack
• Network Operating System
• Service Specific Middleware
• Also contains DSM components
• Middleware for n-tier architecture must provide a
  platform for
• running server-side components balancing loads
  managing the integrity of transactions
  maintaining high-availability supporting
  security providing C/S communication pipes
• Figure II-3-7
• Platforms
• The application servers that run the server-side
  components
• Used across different OSs to provide a unified
  view of the distributed environment - Web server,
  Object Transaction server, TP Monitor
• Pipes
• Provide the intercomponent communication

10
INTERPROCESS COMMUNICATION

• Middleware layers Figure I-4-1
• Integration of communication services into a
  programming language paradigm
• RMI Remote Method Invocation (invoke a method
  in an object)
• RPC Remote Procedure Call (a call to a
  procedure)
• Request-Reply protocol
• Internet transport protocols UDP and TCP
• Message passing

Send operation
Receive operation
Process A
Process B
Message (a set of bytes)
11

• Synchronous and asynchronous communication
• A queue is associated with each message
  destination
• Sending process causes a message to be added to a
  remote queue
• Receiving process removes messages from a local
  queue
• Synchronous communication
• Both operations are blocking
• Whenever send is issued the sending process is
  blocked until the corresponding receive is issued
• Whenever a receive is issued the process blocks
  until a message arrives
• Asynchronous communication
• The sending process in non-blocking
• The receiving process can be either better if
  non-blocking (Java case of a multithreaded
  process) - more efficient

12

• Message destination
• Messages are sent to (Internet address, local
  port) Figure I-4-2
• A local port is a message destination within a
  computer
• A port has one receiver and can have many senders
• Sockets
• Is a process abstraction for a point-to-point
  communication
• Interprocess communication consists of
  transmitting a message between a socket in one
  process and a socket in another process
• A message set to a particular Internet address
  and port number can be received only by a process
  whose socket is associated with the Internet
  address and port number
• Processes may use of multiple ports but a process
  cannot share ports with other processes on the
  same computer (multicasting is an exception)
• Each socket is associated with a particular
  protocol

13

• Remote object reference
• Addressing issue Figure I-4-10
• C/S communication Figure I-4-19
• Two processes must establish a connection between
  their pair of sockets before a C/S communication
  can be made
• One of the sockets will be listening, the other
  will be sending information
• Create and bind sockets
• Clients request connections
• A listening server accepts connections
• When a connection is accepted, the system
  automatically creates a new socket and pairs it
  with its client socket so that the server may
  continue listening for other clients connection
  requests through the original socket

14
DISTRIBUTED OBJECTS AND REMOTE INVOCATION

• Programming models for distributed applications -
  
• Applications are composed of cooperating programs
  running in several different processes
• These processes are most of all run on different
  computers
• Extensions to programming models
• Remote Procedure Call (RPC) model - allows
  client programs to call procedures in server
  programs running in separate processes and
  generally in different computers from the client
  (sequential processing)
• Remote Method Invocation (RMI) model - extension
  of local method invocation that allows an object
  living in one process to invoke the methods of an
  object living in another process
• Event-based programming model - allows objects to
  receive notification of the events at other
  distributed objects in which they have registered
  interest

15
Middleware Redefined

• Software that provides a programming model above
  the basic building blocks of processes and
  message passing is called middleware
• Figure I-5-1
• The middleware layer uses protocols based on
  messages between processes to provide its
  higher-level abstractions such as remote
  invocations and events
• Middleware provides location transparency and
  independence from the details of communication
  protocols, operating system and computer hardware
• Some forms of middleware allows the separate
  components to be written in different programming
  languages

16

• Location transparency
• In RPC, the client that calls a procedure cannot
  tell whether the procedure runs in the same
  process or in a different process, possibly on a
  different computer
• In RMI, the object making the invocation cannot
  tell whether the object it invokes is local or
  not and does not need to know its location
• Nor does the client need to know the location of
  the server
• Communication protocols
• The protocols that support the middleware
  abstractions are independent of the underlying
  transport protocol. The request-reply protocol
  can be implemented over either UDP or TCP.
• Computer hardware
• Standards for external data representation are
  used to hide the differences due to hardware
  architectures

17

• Operating system
• The higher-level abstractions provided by the
  middleware layer are independent of the
  underlying operating system
• Use of several programming languages
• Integrational issues
• The use of specially written programmers
  interfaces
• Interfaces are written using an Interface
  Definition Language (IDL)
• An interface that is intended for RPC and RMI
  cannot specify direct access to variables (data)

18
COMMUNICATION BETWEEN DISTRIBUTED OBJECTS

• The object model
• Object-oriented program (Java, C) consists of a
  collection of interacting objects
• Each object consists of a set of data and a set
  of methods
• An object communicates with other objects by
  invoking their methods, generally passing
  arguments and receiving results
• Objects can encapsulate their data and the code
  of their methods

19

• Distributed objects
• Since object-based programs are naturally
  partitioned, physical distribution of objects
  into different processes or computers in a
  distributed system is a natural extension
• Distributed object systems may adopt the
  client-server architecture. In this case, objects
  are managed by servers and their clients invoke
  their methods using RMI
• In RMI, clients request to invoke a method of an
  object is sent in a message to the server
  managing the object
• Objects can be replicated in order to obtain the
  benefits of fault tolerance and enhanced
  performance
• Objects can be migrated with a view to enhancing
  their performance and availability

20

• The distributed object model
• Figure I-5-3
• Each process contains a collection of objects
• Some objects can receive both local and remote
  invocations, whereas the other objects can
  receive only local invocations
• Objects that can receive remote invocations are
  called remote objects
• Remote Object Reference - All objects can
  receive local invocations only if the other
  objects hold references to them
• Remote Interface - Figure I-5-4 - Every
  remote object has a remote interface that
  specifies which of its methods can be invoked
  remotely

21
Remote Procedure Call (RPC)

• A extension to a classic procedure call familiar
  to every programmer
• A client calls a function/procedure on a remote
  server and suspends itself until it gets back the
  results --- RPC is synchronous
• Parameters are passed like in any ordinary
  procedure
• Issue 1 How are the server functions located
  and started?
• If there is a single call to a procedure, the
  issue is simple
• If there are many clients calling the same
  procedure, there is a need to start and stop
  server, prioritize requests, perform security
  checks, and provide a form of load-balancing
• Solution multi-threading - manage a pool of
  threads that wait for work

22

• Issue 2 How are parameters defined and passed
  between the client and the server?
• NOS is doing this quite well by providing
  Interface Definition Language (IDL) for
  describing the functions and parameters
• Figure II-8-4
• An IDL compiler takes descriptions of the
  interface given in IDL format and produces source
  cde stubs (and header files) for both the client
  and server
• These stubs are then used by programmers and
  linked with the client and server code
• The client stub - packages in parameters in an
  RPC packet, converts the data, calls the RPC
  run-time library, and waits for the servers
  reply
• The server stub - unpacks the parameters, calls
  the remote procedure, packages the results, and
  sends the reply to the client

23

• Issue 3 How are failures handled?
• Both sides of RPC can fail separately
  combinations of failures must be handled
• If the server does not respond, the client will
  normally block, time out, and retry the call
• The server cannot execute duplicate requests
• If the client fails after sending a request, the
  server must undo the effects of that transaction
• Connection-oriented RPC is more reliable
• Connectionless version is also available

24

• Issue 4 How is security handled by the RPC?
• NOS makes it easy to automatically incorporate
  its security features into RPC. All you need is
  to specify security level (authentication,
  encryption, etc.)
• Issue 5 How does the client find its server?
• The association between a client and a server is
  called binding
• Static binding - The binding information may be
  hardcoded or specified in the configuration
  management file
• Dynamic binding - The client can also find its
  server at run time through the network directory
  services if the server advertise its services in
  the directory. RPC client stub will locate a
  server from a list of servers that support the
  interface.
• Figure II-8-5 RPC mechanism

25
The MOM Middleware

• MOM Message-Oriented Middleware
• Provides the easiest path for creating
  inter-enterprise C/S systems
• Figure II-8-6
• MOM allows messages to be exchanged in a C/S
  system using queues
• Applications put messages in queues and getting
  messages from queues
• MOM hides very complex communication protocol
  from the programmer by providing a very simple
  high-level API to its services
• MOM-enabled programs do not talk to each other
  directly
• A program can decide when it wants to receive a
  message off its queue - load balancing issue

26

• Figure II-8-7 Messaging allows either the
  client or the server to be unavailable
• Messaging queues are versatile. They can be
  configured as one-to-many or many-to-one
  relationships - Figure II-8-8
• Message prioritizing
• Message filtering filters used to remove
  unwanted messages
• Message queues implementations
• Non-persistent (in memory)
• Persistent (logged on disk) a fault-tolerance
  to server and client failures
• Queue location
• Local
• Remote
• On both ends (queue to queue communication)
• MOM standard is regulated by MOMA committee
• MOM market is growing 60 per year

27
MOM vs. RPC

• RPC is immediate
• MOM has a work overhead associated with queuing
• MOM encourages an event-driven model of
  communication
• RPC can mimic this by asynchronous,
  loosely-coupled, event-driven behavior using
  threads
• Table II-8-1 - a list of differences
• RPC is being replaced by ORB
• RMI is a kind of RPC

28
Design Issues for RMI

• RMI Invocation Semantics
• Available delivery guarantees of the
  Request-Reply protocol
• Retry request message - retransmission of the
  request message until either a reply is received
  or the server is assumed to have failed
• Duplicate filtering - filtering of duplicate
  requests at the server when retransmissions are
  used
• Retransmission of results - retransmission of
  result messages without re-execution of the
  operations at the server
• Figure I-5-5 Combinations of the above choices
  leading to possible semantics for the reliability
  of remote invocations

29

• Maybe invocation semantics
• The invoker cannot tell whether a remote method
  has been executed once or not at all.
• None of the fault tolerance measures is applied
• A crash failure may occur either before or after
  the method is executed
• In asynchronous system, the result of executing
  the method may arrive after the timeout
• At-least-one invocation semantics
• The invoker receives either a result, in which
  case the invoker knows that the method was
  executed at least once, or an exception informing
  it that no result was received
• A serious problem with duplicate execution may
  arise - especially with duplicate read-modify
  operations at the server

30

• At-most-once invocation semantics
• The invoker receives either a result, in which
  case the invoker knows that the method was
  executed exactly once, or an exception informing
  it that no result was received, in which case the
  method will have been executed either once or not
  at all
• The use of retries masks any omission failures of
  the invocation or result messages
• A method cannot be executed more than once - it
  provides an important feature for systems with
  irreversible states
• Java RMI supports the at-most-once invocation
  semantics
• CORBA supports both the at-most-once invocation
  semantics and and maybe invocation semantics
• Sun RPC supports the at-least-once invocation
  semantics

31

• Transparency
• There is no distinction in syntax between local
  and a remote procedure call
• Retransmission of messages is transparent to the
  caller
• The latency of a remote invocation is several
  orders of magnitude greater than that of a local
  one
• It is a very serious conclusion for a designer to
  limit the number of remote calls (practical
  issue)
• A caller should be able to abort a remote
  procedure call that is taking too long in a such
  a way that it has no effect on the server - if
  so, the server must restore of the state on the
  server (transaction processing behavior)
• IDL can support more complex decision making in
  case of failures when communicating with remote
  objects
• Transparency and failure handling is pushed onto
  interfaces

32
Implementation Architecture of RMI

• Architecture - Figure I-5-6
• Explain the path client-server-client
• Communication module
• Carry out the request-reply protocol for message
  transmission
• The communication modules are responsible for
  providing a specified invocation semantics, for
  example at-most-once
• The communication module in the server selects
  the dispatcher for the class of the object to be
  invoked

33

• Remote Reference module
• Responsible for translating between local and
  remote object references and for creating remote
  object references
• It has a remote object table that records the
  correspondence between local object references in
  that process and remote object references which
  are system-wide
• It is a mapping process between client objects
  and server objects arranged into a communication

34

• The RMI software
• A software layer between the application-level
  objects and the communication and remote
  reference modules
• Proxy
• Makes remote method invocation transparent to
  clients by behaving like a local object to the
  invoker - but instead of executing an invocation,
  it forwards it in a message to a remote object
• There is one proxy for each remote object for
  which a process holds a remote object reference
• Dispatcher
• A server has one dispatcher and skeleton for each
  class representing a remote object
• Receives the request message from the
  communication module
• Skeleton
• Implements the method in the remote interface
• It unmarshals the arguments in the request
  message and invokes the corresponding method in
  the remote object
• It waits for the invocation to complete and then
  marshals the results in a reply message

35
Implementation Architecture of RPC

• Architecture - Figure I-5-7
• RPC is very similar to RMI
• Explain the path client-server-client
• There is no remote reference module since RPC is
  not concerned with objects and object references
• The role of a stub procedure is similar to that
  of a proxy
• A server stub procedure is like a skeleton method
  

36
TRANSACTIONS AND CONCURRENCY

• Transaction - a basic concept
• A transaction defines a sequence of server
  operations that is quaranteed by the server to be
  atomic in the presence of multiple clients and
  server crashes
• Nested transactions are structured from sets of
  other transactions. They are particularly useful
  in distributed systems because they allow
  additional concurrency.
• Transaction is an action that changes the state
  of an enterprise - for example, a customer
  depositing money in a checking account
  constitutes a banking transaction
• On-Line Transaction Processing (OLTP) is a
  backbone of commercial data processing since
  1970s
• Current examples Electronic commerce
  Inventory systems In general distributed
  systems and OLAP Distributed engineering design

37
ACID Properties

• ATOMICITY
• All of the transaction actions succeed or all
  fail
• Viewed as all-or-nothing proposition
• Actions under the transactions umbrella may
  include the message queues, updates to a
  database, and display
• Atomicity is defined form the perspective of the
  consumer of the transaction
• CONSISTENCY
• After a transaction is executed, it must leave
  the system in a correct state or it must abort
• If the transaction cannot achieve a stable end
  state, it must return the system to its initial
  state

38

• ISOLATION
• A transaction behavior is not affected by other
  transactions executed concurrently
• The transaction must serialize all accesses to
  shared resources and guarantee that concurrent
  programs will not corrupt each others operations
• A multi-user program running under transaction
  protection must behave exactly as it would in a
  single-user environment
• The changes that a transaction makes to shared
  resources must not become visible outside the
  transaction until it commits
• DURABILITY
• It means that a transactions effects are
  permanent after it commits
• Its changes should survive system failures

39
Transaction Models - Flat Transaction

• Flat transaction is the basic transaction type
• Figure II-15-1
• All the work done within the transaction
  boundaries is at the same level
• Transaction starts with begin_transaction
• Transaction ends with either a commit_transaction
  or abort_transaction
• Observe all-or-nothing proposition
• There is no way to commit or abort parts of a
  flat transaction
• All the actions are indivisible
• Major advantage is simplicity
• Major disadvantage is processing long transactions

40
Back-To-Back Flat Transaction

• Figure II-15-2
• It is also called baby stepping transaction
• It is executed in very small steps - from one
  stable state to another stable state
• Implemented as a workflow - a sequence of flat
  transactions that are either conversational or
  queued

41
Distributed Flat Transaction

• Figure II-15-3
• A flat transaction run on multiple servers and
  updating resources located within multiple
  resource managers
• In addition a high-level parallelism can be
  involved
• Each site TP Monitor (TP server) must manage its
  local pieces of transaction
• Within a single site, the TP Monitor coordinates
  the transactions with the local ACID subsystems
  and resource managers DB managers Queue
  managers Persistent objects Message Transport
• All-or-nothing proposition must be preserved over
  a distributed environment
• A Two-Phase Commit protocol manages distributed
  transaction

42
Two-Phase Commit Protocol

• Figure II-15-4
• Is used to synchronize updates on different
  programs and computers so they either all fail or
  succeed
• This is done by centralizing the decision to
  commit but giving each participant the right of
  veto

43

• Phases
• Phase 1
• The commit manager node (also called a root node
  or the transaction coordinator) sends
  prepare-to-commit commands to all its direct
  subordinate nodes
• This phase terminates when the root node receives
  ready-to-commit signals from all its direct
  subordinate nodes --- this indicates that all of
  those nodes are ready to the final commit phase
• Phase 2
• Starts when the root node decides to commit the
  transaction (based on the unanimous yes vote) and
  it tells all its direct subordinate nodes to
  commit
• When all subordinate nodes return commit
  confirmation, the root informs the client about
  the success
• The two-phase commit aborts if any of the
  participant returns refuse information

44

• Problems
• Performance overhead
• Usually a significant overhead is involved in TP
• It is introduced by message exchanges
• Virtually, there is no way to distinguish
  transactions which change the state at other
  subordinate nodes (in order to optimize commit
  protocol)
• Read-only optimization and Processing-only
  optimization
• Hazard windows
• There are situations where certain failures can
  be a problem
• For example, the root crashes after the first
  phase of the commit
• Fault-tolerant hardware is needed at key-points
  of TP

45
Limitations of the Flat Transaction

• Compound business transactions that need to be
  partially rolled back
• For example - arranging a trip flight, hotel,
  rental car booking
• Business transactions with humans in the loop
• Figure II-15-6 - Presentation of a set of
  choices - server must wait for the answer when
  data is locked, and if a user goes out from a
  desk then??
• Business transactions that span long periods of
  time
• Figure II-15-7 - Typical CAD design process
• Business transactions with a lot of bulk
• Figure II-15-8 - How do you handle millions of
  records for processing?
• Business transactions that span across companies
  and the Internet
• Figure II-15-9 - Political problem of company
  business protection, etc.

46
Transactions with Syncpoints

• Use of synchronization points (syncpoints) within
  a single transaction
• Figure II-15-10
• Syncpoints let you roll back work and still
  maintain a live transaction
• Syncpoints are not commit points
• Syncpoints control granularity of a transaction
  division into a logical series of activities

47
Chained Transactions

• A simple solution to a flat transaction - by
  chaining (in a linear order) a sequence of
  smaller transactions
• A variation of syncpoints that make the
  accumulation work durable
• Figure II-15-11
• They allow to commit work while staying with the
  transaction, so you dont have to give up your
  locks and resources
• You loose an ability to roll back the entire
  chain of work

48
Sagas Transactions

• The most advanced form
• They let you roll back the entire chain, if you
  require to so
• Figure II-15-12
• There is a maintenance of compensating
  transactions
• Crash resistance of the intermediate commits is
  maintained
• There is a choice of rolling back the entire
  chain under program control

49
Nested Transactions

• The most complicated form
• Figure II-15-13
• They provide an ability to define transactions
  within other transactions
• A transaction is broken into hierarchies of
  subtransactions
• A tree of nested transactions can be formed
• Each transaction can issue a commit or rollback
  for its designated piece of work
• If a parent transaction rolls back then all its
  descendent transactions must are rolled back
  regardless of whether they issued local commits
• Major benefits
• Failed subtransactions can be done with another
  method
• Nesting helps programmers write more granular
  transactions

50
TP MONITORS

• Transaction Processing Monitors specialize in
  managing transactions from their point of origin
  (typically on the client) across one or more
  servers, and then back to the originating client
• When a transaction ends, the TP Monitor ensures
  that all the systems involved are left in a
  consistent state
• TP Monitors know how to run transactions, route
  them across systems, load-balance their
  execution, and restart then after failures
• TP Monitor can manage resource on multiple
  servers
• First TP Monitors were developed for mainframes
  (typically for banking, booking, stock trading
  systems, etc.)

51
TP Monitor Functionality

• Process management
• Starting server processes
• Funneling work to these processes
• Monitoring the execution of processes
• Load balancing
• Transaction management
• TP Monitor guarantees the ACID properties to all
  programs that run under its protection
• C/S communication management
• Allows clients and processes to invoke an
  application component in a variety of ways -
  including request-response, conversations,
  queuing, publish-subscribe, or broadcast

52
TP Monitor Funneling Function

• Compare two situations - Figure II-16-1
• OS without TP Monitor
• OS with TP Monitor
• TP monitor behaves as an operating system (of a
  distributed system) on top of the existing OSs.
  It does it by connecting these systems through
  funneling.
• Funneling architecture - Figure II-16-2
• TP Monitor assigns the execution of each service
  to server classes, which are pools of prestarted
  application processes or threads waiting for work
• TP Monitor balances workload between them
• Each application can have one or more server
  classes
• The server process dynamically links to the
  proper service called by the client

53

• TP Monitor removes the process-per-client
  requirment by funneling client requests to proper
  application services
• If the number of incoming client requests exceeds
  the number of opened processes in a server class
• It may dynamically start new ones
• Distribute the process load across multiple CPUs
  in SMP or MPP environments
• Application programmers do not have to handle
  these issues
• Incoming requests are automatically prioritized
• Figure II-16-3
• For example, RPC has higher priority than MOM
• TP Monitor uses a two-phase commit protocol

54
Traditional vs. Transactional Communication

• Value-added extensions to traditional
  (non-transactional) communication models such as
  RPCs, ORBs invocations, queues,
  publish-and-subscribe, and conversational
  peer-to-peer
• They piggyback transactional delimiters -
  specifying the begin-transaction and
  end-transaction boundaries
• They introduce under-the-cover exchanges - TP
  Monitor assignes a unique ID to a new
  transaction Any communication related to it uses
  assigned ID (such as two-phase commit protocol)
• They embed transactional state - TP Monitor can
  better know what to do next
• They allow a TP Monitor to enforce exactly-once
  semantics - the message is executed exactly once
• Table II-16-1 - more differences

55
X/Open Distributed Transaction Processing
Reference Model

• TP Monitors are the ultimate glue software
• Coordinate applications running on different
  platforms with access to different databases and
  resource managers
• Figure II-16-4 - TP Monitor architecture
• RM API - used by an application to query and
  update resources that are owned by a Resource
  Manager (RM)
• TX API - used to signal that the application is
  beginning a transaction, ready to commit it, or
  wants to abort it
• XA API - used by the transaction manager to
  coordinate transaction updates across resource
  managers. Information is passed regarding prepare
  to commit, commit, or rollback transactions
• OSI-TP - protocols allow heterogeneous
  transaction managers to work together to
  coordinate transactions

56
3Tier C/S TP Monitor Architecture

• Figure II-16-5 - architecture
• TP Monitors provide an extra tier that separates
  client front-ends from the resource managers
• They control all the traffic that links hundreds
  (or thousands) of clients with application
  programs and the back-end resources
• Load balancing
• Make process independent from any resource
  manager
• Implementation of mission-critical applications

57
TP Monitor Benefits

• C/S application development framework
• TP Monitors are increasingly transparent to the
  developers through special development tools
• Enforce ACID properties
• Firewalls of protection
• TP Monitors support tightly-coupled firewalls
  such as two-phase-commit or loosely-coupled
  firewalls such as those provided by transactional
  queues
• High availability
• Designed to work around all types of failures
• With ACID you can detect a failure exactly where
  it happens
• Load balancing
• Support of prioritization of requests
• Can dynamically replicate server processes

58

• MOM integration
• TP Monitors together with MOMs can provide
  support for long-lived transactions and workflow
  type of applications
• Scalability
• Encourage to create modular reusable services
  that encapsulate resource managers
• Reduced system cost
• Savings between 30-50 can be achieved over
  database centric applications

59
INTERNET AND WEB MIDDLEWARE

• Started in 1989 at CERN (Europe) 1991 first
  browser
• 1993 - Mosaic browser at Univ. of Illinois
• The total size of the Web
• Doubles every 8 months
• Daily added 1.5M pages
• New type of doing business
• Failed concepts
• Surviving concepts
• Major objective - Productivity increase
• The evolution of Web technologies -
  Figure-II-26-1

60
Architecture

• Main objective - simplicity
• Web middleware - Figure II-26-2
• A collection of middleware that operates on top
  of TCP/IP networks
• Elements
• Web browsers
• Web servers and sites
• Uniform Resource Locator (URL)
• Hypertext Transfer Protocol (HTTP)
• Hypertext Markup Language (HTML)
• Web navigation and search tools
• Gateways to non-Web resources
• Java - a mobile code system

61
Web Browser

• Browser is the end-user interface to the Web
  servers - known as Web Client
• Is a GUI supporting a higher-level interactivity
• Addressing web resources
• Browser issues
• Compliance (HTTP, HTML, )
• Performance
• Integration (with standards, hardware/software
  components)
• Navigation aids

62
Web Server

• Web Site components
• Content files (HTML files)
• Web server - receiving browser calls and
  accessing documents
• Gateways generating Web content and providing DB
  access
• Web server is a scheduler of Web client requests

63
HTML

• A cross-platform documentation language
• Figure II-26-5/6
• Specifics
• Creation of an ASCII text file using HTML markup
  tags
• Defines style of presentation arranges
  presentation
• Hypertext - arranges organization of (links
  between) documents
• Hypermedia - allows for graphics, audio, and
  video elements to be a part of a document
• DHTML
• XML

64
HTTP

• At the core of the middleware for WWW
• An application-level protocol to give interactive
  users the ability to communicate
• Must be fast - so, it is really a simple model
• Model (steps)
• Connection - establish a connection with the
  server
• Request - send a request message (ask for a Web
  page) to the server
• Response - responds to the client with an answer
  (a Web page)
• Close - the client or server terminate the
  connection
• Each connection is handled as a self-contained
  Session (composed of ConnectRequestResponseClos
  e)
• Problems for DB applications - should involve
  conversation, requiring information about the
  state (state change, etc.)

65

• URI - Universal Resource Identifiers
• URL - is one of URIs - Figure-II-26-3
• URN - Universal Resource Names - identifies
  resource name
• URC - Universal Resource Citations - describe
  properties of objects
• Connection
• Implemented over TCP/IP - port 80 is the default
  port for connection
• Other port assignments possible - port to a
  service program connection
• Request - Figure-II-26-13
• Contains
• URI
• A request method
• Protocol version
• Request modifier
• Client information, and
• Body contents

66

• Example methods
• GET - indicates that a document needs to be
  retrieved from the server
• HEAD - used to get meta-level information - used
  to test/probe a link
• POST - used to send a message for posting on a
  news group, mailing list, etc.
• PUT - used to transfer documents to the server
• DELETE - used to delete resources identified in
  URI
• Response - Figure-II-26-14
• Contains
• A status line
• Server information
• Meta information, and
• Body contents
• MIME - Multipurpose Internet Mail Extension -
  defines how information other than text is sent
• Close
• Handling situations such as timeouts, program
  failures, or user actions

67
Basic 3-Tier C/S Web-Based Architecture

• Figure II-27-1
• Web gateways bridge a gap between Web browser and
  the corporate applications and DB
• Basic interactively is supported by these
  gateways
• Key element of E-commerce
• Stateful vs. stateless server model
• Approaches
• CGI Common Gateway Interface
• SSL Secure Sockets Layer
• S-HTTP Secure HTTP
• Mobile code systems (Java gateways)

68
CGI

• CGI - a program on a Web server
• Referenced to from a HTTP document (hyperlink)
• Types
• Single-step CGI gateway
• Contains business logic
• Used for simple functions
• Two-step CGI gateway
• Does not contain business logic
• Invokes a business application
• It is easier to invoke an existing application
  than write it using CGI
• A combination can be used effectively
• Useful for large legacy applications

69

• Process - Figure-II-27-6
• State maintenance - Figure-II-27-7
• The server forgets everything after a session is
  over
• Hidden fields are used to maintain the state on
  the client site
• Contain values not displayed within a form
  (returned to the client by the server)
• Used to store information - maintaining the state
  between submissions
• Hidden fields containing old data are passed back
  to the server through CGI when the current page
  is submitted
• Cookies are another variation of hidden fields
  approach
• Cookie is a small piece of data stored in the
  client on behalf of a server
• Typically used to store user Ids or basic
  configuration information
• Cookie is sent back to the server in subsequent
  page requests

70
Java The Mobile Code

• Characteristics
• Java - an object-oriented programming language
  crucial for web-based distributed computing
• Considered as a part of middleware
• Mobile code
• Can be run at a client site
• Introduces real dynamics in presentation and
  on-demand computing at the client site
• Access to DB can be invoked directly from the
  browser instead of using a gateway
• Runs animations, on-demand graphics etc.
• Java Applet - a small Java program shipped with a
  page

71
Web C/S with Java

• Applets allow us to distribute executable content
  across the Web along with data
• Interaction scenario - Figure II-28-1
• Request the applet
• Receive the applet
• Load and execute
• Discard the applet
• Services provided by a mobile code system
• A safe environment for executing mobile code
• Control access to memory, system calls and server
  function calls
• Platform-independent services
• Life cycle control
• Providing run-time environment for loading,
  unloading and executing the code
• Applet distribution across the network

72
How Does It Work?

• Figure II-28-2
• A portable unit of mobile code
• Portability achieved by compiling applets to the
  Java Virtual Machine
• Java Virtual Machine modeled after a RISC
  processors instructions called bytecodes
• Bytecodes make Java partially compiled language
  --- about 80 compilation done still requires
  about 20 of interpretation
• 80/20 mix creates excellent portability
• Bytecode executed/interpreted at a client
  location
• Problem Java interpreted code is about 15x
  slower than native compiled code

73
Characteristics

• Robust
• Lot of emphasis on early checking for possible
  problems
• Later dynamic checking
• Elimination of error-prone situations
• Support declarations - does not support C-style
  implicit declarations
• No pointer arithmetics
• Security
• Java verifier - FIGURE
• Big problem in distributed computing
• The problem is not resolved - will be ???
• Architecture Neutral
• Support applications on network - architecture
  independent
• Code compiled/interpreted at the client site

74

• Portable
• Specifies the size of the primitive data types
  and the behavior of arithmetic on them
• Compiler is written in Java and the run-time is
  written in ANSI C
• Interpreted
• High-Performance ???
• Multithreaded
• Synchronization primitives available
• Dynamic
• Designed to adapt to an evolving environment
• Understands interfaces

75
DISTRIBUTED OBJECTS AND COMPONENTS

• Top-level motivation
• Most current applications being developed are
  based on OO concepts
• Objects are increasingly dispersed on multiple
  machines
• Therefore, combination of OO and distributed
  systems is needed
• New system development paradigm
• Assembly from off-the-shelf components
• Systems engineering practice
• Build in record time
• Build with lowest cost
• C/S is natural environment for object oriented
  technology
• Data and business logic are encapsulated within
  objects allowing them to be located anywhere
  within a distributed system

76

• Benefits - Figure II-21-1
• Plug-and-play Interoperability Portability
  Coexistence Self-managing entities
• Distributed software
• Distributed objects ---gt independent software
  components
• Independent from different networks
• Independent from different operating systems
• Independent from different tool palettes
• They are not bound to any particular programming
  language or implementation
• REUSABILITY !!!
• Building systems from components
• Easy customization
• Software upgrades, patches, etc.
• Ever growing software size and complexity

77
Software Component

• Properties of a software component
• Marketable entity
• Self-contained, shrink-wrapped, binary piece of
  software purchased in the open market
• Not a complete application
• A component can be combined with other components
  to form an application
• Size Fine-grained small C objects
  Medium-grained GUI Objects Coarse-grained
  objects such as ERP module
• Can be used in unpredictable combinations
• Can be combined using plug-and-play so many
  combinations exist
• Has a well-specified interface
• The only part of a component exposed to the world
• Toolability
• Can be imported, customized, etc.

78

• Event notification
• Communication to the world
• Other components can subscribe to certain events
• Configuration and property management
• Components have state
• Properties can identify and surface this state
  information
• Property is a discrete named attribute that you
  can use to read and modify the state of a
  component
• May have a configuration wizards to configure
  itself
• Scripting
• A component must permit its interface to be
  controlled via scripting languages
• Metadata and introspection
• Must provide, on request, information about
  itself including information about interfaces,
  properties, ebvents, quality-of-service, and the
  suits it supports

79

• Interoperability
• Can be invoked as an object across address spaces
  networks, languages, OSs, and tools
• A system independent entity
• Ease of use
• Must provide a limited number of operations to
  encourage use and reuse
• The level of abstraction must be high as possible
  to make the component inviting to use
• This forms a new computing paradigm similar to
  hardware architecture
• Software IC - a component
• Board/container - application framework
• Backplane - object bus

80
JavaBeans Component Model

• Figure II-21-2
• JDK - Java Developers Kit provides infrastructure
  for running beans
• Beans are end product of all Java development
• Developers job is to create new beans or
  customize and assemble applications from existing
  beans --- a software version of an assembly line
• Figure II-21-3
• JDK provides the infrastructure
• Visual layout and presentation Events
  Properties Introspection Persistence
  Customization ORB services

81
Object Transaction Monitor - OTM

• OTM
• A top-of-the-line application server for
  distributed objects
• A morph between a TP monitor and an ORB
• Manages a set of containers that in turn run your
  server-side components
• Intercepts incoming calls, invokes the
  appropriate callback objects within a container,
  and then passes the request to your object
• Provides the platform for distributed objects
  (enforced organization)
• ORB
• Provides pipes for distributed objects
• Is simply an object bus
• Objects must explicitly provide calls to services
• More coding and highly skilled programmers are
  needed
• Figure II-21-6

82
Component Evolution

• Figure II-21-8
• Basic level - component bus (supported by ORB)
• Interoperation across address spaces, languages,
  OSs, and networks
• Bus augmented into a system-level services
• Creation of supermart components - services such
  as licensing, security, version control, suite
  negotiation, semantic messaging, scripting, and
  transactions
• Ultimate goal is to create business objects
• Business objects performing specific functions
  such as customer, car, or hotel
• Grouping objects into virtual suits that resemble
  real-world places on a desktop

83
Object-Style 3-Tier C/S

• Figure II-21-9
• Business objects are ideal for creating scaleable
  3-tier C/S solutions because they are inherently
  decomposable

84
Common Object Request Broker Architecture - CORBA

• The most important (and ambitious) middleware
  project ever undertaken by the industry
• CORBA - specification proposed by the Object
  Management Group (OMG) - a non-profit
  organization formed in 1989.
• Members mostly, large companies
• Goals
• Solve problems of interoperability in distributed
  systems
• Use de facto standards in object technology
• Create a suite of standard languages, interfaces
  and protocols for interoperability of
  applications in heterogeneous distributed
  environments
• Build upon, not replace, existing interfaces

85

• CORBA was designed to allow individual components
  to discover each other and interoperate on an
  object bus
• CORBA specifies technology for interoperable
  distributed OO systems
• Key concepts
• Specifies the middleware services that will be
  used by the application objects
• Any object (application) can be a client, server
  or both
• Any interaction between objects is through
  requests
• Supports static as well as dynamic binding (at
  compilation time, at run time)
• An interface represents contracts between client
  and server applications. IDL is defined for CORBA
  - it includes stubs and skeletons at IDL
  compiling
• Objects do not know the underlying implementation
  details. An object adapter maps a generic model
  to implementation

86
Distributed Objects - CORBA Style

• IDL used to define a components boundaries -
  interfaces
• Figure II-22-1
• CORBA objects are packaged as binary components
  that remote objects can access via method
  invocation
• Both language and compiler used to create server
  objects are totally transparent to clients
• Clients do