Web Application Developer’s Guide phần 10 pps

Modifying the Connector in Tomcat By default the Apache Web Server and Tomcat Web Container are connected via the IIOP Plug-in.. Connecting to the CORBA Server The IIOP Plug-in also enab

M o d i f y i n g W e b c o m p o n e n t c o n n e c t i o n

Modifying Web component connection

Borland Enterprise Server Web Edition provides an operational Apache Web Server and Tomcat Web Container connection as “out of the box” upon start up The two components are connected with each other via the IIOP Plug-in This Plug-in allows both Apache and Tomcat to

communicate via Internet Inter-ORB Protocol (IIOP) to one another with

no required configuration

Figure 18.5 Web components connection via IIOP

jss.softCommit=<true or false> Write to disk but only for crash recovery and not

a full transaction commit.

jss.userName=<char_string> This is the name of the database user.

jss.factoryName=<char_string> The name given to the JSS factory created by this

service The service gets registered with this name in the Smart Agent (osagent).

jss.workingDir=<path> The path of the working directory where the

database files are stored.

jss.pstore=<char_string> The name of the database file that gets created

under the jss.workingDir.

Table 18.2 JSS Properties (continued)

Property Name Description

LoadModule webapp_module <bes-install>/lib/apache/ mod_webapp.so

Note The webapp_module is a dynamic library

3 Tell Apache about the connection using the WebAppConnection directive Have a new connection based on the name of the Tomcat server

WebAppConnection myConnection iiop "tc_inst1"

Note The name corresponds to the name you defined for the Tomcat IIOP

connector instance In this case, "tc_inst1" is the IIOP connector instance for Tomcat

4 Tell Apache to use the WebAppDeploy directive for request handling The IIOP service will handle client request starting with the URL /examples/

WebAppDeploy examples myConnection /examples/

Note You can have multiple line entries for each deployments

5 When completed, Save and exit the file

Modifying the Connector in Tomcat

By default the Apache Web Server and Tomcat Web Container are connected via the IIOP Plug-in However, you can change the connection configuration for this service in the configuration file, server.xml This service has a Connector named IIOP It is capable of sending and receiving IIOP messages by actually talking to the Apache Web Server for getting a request and sending the response

The IIOP service is separated into two portions; the Connector and the Engine/Host

Here is an example of the Connector portion:

<Service name="IIOP">

<ConnectorclassName="org.apache.catalina.connector.iiop.IiopConnector"

name"tc_inst1"

/>

M o d i f y i n g W e b c o m p o n e n t c o n n e c t i o n

The Engine/Host portion has the same parameter values as a normal Tomcat service

Here is an example of the Engine/Host portion:

<Engine name="Iiop" defaultHost="localhost" debug="9">

<Host name="localhost" debug="9" appBase="wars"

unpackWARs="false">

</Host>

</Engine>

Afterwards, save and exit the file

Connecting to the CORBA Server

The IIOP Plug-in also enables Apache to communicate with any

standalone CORBA service, but the VisiBroker ORB is required (See the

“Understanding the Borland Enterprise Server Editions” chapter in the

Borland Enterprise Server Developer’s Guide, and the Borland Enterprise Server Installation Guide for details.) This means you can easily put a

web-based front-end on almost any CORBA server

Figure 18.6 Connecting from Apache to a CORBA server

M o d i f y i n g W e b c o m p o n e n t c o n n e c t i o n

Configuring the IIOP Plug-in for use with CORBA

You must configure Apache’s httpd.conf file in order for the CORBA service to be invoked by the Web Server This involves three steps:

1 Load the mod_webapp using the LoadModule directive This is

achieved by adding the following line to the httpd.conf file:

LoadModule webapp_module c:/<install-dir>/lib/apache/mod_webapp.dll

2 Tell Apache about the connection using the WebAppConnection directive This is achieved by adding the following line to the httpd.conf file:

WebAppConnection <connection-name> <connection-protocol> <object-name>where <connection-name> is the name by which you want your connection referred in your application, <connection-protocol> is the protocol used (e.g iiop), <object-name> is the CORBA object name of the object registered with the Smart Agent

3 Tell Apache how to use the connection using the WebAppDeploy directive The Web Server needs to know which HTTP requests to forward to the connector and which HTTP requests should not be forwarded This is achieved by adding a line of URI mapping to the httpd.conf file:

WebAppDeploy <web-application-name> <connection-name> /<URI-mapping-component>/where <web-application-name> is the name of the web application using the connector, <connection-name> is the name of the connection (the same name as in Step 2), and <URI-mapping-component> is the URI used to identify which HTTP requests should be routed through the connector

A full example of the use of this connector is in the “Apache/Tomcat IIOP

Connector Example” in the Borland Enterprise Server Developer’s Guide.

Interface Definition Language (IDL) for Apache, Tomcat and CORBA Server

The ReqProcessor Interface that allows communication between a web server and a web container using IIOP HTTP request can then be passed from an Apache Web Server to another Tomcat Web Container or a CORBA Server The server must return HttpResponse

Code sample 18.1 IDL Specification for ReqProcessor Interface

*/

module apache { struct NameValue { string name;

string value;

};

typedef sequence<NameValue> NVList;

S e c u r i t y f o r t h e w e b c o m p o n e n t s

/*

* HttpRequest analog */

struct HttpRequest { string authType; // auth type (BASIC,FORM etc) string userid; // username associated with request string appName; // application name (context path) string httpMethod; // PUT, GET etc,

string httpProtocol; // protocol HTTP/1.0, HTTP/1.1 etc string uri; // URI associated with request string args; // query string associated with this request string postData; // POST (form) data associated with request boolean isSecure; // whether client specified https or http string serverHostname; // server hostname specified with URI string serverAddr; // [optionally] server IP address specified // with URI

long serverPort; // server port number specified with URI NVList headers; // headers associated with this request // format: header-name:value };

/*

* HttpResponse analog */

struct HttpResponse { long status; // HTTP status, OK etc

boolean isCommit; // server intends to commit this request NVList headers; // header array

OctetSequence_t data; // data buffer };

interface ReqProcessor { HttpResponse process(in HttpRequest req);

};

};

Security for the web components

The Borland Enterprise Server allows you to secure the web components using the conventions of encryption, authentication, and authorization Like the security measures provided by the J2EE standards, where security is set at the module level, you can also secure web components by declaring the security mechanism within their configuration files

Security for the Apache Web Server

The Apache Web Server uses data transport encryption technology for security The Borland Enterprise Server uses the mod_ssl module for this purpose This module provides strong cryptography for Apache Web Server via the Secure Sockets Layer (SSL v2/v3) and Transport Layer

S e c u r i t y f o r t h e w e b c o m p o n e n t s

Security (TLS v1) protocols by the help of the Open Source SSL/TLS toolkit OpenSSL

Security for the Tomcat Web Container

The Borland Enterprise Server allows you to control access to the web resources by declaring the security roles This information is specified in the deployment descriptor tags and the runtime environment, when validation is required To set up the declarative security, do the following:

This code example enables security on any URL pattern containing

“servlet” in its path The module deployment descriptor indicate which security roles are allowed to access the web resource Also, the

authorization constraint indicates that the roles of “tomcat” and “role1” allowed user with these names access to the web resources

2 Next, you want to set up authentication realms In the server.xml file, add a realm name to authenticate user access Borland provides the LoginModules, which are realms that you can define as shown below

<Realm className="org.apache.catalina.realm.BSSRealm" name="NTLogin"/>The realm name, “NTLogin” is user defined The Borland Security Service Realm corresponds to any of the names in the authentication configuration file, below

For more information on rolemap, see the “Authentication” chapter in

the Borland Enterprise Server Developer’s Guide.

You can add the realm at any level you want within the Tomcat component structure For example, you can add a realm at the engine level You can also add a realm at the host level But if you have multiple hosts, and one of those hosts does not have a specific realm assigned to it, then that host will take the realm properties at the engine level This is also true if you do not assign a realm at a context level, it will take the realm properties from the first host level with a realm The realm interaction is illustrated in the example below

//For this context, webapp2 uses the

“hRealm” from host 1

S e c u r i t y f o r t h e w e b c o m p o n e n t s

The role of “Manager” is listed in the rolemap file This role must be mapped using the authorization constraint specified in web.xml, for example:

Borland Enterprise Server Developer’s Guide.

Alternatively, you can set up for a three-tier authorization scheme to accommodate a more complex client/server landscape As illustrated in the diagram below, a three-tier authorization scheme can include a client browser, a web container, and an EJB container

Figure 18.7 Three-tier authorization scheme

The server-side has two different container components with security mechanism in each of them So when a user (John) sends a client request, his login ID is authorized and authenticated at the web container level Lets say that the client request requires the servlet running at the web container to access a bean in the EJB container However, the EJB container does not know the user, “John” You have two options to extend security to the EJB container The first and most common is to make the EJB container knowledgeable of all users The second is to use the concept

of “run as” When the web container makes a EJB invocation, the web container will “run as” a user that the EJB container recognize The web application can be configured with a “run as” user to access the third-tier component The web application with the servlet making the EJB

invocation can be configured with “run as” user “web container” In this case, though the real user is “John”, the EJB container acknowledges the user as “web container”

D a t a E x c h a n g e u s i n g S O A P a n d C o c o o n

Setting up ‘Run As’ role

The Borland web container, Tomcat, supports the “run as” configuration for web applications The web application can be set up with the “run as” role which maps to a user In the code example below, the “run as” role is configured for the web application

In the web.xml file of the web application you must have entries similar to:

<web-app>

<servlet>

<servlet-name>

HelloWorldExample </servlet-name>

<servlet-class>

hot.HelloWorldExample </servlet-class>

Data Exchange using SOAP and Cocoon

The Web Edition includes support for the Simple Object Access Protocol (SOAP) and the Apache Cocoon The Cocoon servlet is pre-installed in the Tomcat Web Container

About SOAP

SOAP is a protocol for exchanging XML-formatted messages between network peers SOAP is used for implementing Web Services These services can be invoked within the Tomcat Web Container via HTTP requests executed either from standalone Java applications or embedded within the web applications that are run from a browser

The Web Edition includes the SOAP pre-installed with the Tomcat Web Container as a web application (soap.war) There are several examples of

C l u s t e r i n g o f m u l t i p l e w e b c o m p o n e n t s

SOAP services that are also included so that they are available “out of the box” In addition, a jar file is provided for you to develop and run SOAP clients

Note For detailed information on deploying the SOAP example, see the

“Additional Features and Examples” chapter in the Borland Enterprise

Server Developer’s Guide

About Cocoon

Cocoon is a web publishing framework that renders XML data into a number of formats including HTML, WML, PDF, and the like These formats are based on a set of properties provided by an XSL stylesheet.The Web Edition includes the Cocoon servlet pre-installed in the Tomcat Web container The web.xml file contains specifications for the Cocoon servlet, which is pre-configured to point to the cocoon properties file in the WEB-INF directory of the context under which Cocoon is invoked However, you can change this specification to point to another location if desired Additionally, the web.xml file includes a mapping for “*.xml” directing any such file to be processed by Cocoon This mapping can be modified or deleted

An unmodified copy of the properties file is included as part of the Cocoon webapp (cocoon.war) distributed with the Web Edition You can customize this file to create your own cocoon.properties file This unmodified cocoon.properties file is compiled in with the Tomcat Web Container As the default properties file, it is used whenever the file specified in the Cocoon servlet definition cannot be found

Cocoon is an open-source product distributed by the Apache Software Foundation For additional information about Cocoon, see the website:http://xml.apache.org/cocoon/

Clustering of multiple web components

In a typical deployment scenario, you can use multiple Borland Partitions

to work together in providing a scalable n-tier solution Each Borland Partition can have the same or different services These services can be turned off or on depending on your clustering schema In any case, leveraging these resources together or clustering, makes deployment of your web application more efficient Clustering of the web components involve session management, load balancing and fault tolerance (failover)

C l u s t e r i n g o f m u l t i p l e w e b c o m p o n e n t s

Interaction between the client and server involves two types of connection services: stateless and stateful A stateless service does not maintain a state between the client and the server There is no “conversation” between the server and the client while processing a client request In a stateful service, the client and server maintains a dialogue of information, thereby having multiple interactions with one another the client in the context of the same session

Stateless service

The Borland Enterprise Server Web Edition supports clustering of web components For a stateless connection, a single Apache Web Server is connected to multiple Tomcat Web Containers The diagram below shows how the web components are connected using IIOP in conjunction with the JSS

Figure 18.8 Apache and Tomcat communicate via IIOP

In this example, the first client request goes to Tomcat 1 The second client request goes to Tomcat 2 The third client request goes to Tomcat 1 And

so forth

Fault tolerance

When the first instance of Tomcat goes down, the Apache Web Server transparently re-routing of all client requests to the second instance of Tomcat Since this is a stateless connection (no session), the JSS is not involved

Stateful service

In a stateful service, the web components (Apache and Tomcat servers) maintain the “conversational” interaction within the same context of a session If the first Tomcat instance goes down, another instance of Tomcat can then pick up where the first Tomcat left off since it gets session information from the JSS

Session management

The JSS is responsible for session management of clustered web components It does not support load balancing indiscriminately, meaning that the Apache Web Server needs to send data to the first Tomcat instance that it initially started in the session The proceeding session is then sent to the next Tomcat instance And so forth In the

C l u s t e r i n g o f m u l t i p l e w e b c o m p o n e n t s

diagram below, Session 1 is sent to the first Tomcat instance and Session 2

is sent to the second instance of Tomcat Any client request from Session 1 will always be serviced in the first Tomcat instance

Figure 18.9 Session Management for multiple Tomcats

JSS role

In a stateful service connection, the JSS provides session management to all Tomcat Web Containers Session data between the client and a specific Tomcat instance is “flushed” to the JSS for session management