serv-jsp-corba.ppt
TRANSCRIPT
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.