Internet Protocols and Applications I

1
Internet Protocols and Applications I
2
Some Protocols

• HTTP Communication
• Connectionless Communication
• Stateless Communication

(1) TCP Connection Request
(2) HTTP Request
Server
Client
(3) HTTP Response
(4) TCP Connection Close
3
Some Protocols

• HTTP Message
• Start Line Client Request Information /
  Response Status Information
• Message Header Additional Information for HTTP
  Message such as Date, Program Name, Version,
  Cookie, User Authentication, Cache
• Message Body Contents for Request or Response.
  In case of POST, Input data consists of data
  stream encoded in request message.

4
Some Protocols

• Client Request Message in HTTP
• Request HTTP Command, URI, and HTTP Version,
  Header NameHeader Value, Request Message Body
• HTTP Command GET, HEAD, POST/ OPTIONS, PUT,
  DELETE, LINK, UNLINK, TRACE
• Server Response Message in HTTP
• Response Message HTTP Version, Status Code,
  Code Description, Response Header, Response
  Message Body
• Response Status Code (Reference 100-199),
  (Success 200-299), (Redirection 300-399),
  (Incomplete 400-499), (Server Error 500-599)

5
Some Protocols

• HTTP Message Header
• HTTP Header Used for transmitting any kinds of
  information between client and server, Header
  Name Blank Header-value
• General Header Client Request, Server Response,
  Cache setup, Connection, Date, etc
• Client Request Header Client information and
  preferred data type, Accept Character set,
  encoding type, and authorization
• Response Header Server Information, Message
  processing methods for response message. Web
  server information, Cookie setup, authenticate
  information.
• Entity Header HTTP message body information,
  encoding method of message, contents length, MD5
  information, encoding method of contents
  transmission, MIME type

6
Some Protocols

• MIME Type
• As HTTP transmission deal with multimedia
  documents, pre-defined method to deal with that
  data by client should be described.
• MIME(Multipurpose Internet Mail Extension) Type
• Client Using Accept Header, Clients can define
  their preferred media type
• Server Describe MIME Type in Content-Type
  Header
• MIME Type form Type/Subtype (ex
  application/x-javascript)
• Standard MIME Type
• Text, Multipart, Message, Application, Image,
  Audio, Video

7
CGI Communication

• CGI(Common Gateway Interface)
• Transmit Messages by GET/POST Method
• Characteristics
• Extend Web Server, Dynamic Response, Only Install
  in Server Side
• Overhead, Security, Interactive pages, Cannot
  keep the connection Problems

Process 1
Process 1
Process 1
Web Server
CGI Program
Processes
8
Extended CGI

• ASP (Active Server Page) of Microsoft
• Combine HTML, Server side Script, and Server side
  Component
• Written in Jscript, VBScript, and run on IIS
  Server
• Can use COM Component
• Java Servlet and JSP
• Platform Independent, Safe and Effective Thread
  Service, Object Oriented Paradigm
• Easy to interoperate with Legacy Application
• JSP is similar to ASP, and provide HTML script
  language and JavaBeans Component
• Object Web
• CORBA (Common Object Request Broker Architecture)
• EJB (Enterprise JavaBeans)
• DCOM (Distributed Common Object Model)

9
Motivations of Servlet and JSP
Slide 9-18, Used the Material by Philippe Rochat

• Faster than CGI (no process creation overhead)
• Java is Internet oriented
• Servlet API
• Security
• Session support
• Code reuse and portability
• JDBC support
• Next step Enterprise Java Beans (EJB)

10
How-to

• Very Similar to applet
• Must inherits
• HttpServlet
• Must implements one of
• doGet
• doPost
• doPut
• Receives
• HttpServletRequest
• HttpServletResponse

11
Life-Cycle

• Instanciation
• Init()
• Service()
• Done()

12
Session

• public void doGet(HttpServletRequest request,
  HttpServletResponse response)
• HttpSession session request.getSession(true)
• session.setAttribute(dataName, dataValue)
• Enumeration e session.getAttributeNames()

13
Example

• Refer Apache Tomcat

14
Cookies

• public void doGet(HttpServletRequest request,
  HttpServletResponse response)
• Cookie cookies request.getCookies()
• response.addCookie(c)

15
Pros and Cons

• Cons
• HTML embedded in Java source file
• Pros
• Power of Java Platform
• Speed
• Portability across servers and DBs

16
More

• At sun
• http//java.sun.com/products/servlet/index.html
• Apache
• http//jakarta.apache.org/tomcat/
• Lbdpc15
• TomCat documentation

17
JSP

• Allows HTML embedded tags
• lthtmlgt
• ltjspuseBean id"cart" scope"session"
  class"sessions.DummyCart" /gt
• ltjspsetProperty name"cart" property"" /gt
• lt
• cart.processRequest(request)
• gt
• ltFONT size 5 COLOR"CC0000"gt
• ltbrgt You have the following items in your cart
• ltolgt
• lt
• String items cart.getItems()
• for (int i0 iltitems.length i)
• gt
• ltligt lt itemsi gt
• lt
• gt
• lt/olgt

18
Introduction toCommon Object Request Broker
Architecture(CORBA)
19
Contents

• Overview of distributed programming challenges
• Overview of CORBA architecture
• CORBA programming with Java ORB
• WWW, Java and CORBA
• GIOP and IIOP
• Trends in Internet

20
Introduction

• Developing distributed applications whose
  components collaborate efficiently, reliabley,
  transparently, and scalably is hard.
• To help address this challenge, the Object
  Management Group(OMG) is specifying the CORBA
• OMG is a consortium of 700 more strong computer
  compaines and universities.
• Netscape, Sun, HP, DEC, Mircrosoft, IBM,
  Visigenic, IONA, etc.

21
History of OMG CORBA

• 1991 CORBA version 1.1 published
• 1992 - 1996 CORBA Core and Interoperability
  Architecture Communications
• 1994 CORBA 2.0 published, including
  Interoperable Specification
• 1994 - 1996 CORBAservices Basic Services for
  Object-Oriented Application
• May, 1996 CORBA Task Force issues Secure
  Interoperability Protocol
• 1995 - CORBAfacilities Application
  level Data Manipulation Storage

22
History of OMG CORBA

• 1997 CORBA version 2.1 Identify
  Problems
• 1998 CORBA 2.2 Portable Object
  Adapter Management of Lifetime Server Object,
  Portability
• CORBA 2.3 Object By Value
• 1999 CORBA 3 Internet Integration,
  QoS, CORBA Component Architecture

23
Source of Complexity

• Distributed application development exhibits both
  inherent and accidental complexity
• Inherent Complexity results from fundamental
  Challenges in the distributed application domain,
  e.g.,
• Addressing the impact of latency
• Detecting and recovering from partial failures of
  networks and hosts
• Load balancing and service partitioning
• Consistent ordering of distributed events

24
Source of Complexity

• Accidental complexity results from limitations
  with tools and techniques used to develop
  distributed applications.
• Lack of type-safe, portable, re-entrant, and
  extensible system call interfaces and
  component libraries
• Inadequate debugging support
• Widespread use of algorithmic decomposition
• Fine for explaining network programming
  concepts and algorithms but inadequate for
  developing large-scale distributed applications
• Continuous rediscovery and reinvention of core
  concepts and components

25
Motivation for CORBA

• Simplifies application interworking
• CORBA provides higher level integration than
  traditional "untyped TCP byte streams "
• Provides a foundation for higher-level
  distributed object collaboration
• e.g., Windows OLE and the OMG Common Object
  Service Specification(COSS)
• Benefits for distributed programming
  similar to OO languages for
  non-distributed programming
• e.g., encapsulation, interface inheritance, and
  object-based exception handling

26
CORBA Contributions

• CORBA addresses two challenges of developing
  distributed system
• Making distributed application development no
  more difficult than developing centralized
  programs.
• Easier said than done due to
• Partial failures
• Impact of latency
• Load balancing
• Event Ordering
• Providing an infrastructure to integrate
  application components into a distributed system
• i.e., CORBA is an "enabling technology"

27
CORBA Bank Example (Old Version)

• Ideally, to use a distributed service, we'd like
  it to look much like a non-distributed service
• public static void main(String args)
• Bank.AccountManager manager Bank.AccountManager_
  var.bind(My Bank")
• Bank.Account account manager.open(name)
• float balance account.balance()
• System.out.println ("The balance in " name
  "'s account is " balance)

28
CORBA Bank Interface

• We need to write an OMG IDL. Interface for our
  Bank object
• This interface is used by both clients and
  servers
• // Bank.idl
• module Bank
• interface Account
• float balance()
• interface AccountManager
• Account open(in string name)

29
CORBA is Software Bus

• CORBA provides a communication infrastructure for
  a heterogeneous, distributed collection of
  collaborating objects.

30
Related Works

• Related technologies for application integration
  include
• Traditional RPC
• Provides "procedural" integration of application
  serveices
• Doesn't provide object abstractions
• Does not address inheritance of interfaces
• Widows OLE/COM
• Traditionally limited to desktop application

31
CORBA Components

• The CORBA specification is comprised of several
  parts
• 1. An Object Request Broker (ORB)
• 2. Basic Object Adapter (BOA), Portable Object
  Adapter(POA)
• 3. An Interface Definition Language (IDL)
• 4. A Static Invocation Interface (SII)
• 5. A Dynamic Invocation Interface (DII)
• 6. A Dynamic Skeleton Interface(DSI)
• 7. Interface and implementation repositories
• 8. Programming language mappings
• 9. An Interoperability Spec(GIOP and IIOP)
• Other documents form OMG descirbe common object
  services built upon CORBAservices
• e.g. , Event services, Name services, Lifecycle
  service

32
CORBA Architecture
33
CORBA Architecture

• The ORB is the foundation of all other CORBA
  services and facilities

34
Object Request Broker

• The Object Request Broker(ORB) is the central
  component in CORBA
• An ORB provides mechanisms for invoking methods
  on local/remote objects
• ORB mechanisms automate
• Object location, creation, activation and object
  management
• Message exchange between objects
• CORBA ORB provides security also.

35
Interface Definition Language (IDL)

• Developing flexible distributed applications
  on heterogeneous platforms requires a strict
  separation of interface from implementation(s)
• Benefits of using an IDL
• Ensure platform independence
• e.g., Windows NT to UNIX
• Enforce modularity
• e.g., must separate concerns
• Increase robustness
• e.g., reduce opportunities for network
  programming errors
• Enable language independence
• e.g., C, Smalltalk, COBOL to C, Java

36
CORBA IDL

• OMG IDL is an object-oriented interface
  definition language
• Used to specify interfaces containing operations
  and attributes
• OMG IDL support interface inheritance (both
  single and multiple inheritance)
• OMG IDL is designed to map onto multiple
  programming languages
• e.g., C, C, Smalltalk, COBOL, Modula 3, DCE,
  Java, etc.
• OMG IDL is similar to Java interfaces, class and
  C class

37
OMG IDL Compiler

• A OMG IDL compiler generates client stubs and
  server skeletons
• Stubs and skeletons automate the following
  activities (in conjunction with the ORB)
• Client proxy factories
• Prameter marshalling/demarshalling
• Implementation class interface generation
• Object registration and activation
• Object location and binding

38
Producing IDL file, Client, and Object
Implementation
39
Application Interfaces

• Interfaces described using OMG IDL may be
  application-specific, e.g.,
• Databases
• Spreadsheets
• Spell checker
• Network manager
• Air traffic control
• Documents
• Medical imaging systems
• Objects may be defined at any level of
  granularity
• e.g., from fine-grained GUI objects to multi-mega
  byte multimedia "Blobs"

40
OMG IDL Features

• OMG IDL is a superset of C, Java, etc.
• Note, it is not a complete programming language,
  it only defines interfaces
• OMG IDL supports the following features
• Modules
• Interfaces
• Operations
• Attributes
• Inheritance
• Basic types(e.g., double, long, char, etc).
• Arrays
• Sequence
• Struct, enum, union, typedef
• Consts
• Exceptions

41
Static Invocation Interface(SII)

• The most common way of using OMG IDL involves
  the "Static Invocation Interface" (SII)
• In this case, all the methods are specified in
  advance and are know to the client and the
  server via proxies
• proxies are also known as surrogates
• The primary advantage of the SII is its
  simplicity, typesafety, and efficiency

42
Dynamic Invocation Interface (DII)

• A less common way of using OMG IDL involves the
  "Dynamic Invocation Interface" (DII)
• The DII enables objects and their methods to be
  specified and called at run-time
• Uses meta-data stored in an "Interface
  Repository"
• The DII is more flexible than the SII apporach,
  e.g.,
• It supports tools tools like a MIB browser that
  may not know all their components or operations
  at compile-time
• It also enables the use of deferred synchronous
  invocation
• The DII is also more complicated and less
  typesafe and efficient.

43
Dynamic Skeleton Interface (DSI)

• The "Dynamic Skeleton Interface" (DSI) provides
  analogous functionality for the server-side that
  the DII provides on the client-side
• It is defined in CORBA 2.0 primarily for using
  building ORB "Bridges"
• The DSI lets server code handle arbitrary
  invocations on CORBA objects

44
Object References

• An "Object reference" is an opaque handle to an
  object
• Object references amy be passed among processes
  on separate hosts
• The underlying CORBA ORB will correctly convert
  object references into a form that can be
  transmitted over the network
• Presumably by converting it to a "stringfied"
  reference
• The ORB passes the receiver's implementation a
  pointer to a proxy in its own address space
• This proxy refers to the object's implementation
• Object references are a powerful feature of CORBA
• e.g., supports "peer-to-peer" interactions

45
Object Adaptor

• CORBA "object adaptors" provide services for
  binding object references to their associated
  object implementations
• Several types of object adaptors are available
• Basic Object Adaptor(BOA)
• Objects and object references are known to the
  ORB
• Thus, an object implementation has to explicitly
  register objects to be activated
• Object-Oriented Database Adaptor(OODA)
• This adapter uses a connection to an o-o db to
  access the objects stored in it.
• Since the OODB provides the emthods and
  persistent storage, object may be registerd
  implicitly.

46
Object Adaptor

• Creation and Analysis of Object Reference
• Method Invocation
• Interaction
• Activation and Deactivation of Object and
  Implementation
• Matching to Object Implementation According to
  Object Reference
• Registration of Object
• Problem of BOA
• Inconsistency of Specification
• Difference of BOA Implementation
• Problem in Server Portability

47
Portable Object Adaptor

• Allow the Persistent Object
• Allow more Object Implementation
•  
• Characteristics
• Map an Object Reference to the Servant that
  Implements that object
• Allow Transparent Activation of Objects
• Associate Policy Information With Objects
• Make a CORBA object persistent over several
  server process lifetimes
• Object ID Namespace
• Policy of Multi-Threading, Security, Object
  Management
• Multi POA with different policy and name space
  exist in a server

48
EXAMPLE

• Bank Example
• Bank server maintains the user's account
• Clients can request to open his account and to
  ask his balance via CORBA interfaces and CORBA
  run-time
• Since the server(s) and the clients are
  distributed, the solution must work across LAN
  and WAN environments

49
Initial OMG IDL Bank Specification

• // Bank.idl
• module Bank
• interface Account
• float balance()
• interface AccountManager
• Account open(in string name)

50
Compiling the Interface Definition

• Running the Bank module definition through the
  IDL compiler generates client stubs and server
  skeletons
• The client stub acts as a proxy and handles
  object binding and parameter marshalling from
  requestor
• The server skeleton handles object registration,
  activation, and parameter demarshalling from
  target
• CORBA allows two ways to associate an object
  implementation to a generated IDL skeleton
• 1. BOAImpl -gt uses the Class form of the Adapter
  pattern(inheritance)
• 2. TIE -gt uses the Object form of the Adapter
  pattern (object composition)

51
Object Activation, invocation by the BOA
52
Main Server Program

• Developer Can Register or Activate the Objects on
  Server according to Policy
• // Server.java
• import org.omg.PortableServer.
• public class Server
• public static void main(String args)
• try
• // Initialize the ORB.
• org.omg.CORBA.ORB orb org.omg.CORBA.ORB.in
  it(args,null)
• // get a reference to the root POA
• POA rootPOA POAHelper.narrow(orb.resolve_i
  nitial_references("RootPOA"))
• // Create policies for our persistent POA
• org.omg.CORBA.Policy policies
• rootPOA.create_lifespan_policy(LifespanPolicyValue
  .PERSISTENT)

53
Main Server Program (Continued)

• // Create myPOA with the right policies
• POA myPOA rootPOA.create_POA(
  "bank_agent_poa", rootPOA.the_POAManager(),
  policies )
• // Create the servant
• AccountManagerImpl managerServant new
  AccountManagerImpl()
• // Decide on the ID for the servant
• byte managerId "BankManager".getBytes()
• // Activate the servant with the ID on myPOA
• myPOA.activate_object_with_id(managerId,
  managerServant)
• // Activate the POA manager
• rootPOA.the_POAManager().activate()
• System.out.println(myPOA.servant_to_referenc
  e(managerServant) "
  is ready.")
• // Wait for incoming requests
• orb.run()
• catch (Exception e)
  e.printStackTrace()

54
A Client Program

• // Client.java
• public class Client
• public static void main(String args)
• // Initialize the ORB.
• org.omg.CORBA.ORB orb org.omg.CORBA.ORB.init
  (args,null)
• // Get the manager Id
• byte managerId "BankManager".getBytes()
• // Locate an account manager. Give the full
  POA name and the servant ID.
• Bank.AccountManager manager
• Bank.AccountManagerHelper.bind(orb,
  "/bank_agent_poa", managerId)
• // use args0 as the account name, or a
  default.
• String name args.length gt 0 ? args0
  "Jack B. Quick"
• // Request the account manager to open a
  named account.
• Bank.Account account manager.open(name)
• // Get the balance of the account.
• float balance account.balance()
• // Print out the balance.
• System.out.println
• ("The balance in " name "'s account is
  " balance)

55
Implementing the Object

• // AccountManagerImpl.java
• import org.omg.PortableServer.
• import java.util.
• public class AccountManagerImpl extends
  Bank.AccountManagerPOA
• public synchronized Bank.Account open(String
  name)
• // Lookup the account in the account
  dictionary.
• Bank.Account account (Bank.Account)
  _accounts.get(name)
• // If there was no account in the dictionary,
  create one.
• if(account null)
• // Make up the account's balance, between 0
  and 1000 dollars.
• float balance Math.abs(_random.nextInt())
  100000 / 100f
• // Create the account implementation, given
  the balance.
• AccountImpl accountServant new
  AccountImpl(balance)

56
Implementing the Object

• try
• // Activate it on the default POA which
  is root POA for this servant
• account Bank.AccountHelper.narrow(_defau
  lt_POA().servant_to_reference(accountServant))
• catch (Exception e)
• e.printStackTrace()
• // Print out the new account.
• System.out.println("Created " name "'s
  account " account)
• // Save the account in the account
  dictionary.
• _accounts.put(name, account)
• // Return the account.
• return account
• private Dictionary _accounts new Hashtable()
• private Random _random new Random()

57
Run Example

• Activate OSAGENT
• Server Side
• ltpromptgt java Server
• Server Activation
• Client Side
• ltpromptgt java Client Account Name
• Client can receive the response from Server

58
OMG IDL Mapping Rules

• The CORBA specification defines mappings from
  CORBA IDL to various programming language
• e.g., C, C, Java, Smalltalk
• Mapping OMG IDL to Java
• Each module is mapped to package
• Each interface within a module is mapped to
  abstract class or fully implemented class
• Each operation is mapped to a Java method with
  appropriate parameters
• Each read/write attribute is mapped to a pair of
  get/set methods
• A read-only attribute is only mapped to a single
  get method

59
Binding a Client to a Target Object

• Three typical steps
• 1. A CORBA client (requestor) obtains an "object
  reference" from a server
• e.g., May use a naming service or a locator
  service
• 2. This object reference serves as a local proxy
  for the remote target object
• 3. The client may then invoke methods on its
  proxy
• Recall that object references may be passed as
  parameters to other remote objects

60
Experiences with Java ORBs

• ORB Interoperability
• Visigenics Black Widow(now, VisiBroker) supports
  the CORBA 2.0 IIOP
• DSTC provide a permanent ORB Interoperability
  showcase
• Java language binding for CORBA
• Development time can be significantly reduced
  when using Java instead of C
• Portability
• Java ORB profit from Java portability
• Performance
• Now, Java ORBs do not perform very well(about 20
  times longer)
• But, faster compiler (e.g., Just-in Time
  Compiler) will solve it
• Applet clients vs. CGI based clients
• Middleware advantages
• automatic generation of stub code
• separating interfaces from implementations
• automatic type checking

61
Internet Inter-ORB Protocol(IIOP)

• Interoperability Via ORB-to-ORB
• ORB Interoperability Architecture
• Example of CORBA 2.0 Interoperability
• Interoperable Object Reference
• General Inter-ORB Protocol(GIOP)
• Internet Inter-ORB Protocol (IIOP)

62
Interoperability Via ORB-to-ORB

• All of the clients connected to ORB 1 can access
  object implementations in both ORB 1 and ORB 2
• The same condition holds for clients connected to
  ORB 2
• This architecture scales to any number of
  connected ORBs

63
Interoperability via ORB-to-ORB
64
ORB Interoperability Architecture

• Immediate bridging
• two domains talk directly to each other over a
  single bridge that translate whatever parts of
  the message require it.
• fast and efficient but inflexible and require a
  lot of bridges
• Mediated bridging
• All domains bridge to a single common protocol
• common protocol is IIOP
• the number of bridge types only grows as fast as
  the number of different domains.
• this conforms to the backbone configuration of
  most large, multiprotocol networks mediated
  bridging configures naturally in these networks.

65
Example of CORBA 2.0 Interoperability
66
Interoperable Object Reference (IOR)

• Specialized Object Reference
• Be used by an application in the exact same way
  that an object reference is used
• allows an application to make remote method calls
  on a CORBA object
• An application which obtain IOR, it can access
  the remote CORBA object via IIOP
• The application constructs a GIOP message and
  sends it
• The IOR contains all the information needed to
  route the message directly to the appropriate
  server

67
General Inter-ORB Protocol (GIOP)

• Goal
• Widest possibility, availability, Simplicity,
  Scalability, Lowcost, Generality, Architectural
  neutrality
• GIOP consists of three specification
• The Common Data Representation (CDR) definition
• Trasnfer syntax, mapping from data types defined
  in OMG IDL to a bicanonica, low-level
  representation for transfer between agents.
• SPEC takes into account byte ordering and
  alignment

68
General Inter-ORB Protocol (Continued)

• GIOP message formats
• carry requests, locate object implementations,
  and manage communication channels.
• Message Header
• include magic number, version number, byte
  order, message type, message size
• Seven Messages
• Be sent by the client Request, CancelRequest,
  LocateRequest
• Be sent by Server Reply, LocateReply,
  CloseConnection
• Both may send MessageError

69
General Inter-ORB Protocol (Continued)

• GIOP transport requirements
• a connection-oriented protocol
• reliable delivery (byte order must be preserved,
  and acknowledgment of delivery must be available)
• participants must be notified of disorderly
  connection loss
• the model of initiating a connection must meet
  certain requirements

70
Internet Inter-ORB Protocol (IIOP)

• The mapping of the GIOP message transfer to
  TCP/IP connections is called IIOP
• GIOP can map to Novell IPX and OSI also
• TCP/IP Connection Usage
• Servers must listen for connection requests.
• A client needing a objects services must
  initiate a connection with the address specified
  in the IOR, with a connection request
• The listening server may accept or reject the
  connection.
• Once a connection is accepted, the client may
  send Request, LocateRequest, or CancelRequest
  messages by writing to the TCP/IP socket it owns
  for the connection.

71
CORBA Common Services

• Basic Services to build distributed object system
• Naming, Event, Persistence, Life Cycle,
  Concurrency, Externalization, Relation,
  Transaction, Timing, License, Security,Property,
  Query, Trader, Collection, Startup, Interface
  type Version Management Services

72
CORBA Common Facilities

• Software Components to provide some application
  function
• Horizontal facilities, Vertical facilities
• Horizontal facilities Compound Presentation,
  Compound Interchange, Internalization, Time
  Operations, Mobile Agent, System Management
• Vertical facilities Healthcare, Financial
  Facilities.