Serv-JSP-CORBA.ppt

Internet Protocols and Applications I

Incheon Paik

2

Some Protocols

HTTP Communication

Connectionless Communication Stateless Communication

(1) TCP Connection Request

(2) HTTP Request

(3) HTTP Response

(4) TCP Connection Close

Client Server

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 Name:Header 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

Web Server CGI Program Processes

Process 1

Process 1

Process 1

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

Classic Web Application Architecture Ajax Architecture

AJAX (Asynchronous JavaScript And XML)

10

Motivations of Servlet and JSP

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)

Slide 9-18, Used the Material by Philippe Rochat

11

Object Web

Web Server

JSP

Servlet

EJB

CORBA

DBMS

Legacy

Application

HTML/XML

Applet

HTTP

HTTP

RMI/IIOP

IIOP

12

Servlet and Servlet Container

Java Servlet API

Servlet Application 1 Servlet Application 2 Servlet Application N

Servlet Container 1 Servlet Container 2 Servlet Container N

Servlet Container: - To run servlet, there need to be JVM to run Java servlet class and servlet container to provide servlet applications with system service.- Deliver HTTP request of a client to servlet application, and HTTP response of the servlet applcation to the client

13

How-to Write Servlet

Very Similar to applet Must inherits

HttpServlet Must implements one of

doGet doPost doPut …

Receives HttpServletRequest HttpServletResponse

14

Life-Cycle

Instantiation

Init()

Service()

Done()

15

Session

public void doGet(HttpServletRequest request, HttpServletResponse response)

HttpSession session = request.getSession(true);

session.setAttribute(dataName, dataValue);

Enumeration e = session.getAttributeNames();

16

Examples

Refer to Apache Tomcat

When you install Apache Tomcat,

http://localhost:8080/servlets-examples/

17

Cookies

public void doGet(HttpServletRequest request, HttpServletResponse response)

Cookie[] cookies = request.getCookies();

response.addCookie(c);

18

Pros and Con’s

Con’s HTML embedded in Java source file

Pro’s Power of Java Platform Speed Portability across servers and DB’s

19

More …

At sun http://java.sun.com/products/servlet/index.ht

ml

Apache http://jakarta.apache.org/tomcat/

Lbdpc15 TomCat documentation

20

Execution of JSP

Web Browser

A user requests .jsp file through URL. Web server requests JSP handler to process .jsp file JSP/Servlet container pass the corresponding .jsp file to JSP handler servlet JSP Handler Servlet

• Check JSP file, execute the existing .class servlet when no change• When there was change, generate .java source code from .jsp• Compile the java source• when .class file was generated normally, execute the servlet.

Web Server

Servlet Container

JSP Handler Servlet

JSP Servlet

JSP RequestHandler Request

JSP File (.jsp)

Java File (.java)

Class File (.class)

JSP File Check

JSP file Compile

Java file Compile

Servlet Invocation

Class Loading

21

JSP Allows HTML embedded tags:

<html><jsp:useBean id="cart" scope="session" class="sessions.DummyCart" /><jsp:setProperty name="cart" property="*" /><%

cart.processRequest(request); %><FONT size = 5 COLOR="#CC0000"><br> You have the following items in your cart:<ol><%

String[] items = cart.getItems();for (int i=0; i<items.length; i++) {

%><li> <%= items[i] %> <%

}%></ol></FONT><hr><%@ include file ="/jsp/sessions/carts.html" %></html>

22

Examples

Refer to Apache Tomcat

When you install Apache Tomcat,

http://localhost:8080/jsp-examples/

Introduction toCommon Object Request

Broker Architecture(CORBA)

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

25

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.

26

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

27

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

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 latencyDetecting and recovering from partial

failures of networks and hostsLoad balancing and service partitioning Consistent ordering of distributed events

29

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

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

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"

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); }

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); }; };

CORBA is Software Bus

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

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

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

37

CO

RB

A

Arc

hit

ectu

re

38

CORBA Architecture

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

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

managementMessage exchange between objects

CORBA ORB provides security also.

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

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

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 generationObject registration and activationObject location and binding

43

Producing IDL file, Client, and Object Implementation

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"

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

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 proxiesproxies are also known as surrogates

The primary advantage of the SII is its simplicity, typesafety, and efficiency

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.

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

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

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.

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

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

EXAMPLE

Bank Example

Bank server maintains the user's accountClients 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

54

Initial OMG IDL Bank Specification

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

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 -> uses the Class form of the Adapter

pattern(inheritance) 2. TIE -> uses the Object form of the Adapter

pattern (object composition)

56

Object Activation, invocation by the BOA

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.init(args,null); // get a reference to the root POA POA rootPOA =

POAHelper.narrow(orb.resolve_initial_references("RootPOA"));

// Create policies for our persistent POA org.omg.CORBA.Policy[] policies = { rootPOA.create_lifespan_policy(LifespanPolicyValue.PERSISTENT) };

58

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_reference(managerServant) + " is ready.");

// Wait for incoming requests orb.run(); } catch (Exception e) { e.printStackTrace(); } } }

59

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 args[0] as the account name, or a default. String name = args.length > 0 ? args[0] : "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); } }

60

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);

61

Implementing the Object

try { // Activate it on the default POA which is root POA for this servant account =

Bank.AccountHelper.narrow(_default_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(); }

62

Run Example

Activate OSAGENT

Server Side <prompt> java Server

Server Activation

Client Side <prompt> java Client [Account Name]

Client can receive the response from Server

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

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

65

Experiences with Java ORBs

ORB Interoperability Visigenic’s 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

66

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)

67

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

68

Interoperability via ORB-to-ORB

69

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.

70

Example of CORBA 2.0 Interoperability

71

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

72

General Inter-ORB Protocol (GIOP)

GoalWidest possibility, availability, Simplicity,

Scalability, Lowcost, Generality, Architectural neutrality

GIOP consists of three specificationThe 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

73

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

74

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

75

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 object’s 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.

76

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

77

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.