common application components l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Common Application Components PowerPoint Presentation
Download Presentation
Common Application Components

Loading in 2 Seconds...

play fullscreen
1 / 37

Common Application Components - PowerPoint PPT Presentation


  • 203 Views
  • Uploaded on

Common Application Components. Some frequently needed elements in applications that involve communication between separate systems. Common Elements of the Application Layer. Some things have to be done in all applications Others are very common

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Common Application Components' - betty_james


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
common application components

Common Application Components

Some frequently needed elements in applications that involve communication between separate systems

common elements of the application layer
Common Elements of the Application Layer
  • Some things have to be done in all applications
  • Others are very common
  • Having a bag of tools handy can save recreating a solution every time the problem arises
base set of common services
Base set of common services
  • Establish contact
  • Remote execution
  • Reliable transfer of data
  • Coordination of distributed processing elements
establishing contact
Establishing contact
  • Locate the processing partner
  • Associate semantics with messages exchanged
  • Understand network service level
  • Match processing elements
  • Identify initiator of the contact
slide5
ACSE
  • Association Control Service Element
  • Two types of services offered:
    • Association establishment
    • Association termination
      • release
      • abort by the user
      • abort by the lower layer network services
a associate
A-ASSOCIATE
  • Association establishment
    • parameters describe the set of desired characteristics (the context) of the association
      • what application service elements will be active in the cooperating systems
      • identification of the destination process location for communication
        • OSI PSAP (Presentation Service Access Point)
        • TCP/IP port number
      • Presentation context
        • how should the receiver interpret data that arrives
        • {1{PersonnelData, Encrypted}, 2{Annual Report, Compressed}, 3{AnnualReport,Basic}}
a release a abort
A-RELEASE, A-ABORT
  • A-RELEASE: Orderly termination of an association between cooperating processes
  • A-ABORT: Abrupt termination, with possible loss of data
closing an association
Closing an Association

Confirmed service

Unconfirmed service

communication between layers
Communication between layers

Peer to Peer

Service Requestor /

Service Provider

Service Requestor /

Service Provider

Peer to Peer

Service Requestor /

Service Provider

Service Requestor /

Service Provider

within layers
Within layers

Peer to Peer

Service Requestor /

Service Provider

Service Requestor /

Service Provider

Peer to Peer

Service Requestor /

Service Provider

Service Requestor /

Service Provider

parameters
Parameters
  • Information shared between peers and between service requestors and providers
  • Each invocation of a service, or response to a service request, involves information passed both within the local stack and with peers in a cooperating stack.
  • The single list of parameters must be split into those that inform the service provider and those that inform the peer process.
system state regarding protocols
System state regarding protocols
  • A system is in one of a number of states at any given time.
    • The state depends on what conditions are in effect, what has happened so far.
    • The state determines what are possible responses to future events
  • Initial state (Idle)
    • limited set of events are acceptable
    • others are considered error conditions
    • For example, the arrival of data before an association is established would be an error condition
protocol machine
Protocol machine

Key:

Event

Response

The event occurs, the

protocol machine changes

state and performs

the indicated response.

Here the response is

something sent or issued.

Two views: top shows the state transition in graphical form;

bottom shows the layer interaction.

association establishment protocol machine
Association Establishment Protocol Machine

Idle

A-ASSOCIATE.req

AARQ

AARQ

A-ASSOCIATE.ind

Outgoing

association

pending

Incoming

association

pending

AARE

A-ASSOCIATE.conf

A-ASSOCIATE.resp AARE

Association

Established

association established
Association Established
  • Once Association is Established
    • the context of the interaction is established
    • data can be exchanged
    • an orderly termination of the association can be done
  • ACSE is the OSI protocol for establishing an association.
  • Other stacks, like TCP/IP, do not have a named entity for this purpose, but must establish this sort of connection
remote operation
Remote Operation
  • Call for the execution of an operation on a remote system
  • Basic questions related to remote operation
    • What do we know about the data to be used?
    • How will the initiator know when the remote operation is complete?
    • Is it safe to repeat a request if the remote system crashes before completing?
    • Stop and wait or continue working?
rose remote procedure calls
ROSE; remote procedure calls
  • What do we know about the data to be used?
    • ASN.1 and BER or alternatives such as XDR
  • How will the initiator know when the remote operation is complete?
    • Requesting some result from every operation allows the initiator to know when the operation is done
  • Is it safe to repeat a request if the remote system crashes before completing?
    • CCR or its equivalent
  • Stop and wait or continue working?
    • Synchronous or asynchronous invocation
remote operation services
Remote operation services
  • In the OSI protocols,
    • ROSE - The Remote Operation Service Element
  • Other,
    • RPC - Remote Procedure Call
    • RMI - Java’s Remote Method Invocation
rose service
ROSE service
  • RO-INVOKE
    • call a method located in another system
    • have it run in the other system
  • RO-RETURN-RESULT
    • send a result to the invoking method
  • RO-RETURN-ERROR
    • send an error notification to the invoking method
  • RO-REJECT-U/RO-REJECT-P
    • reject the invocation request
rose characteristics
ROSE characteristics
  • Minimal state information
  • All services unconfirmed
  • All responsibility for correctness is on the designer of the application
synchronous or asynchronous
Synchronous or Asynchronous
  • Synchronous
    • blocking
  • Asynchronous
    • non-blocking
    • report results and errors
    • report errors only
    • report results only
    • report nothing
using the definition
Using the definition
  • RO-INVOKE (…,0, “PS”…)
    • other required parameters identify remote system to be contacted, etc.
    • 0 is the identifier of getcount; PS is the name of the queue to examine.
  • RO-RETURN-RESULT (“PS”,250)
      • Queue PS has 250 entries
  • RO-RETURN-ERROR (1, “PS”)
      • Queue PS is not available
remote operation summary
Remote Operation Summary
  • Protocols cover only the communication between the caller and the called method
    • how method is identified
    • what information is provided
    • what is understood between them
  • Separate issue
    • write the method to carry out the desired action
reliable transfer of information
Reliable transfer of information
  • What is needed beyond a dependable transport layer?
    • Protect against errors that occur after the data is delivered to the machine
    • example: Jammed printer or a disk failure prevents completion of the desired action, but the transport layer is satisfied
rtse reliable transport service element
RTSE: Reliable Transport Service Element
  • Invokes services of the session layer, uses ACSE
  • Services provided by RTSE:
    • RT-OPEN
    • RT-TRANSFER
    • RT-TURN-PLEASE
    • RT-TURN-GIVE
    • RT-CLOSE
    • RT-U-ABORT/RT-P-ABORT
rt transfer rt turn
RT-TRANSFER, RT-TURN
  • confirmed service
  • parameters specify data to be sent, maximum time allowed for completion
  • If two-way data transfer, RT-TURN-PLEASE, an unconfirmed service, requests the opportunity to send data; RT-TURN-GIVE, unconfirmed service to yield turn
rtse protocol
RTSE protocol
  • Use A-ASSOCIATE to establish connection with peer
  • Invoke turn-taking facilities of the Session layer
  • Invoke activity management facilities of the Session layer to establish checkpoints between data segments
  • used by X.400 mail system and available to ROSE when a lot of data must be moved
commitment concurrency and recovery
Commitment, Concurrency, and Recovery
  • Commitment:
    • assurance that the server process will carry out a request regardless of difficulties that might arise
  • Concurrency:
    • protection from the intrusion of interleaved operations that interfere with correct completion of a requested task
  • Recovery:
    • establishment of procedures to overcome failures by one or more participating process during execution of a distributed application
the lost transaction problem
The Lost Transaction Problem

Process 1

Credit Limit

Process 2

5,000

Read credit

5000

Read credit

5000

Subtract new purchase

(850) update credit

4,150

Subtract new purchase

(54.50) update credit

4,945.50

Time

ccr services
CCR Services
  • Bracket atomic action
    • C-BEGIN, C-PREPARE
  • SERVER --> CLIENT ready
    • C-READY
  • SERVER --> CLIENT no
    • C-REFUSE
  • CLIENT, SERVER agree to go on
    • C-COMMIT
  • CLIENT --> SERVER no
    • C-ROLLBACK
  • CLIENT/SERVER go back
    • C-RESTART
some tcp ip handy tools
Some TCP/IP handy tools
  • Not exactly the same kind of thing, but useful nonetheless
  • ping
    • sends a message and looks for a response to determine that the other machine is alive and active
  • traceroute
    • displays the path taken by messages between two cooperating systems
  • on sun cluster: /usr/sbin/ping or traceroute
  • NOTE-- overuse of these is considered very unfriendly behavior. Be gentle, considerate.
overall summary
Overall summary
  • Net-centered computing has more elements than computing on a single machine.
  • Many characteristics are the same from one application to another
  • Understand what is the same and what varies between applications