Web Application Developer’s Guide phần 10 pps

Using the Borland Enterprise Server Web Edition 18-11 Modifying Web component connection 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 18-12 Web Application Developer’ s Guide Modifying Web component connection Modifying Apache To modify the Apache Web Server to a Tomcat Web Container, use the following steps: 1 Open the configuration file, httpd.conf. It is located in the directory path, such as: <bes_home>\var\servers\<server_name>\apache1\conf\ You must edit the file by adding new lines of instruction discussed in the following steps. 2 Load the mod_webapp using the LoadModule directive. You are loading a new connection using a module name. 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"> <Connector className="org.apache.catalina.connector.iiop.IiopConnector" name"tc_inst1" /> where "tc_inst1" is the name that Apache must point to. Using the Borland Enterprise Server Web Edition 18-13 Modifying Web component connection 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 18-14 Web Application Developer’ s Guide Modifying Web component connection 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; typedef sequence<octet> OctetSequence_t; Using the Borland Enterprise Server Web Edition 18-15 Security for the web components /* * 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 18-16 Web Application Developer’ s Guide Security for the web components 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: Authentication setup 1 Open the web.xml file (deployment descriptor) and identify the security constraint for the web application: <security-constraint> <web-resource-collection> <web-resource-name>Protected Area</web-resource-name> <! Define the context-relative URL(s)to be protected > <url-pattern>/servlet/*</url-pattern> <! If you list http methods,only those methods are protected > <http-method>DELETE</http-method> <http-method>GET</http-method> <http-method>POST</http-method> <http-method>PUT</http-method> </web-resource-collection> <auth-constraint> <! Anyone with one of the listed roles may access this area > <role-name>tomcat</role-name> <role-name>role1</role-name> </auth-constraint> </security-constraint> 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. Using the Borland Enterprise Server Web Edition 18-17 Security for the web components NTLogin { com.borland.security.provider.authn.NTLoginModule required; }; UnixRealm { com.borland.security.provider.authn.UNIXLoginModule required; }; MyRealm { com.borland.security.provider.authn.JDSLoginModule required; } 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. <engine> <realm“eRealm” /> <host h1> <realm “hRealm” /> <context webapp1> <realm “cRealm” /> </context> <context webapp2> //For this context, webapp2 uses the “hRealm” from host 1. </context> </host> <host h2> //For host 2, it uses “eRealm” from the engine. </engine> Authorization setup Set up for basic (two-tier) authorization for users of the Tomcat Web Container. Authorization is defined through a rolemap file where user roles are listed. The code example below shows a typical rolemap. Manager { * (USERID=vbdev, groupname=vvseng) } Customer { *groupname=vvseng } Someother { *groupname=vvseng } 18-18 Web Application Developer’ s Guide Security for the web components 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: <auth-constraint> <! Anyone with one of the listed roles may access this area > <role-name>tomcat</role-name> <role-name>Manager</role-name> </auth-constraint> This example of the auth-constraint is the same code snippet from the security constraint previously mentioned in the Authentication Setup. For more information on rolemap, see the “Authentication” chapter in the 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”. Using the Borland Enterprise Server Web Edition 18-19 Data Exchange using SOAP and Cocoon 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> <run-as> <description>Run as Web Container</description> <role-name>Web-Container</role-name> </run-as> </servlet> </web-app> Beside setting the “run as” role in the web.xml, you also must set a principal to map to the “run as” role. Set the property: vbroker.security.domain.<domain name>.runas.<run as role> =<principal> as an example: vbroker.security.domain.authz_dom1.runas.Web-Container= ejb-user Afterward, whenever the /servlet/HelloWorldExample is accessed by the user, the that user will be set to ‘ejb-user’ for the duration of invocation. 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 18-20 Web Application Developer’ s Guide Clustering of multiple web components 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.xm l 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). [...]... 15-5 servlets 15-3, 15-5 S sandbox applet security 4 -10 Web Start application security 17-1 I-4 Web Application Developer’s Guide security applet restrictions 4-11 applets 4-11 for a Web Start application 17-1 for a WebApp 16-15 sandbox 4 -10 security manager 4 -10 signing applets 4-11 security constraint adding to web. xml file 16-5 Security page in WebApp DD Editor 16-15 servlet API 5-3 servlet HTTP... 4-9 applets 4-8, 4-13 applications 17-1 archive file 16-1 by file type 3 -10 JSP 16-3 servlets 5-8, 16-2 WAR file 16-1 WebApp 16-1 deployment descriptors 3-1 editing 3-2 for a WebApp 3-3 more information 16-18 node of WebApp 3-4 vendor-specific for a WebApp 16-17 web application 16-3 web. xml file 3-4, 16-4 WebApp DD Editor 16-4 developer support 1-5 distributed applications vs web applications documentation... file (web archive) 3-2 adding applets 3-11 adding JAR files 3-11 definition of 3 -10 deploying 16-1 generating 3-3 included file types 3 -10 properties 3 -10 relation to WebApp 3 -10 setting location of 3-5 setting name of 3-5 tools 3-2 viewing contents of 3 -10 Web Application wizard 3-3 web applications 1-1, 2-1, 2-7, 3-1, 15-1 See also WebApp in JBuilder overview overview of developing vs distributed applications... 14-1 web run options 14-6 web view options 14-4 Web Start 17-1 and JBuilder 17-3 applet 17-4 application 17-4 application homepage 17-5 application security 17-1 installing 17-3 JAR file 17-4 JNLP file 17-5 setting up your project 17-3 tutorial 17-6 wizard 17-5 web technologies table of 2-1 web view 15-7 web view options 14-4 web view source 15-7 web. xml file 3-1, 16-3 adding a filter 16-5 I-6 Web Application. .. 18-9 Tomcat Web Container 18-7 Web Application Archive File (WAR file) 18-8 web component connection modifying 18-11 web resource collection adding to web. xml file 16-5 Web Run command 15-1, 15-6, 15-7 enabling 15-8 web run options 14-6 web server plugin 14-8 GUI editor 14-9 JSP considerations 14-9 registering as OpenTool 14-8 setting up the web server 14-8 starting the web server 14-8 web servers... WAR file name 3-5 WebApp page 3-5 web- borland.xml 18-8 WEB- INF directory 3-3 WebLogic deployment descriptor 16-3 weblogic.xml file 16-3 width attribute, applet tag 4-3 wizards JSP (JavaServer Page) 9-3, 10- 1, 11-6 Servlet 12-1 Web Application 3-3 WML servlets 6-4 X XHTML servlets 6-4 XML servlets 6-4 Z ZIP files applet archive attribute 4-3 Index I-7 I-8 Web Application Developer’s Guide ... conventions 1-4 E EJB References page in WebApp DD Editor 16-14 enabling web commands 15-8 Environment page in WebApp DD Editor 16-13 Error Pages page in WebApp DD Editor 16-12 F Fault Tolerance for Tomcat Web Container 18-22, 18-24 file locations in a WebApp 3-3 file types included in WAR file 3 -10 filter adding to web. xml file 16-5 filter servlet 6-1, 16-7 Filters page in WebApp DD Editor 16-7 fonts JBuilder... information Using the Borland Enterprise Server Web Edition 18-27 18-28 Web Application Developer’s Guide Index A Apache Web Server configuration 18-5 configuration syntax 18-5 connecting to Tomcat Web Container 18-2 httaccess files 18-6 applet deployment 4-8, 4-13 in archives 4-9 applet security restrictions 4-11 sandbox 4 -10 security manager 4-2, 4 -10 signing 4-11 solutions 4-11 applet tag 4-2 attributes... with web archives 3-2 See also WAR file web commands enabling 15-8 Web Debug command 15-1 enabling 15-8 web development basic process 2-6 Web Edition Apache Web Server 18-4 configuration 18-5 directory structure 18-6 modifying 18-12 Index I-5 architectural overview 18-1 authorization three-tier authorization 18-18 Core Services 18-2 Smart Agent 18-2 Web Server 18-4 Java Session Service properties 18 -10. .. documentation conventions 1-3 I-2 Web Application Developer’s Guide G generated URL 15-7 generating tables with InternetBeans Express 11-5 H height attribute, applet tag 4-3 hspace attribute, applet tag 4-3 HTML servlets 5-7, 6-4 HTTP servlets 5-7 HTTP Sessions 18-27 I image tag, InternetBeans Express 11-7 importing files to a WebApp 3-4 web application 3-3 installing Web Start 17-3 internet technologies . 16-1 WebApp 16-1 deployment descriptors 3-1 editing 3-2 for a WebApp 3-3 more information 16-18 node of WebApp 3-4 vendor-specific for a WebApp 16-17 web application 16-3 web. xml file 3-4, 16-4 WebApp. 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 18-20 Web Application Developer’ s Guide Clustering. httpd.conf file: WebAppDeploy < ;web- application- name> <connection-name> /<URI-mapping-component>/ where < web- application- name> is the name of the web application using