The following sections provide an overview of WebLogic Server Web applications, servlets, and JavaServer Pages (JSPs):
A Web application contains an application’s resources, such as servlets, JavaServer Pages (JSPs), JSP tag libraries, and any static resources such as HTML pages and image files. A Web application adds service-refs (Web services) and message-destination-refs (JMS destinations/queues) to an application. It can also define links to outside resources such as Enterprise JavaBeans (EJBs).
Web Applications and Java EE
An important aspect of theprogramming model is the introduction of metadata annotations. Annotations simplify the application development process by allowing a developer to specify within the Java class itself how the application component behaves in the container, requests for dependency injection, and so on. Annotations are an alternative to deployment descriptors that were required by older versions of Enterprise applications (J2EE 1.4 and earlier).
With Java EE annotations, the standard
web.xml deployment descriptors are optional. The Java EE programming model uses the feature for Web containers, such as EJBs, servlets, Web applications, and JSPs. See WebLogic Annotation for Web Components.
However, Web applications deployed on WebLogic Server can still use a standard Java EE deployment descriptor file and a WebLogic-specific deployment descriptor file to define their resources and operating attributes.
JSPs and HTTP servlets can access all services and APIs available in WebLogic Server. These services include EJBs, database connections by way of Java Database Connectivity (JDBC), Java Messaging Service (JMS), XML, and more.
A Web archive (WAR file) contains the files that make up a Web application. A WAR file is deployed as a unit on one or more WebLogic Server instances. A WAR file deployed to WebLogic Server always includes the following files:
The WAR file can be deployed alone or packaged in an Enterprise application archive (EAR file) with other application components. If deployed alone, the archive must end with a .war extension. If deployed in an EAR file, the archive must end with an .ear extension.
BEA recommends that you package and deploy your stand-alone Web applications as part of an Enterprise application. This is a BEA best practice, which allows for easier application migration, additions, and changes. Also, packaging your applications as part of an Enterprise application allows you to take advantage of the split development directory structure, which provides a number of benefits over the traditional single directory structure.
|Note:||If you are deploying a directory in exploded format (not archived), do not name the directory .ear, .jar, and so on. For more information on archived format, see Web Application Developer Tools.|
A servlet is a Java class that runs in a Java-enabled server. An HTTP servlet is a special type of servlet that handles an HTTP request and provides an HTTP response, usually in the form of an HTML page. The most common use of WebLogic HTTP Servlets is to create interactive applications using standard Web browsers for the client-side presentation while WebLogic Server handles the business logic as a server-side process. WebLogic HTTP servlets can access databases, Enterprise JavaBeans, messaging APIs, HTTP sessions, and other facilities of WebLogic Server.
WebLogic Server fully supports HTTP servlets as defined in thefrom Sun Microsystems. HTTP servlets form an integral part of the Java EE standard.
With Java EE metadata annotations, the standard
web.xml deployment descriptor is now optional. The , states annotations can be defined on certain web components, such as servlets, filters, listeners, and tag handlers. The annotations are used to declare dependencies on external resources. The container will detect annotations on such components and inject necessary dependencies before the component’s life-cycle methods are invoked. See WebLogic Annotation for Web Components.
Thedefines the implementation of the servlet API and the method by which servlets are deployed in enterprise applications. Deploying servlets on a Java EE-compliant server, such as WebLogic Server, is accomplished by packaging the servlets and other resources that make up an enterprise application into a single unit, the Web application. A Web application utilizes a specific directory structure to contain its resources and a deployment descriptor that defines how these resources interact and how the application is accessed by a client. See The Web Applications Container.
The following are a few key points relating to servlet development:
javax.servlet.http, to create interactive applications.
JavaServer Pages (JSPs) are a Sun Microsystems specification for combining Java with HTML to provide dynamic content for Web pages. When you create dynamic content, JSPs are more convenient to write than HTTP servlets because they allow you to embed Java code directly into your HTML pages, in contrast with HTTP servlets, in which you embed HTML inside Java code. Theis part of the Java Enterprise Edition (Java EE).
JSPs are Web pages coded with an extended HTML that makes it possible to embed Java code in a Web page. JSPs can call custom Java classes, called
taglibs, using HTML-like tags. The WebLogic appc compiler weblogic.appc generates JSPs and validates descriptors. You can also precompile JSPs into the WEB-INF/classes/ directory or as a JAR file under WEB-INF/lib/ and package the servlet class in the Web archive to avoid compiling in the server. Servlets and JSPs may require additional helper classes to be deployed with the Web application.
JSPs enable you to separate the dynamic content of a Web page from its presentation. It caters to two different types of developers: HTML developers, who are responsible for the graphical design of the page, and Java developers, who handle the development of software to create the dynamic content.
BEA WebLogic JSP supports thefrom Sun Microsystems. The main theme for Java EE is ease of development. The platform’s web tier contributes significantly to ease of development in two ways. First, the platform now includes the JavaServer Pages Standard Tag Library (JSTL) and JavaServer Faces technology. Second, all the web-tier technologies offer a set of features that make development of web applications on Java EE much easier, such as:
Because JSPs are part of the Java EE standard, you can deploy JSPs on a variety of platforms, including WebLogic Server. In addition, third-party vendors and application developers can provide JavaBean components and define custom JSP tags that can be referenced from a JSP page to provide dynamic content.
taglibs, using HTML-like tags.
WebLogic Server handles JSP requests in the following sequence:
.jspfile extension from WebLogic Server.
javax.servlet.jsp.JspPageinterface. The JSP file is compiled only when the page is first requested, or when the JSP file has been changed. Otherwise, the previously compiled JSP servlet class is re-used, making subsequent responses much quicker.
JspPageservlet class is invoked to handle the browser request.
It is also possible to invoke the JSP compiler directly without making a request from a browser. For details, see.
Because the JSP compiler creates a Java servlet as its first step, you can look at the Java files it produces, or even register the generated
JspPage servlet class as an HTTP servlet. See Servlets.
BEA provides several tools to help you create and configure Web applications. These are discussed in the following sections.
You can use the WebLogic Ant utilities to create skeleton deployment descriptors. These utilities are Java classes shipped with your WebLogic Server distribution. The Ant task looks at a directory containing a Web application and creates deployment descriptors based on the files it finds in the Web application. Because the Ant utility does not have information about all desired configurations and mappings for your Web application, the skeleton deployment descriptors the utility creates are incomplete. After the utility creates the skeleton deployment descriptors, you can use a text editor, an XML editor, or the Administration Console to edit the deployment descriptors and complete the configuration of your Web application.
You can use an enterprise-level IDE with DTD validation or another development tool that supports editing of XML files.
You can secure a Web application by restricting access to certain URL patterns in the Web application or programmatically using security calls in your servlet code.
At runtime, your username and password are authenticated using the applicable
security realm for the Web application. Authorization is verified according to the security constraints configured in web.xml or the external policies that might have been created using Administration Console for the Web application.
At runtime, the WebLogic Server active security realm applies the Web application security constraints to the specified Web application resources. Note that a security realm is shared across multiple virtual hosts.
For detailed instructions and an example on configuring security in Web applications, see Securing WebLogic Resources. For more information on WebLogic security, refer to Programming WebLogic Security.
The Platform for Privacy Preferences (P3P) provides a way for Web sites to publish their privacy policies in a machine-readable syntax. The WebLogic Server Web application container can support P3P.
There are three ways to tell the browser about the location of the p3p.xml file:
For more detailed information, see
To display special characters on Linux browsers, set the JVM’s
file.encoding system property to
ISO8859_1. For example,
java -Dfile.encoding=ISO8859_1 weblogic.Server. For a complete listing, see Sun’s page for Java EE 5.0.