|
|
|
|
| |
Introduction
Introduction to BEA WebLogic Server introduces you to WebLogic Server, BEA's Web Application Server. This chapter, Introduction, covers the following topics:
Today's business environment demands web and e-commerce applications that will accelerate your entry into new markets, help you find new ways to reach and retain customers, and allow you to introduce new products and services quickly. To build and deploy these new solutions, you need a proven, reliable e-commerce platform. One that can connect and empower all types of users, while integrating all of your corporate data, mainframe applications, and other enterprise applications in a powerful, flexible end-to-end e-commerce solution. One with the performance, scalability, and high availability to handle your most critical enterprise-scale computing.
As the industry leading e-commerce transaction platform, WebLogic Server provides a number of features critical to developing and deploying mission-critical e-commerce applications across distributed, heterogeneous computing environments. These include:
WebLogic Server allows you to quickly develop and deploy reliable, secure, scaleable and manageable applications. WebLogic Server manages system-level details so you can concentrate on business logic and presentation.
WebLogic Server operates at the center of a multitier architecture. In this architecture, business logic is executed in WebLogic Server, rather than in client applications. The resulting "thin" client, three tier architecture allows the client to manage the presentation layer, the application server to manage the business logic and the back end data services manage the data. This makes WebLogic Server the ideal platform for web-enabled e-commerce applications.
In the middle tier, WebLogic Server provides a reliable, highly scalable platform for hosting business logic. It serves static and dynamic web pages, and manages database access, security, and transaction services for applications. WebLogic Server centralizes access to a variety of third-tier resources and back end services. Tier three services include databases, messaging systems, transaction monitors, real-time data feeds, and existing enterprise information systems integrated with WebLogic Server via "connectors." WebLogic Server shields client applications from propriety interfaces and provides efficient sharing of resources.
Managing access to critical back-end resources from the middle tier helps to secure them. In a web-based application, all client interaction is accomplished with HTML web pages. This means that clients outside of a firewall can access a WebLogic Server application without compromising the security of the back-end resources the application uses. Java-based WebLogic Server applications provide similar security for back-end resources through the use of components located in the middle tier.
Instead of focussing on all of the complexities of system infrastructure, WebLogic Server developers focus on modeling business processes and solving application needs.
Multitier Application Architecture
With the traditional two-tier client-server architecture, a server provides a specific service and provides the client with an interface to access that service. The server performs low-level, computation- and resource-intensive tasks on behalf of its clients. The server also provides optimization, resource management, and concurrency control for its multiple clients. This is a considerable improvement over an independent client architecture where each client must implement complex services and somehow share resources cooperatively with other clients.
With the client-server architecture, however, clients use server-specific, client-side APIs to access a server, and each API provides access to a single category of services, such as database or messaging. Client-side APIs are proprietary and vendor-specific. The client code and vendor libraries must be installed and maintained on every computer where the client application is to be used.
In spite of its advantages, the client-server architecture still produces client-side applications that are large, complex, platform- and vendor-specific, and difficult to deploy and maintain.
A multitier architecture based on open standards preserves the advantages of the client-server architecture while simplifying the complexity by adding an additional tier between clients and the services they access. The middle tier can manage client-server resources more efficiently and provide greater scalability, using techniques such as resource-pooling and caching. It presents clients with an abstracted API that integrates back-end resources and shields clients from the back-end vendors' implementation specifics. Client applications are easier to deploy because they are unaffected by changes in the back-end.
An application server can further improve on the client-server architecture by moving much or all of the application logic from the client into the middle tier, so that clients concentrate exclusively on presentation logic.
With a WebLogic Server application deployed to the web, for example, all of the application-specific logic can be located in WebLogic Server; clients invoke applications by requesting web pages and providing input through HTML forms. Servlets or JavaServer Pages, running on WebLogic Server, accept input from the browser and provide the content for the browser.
Servlets and JSPs can access a variety of other services in WebLogic Server. They can execute database queries using standard JDBC (Java Database Connectivity) calls or Enterprise JavaBeans. They can invoke Enterprise JavaBeans that encapsulate specific business logic, and they can use JMS (Java Messaging Service) to exchange messages with other clients and applications.
With a Java client application, the application logic can be selectively deployed in the client or in WebLogic Server. Java clients are typically deployed to overcome the limitations of browsers access to resources on the client computer and less dynamic user interfaces.
WebLogic Server Architecture
WebLogic Server is a multithreaded server that listens on the network for a client request. It establishes a connection with a client, including negotiating details such as protocol, encryption, and authentication. Then it processes the client's requests by executing Java classes on behalf of the client.
On the back-end, WebLogic Server can connect to virtually any network-accessible service. For example, nearly all applications require database access. Other common back-end services are directory and naming services, messaging systems, and legacy applications that are integrated with WebLogic Server applications.
WebLogic Server can be a primary web server or it can process requests redirected to it by an existing web server. For example, it is common to have a Netscape Enterprise Server, Microsoft Internet Information Server, or Apache web server handle requests for static HTML web pages, but pass their servlet and JSP page requests to WebLogic Server.
WebLogic Server clients can be web browsers using HTTP (Hypertext Transfer Protocol), or Java clients. In both cases, clients specify a URL (Universal Resource Locator), which provides the network protocol and location of the desired WebLogic Server resource. Secure, encrypted connections can be made using SSL (Secure Sockets Layer).
WebLogic Server provides scalability and reliability with WebLogic clusters. A WebLogic cluster is a group of cooperating WebLogic Servers that provide load-balancing and failover capabilities. Client requests are distributed among the servers participating in the cluster. When a WebLogic Server does not respond to a request, the client tries the next WebLogic Server. WebLogic EJB components and RMI classes support pluggable load-balancing algorithms. A WebLogic Server cluster can also work cooperatively with intelligent networking software, hardware, or proxy servers to provide even more load-balancing options.
WebLogic Server and Sun's Java 2 Platform
WebLogic Server implements Sun Microsystems' Java 2 Platform, Enterprise Edition (J2EE), a standard architecture for distributed, mutitier enterprise applications. WebLogic Server is the most complete J2EE application server available.
Sun's J2EE architecture emphasizes thin clients with application logic implemented in software components hosted in the middle tier. J2EE defines a suite of standard services that support components so that application logic does not have to be concerned with low-level details such as networking, database access, security, and data-sharing. WebLogic Server provides these services in a standard way so that application programmers can concentrate on business logic and presentation.
Component technologies include servlets and JavaServer Pages (JSP) for server-side presentation logic, and Enterprise JavaBeans (EJB) for implementing business objects and processes.
J2EE services that support components include:
To promote fast development and portability, J2EE identifies common services needed by components and implements them in the container that hosts the component. A component has only the code necessary to describe the object or process that it models. It has no code to access its execution environment or services such as transaction management, access control, network communications, or persistence mechanisms. These services are provided by the "container," which is implemented in WebLogic Server.
This component/container abstraction allows developers to work within their fields of expertise. EJB developers create Enterprise beans that model business objects and processes within their own field of knowledge-for example accounting systems, human resources, or order processing. Web engineers design dynamic web pages that access beans by using simple JSP extensions to HTML.
J2EE also removes non-developer roles from component design by defining the roles of application assemblers and deployers. For example, mapping an enterprise bean to a particular database or other persistent store is a deployment responsibility, not a responsibility of the EJB developer. These services are configured at deployment and implemented by the container-WebLogic Server.
WebLogic Server Application Models
This section describes some common WebLogic Server application models. To use the the multitier architecture to its fullest advantage, the models emphasize placing business logic on WebLogic Server and presentation logic on thin clients, and using server-side components to minimize coding and take advantage of WebLogic Server's powerful component management services.
Web Services Application Model
A web-based application takes advantage of WebLogic Server's web server capabilities. Using HTTP, web browsers and other HTTP servers can make requests to WebLogic Server. WebLogic Server can serve static HTML pages, XML documents, Java Applets, and dynamic HTML pages generated by servlets and JSP pages. All application logic is located in WebLogic Server, so clients are very easy to deploy. Figure 1-1 illustrates the architecture.
Figure 1-1 Web services application model
Web applications communicate using HTTP. With HTTP, clients transmit a request to the server and the server returns a response. The protocol defines several types of requests, GET and POST are the most common. A GET request asks the server for a page at a specified URL. A POST request sends the contents of an HTML form to the server for processing. In either type of request, the server returns an HTML page to the browser.
Static HTML Pages and Applets
Static HTML pages are text files that contain text formatted with standard HTML tags. When a client requests a static HTML page with an HTTP GET request, WebLogic Server returns the contents of the file to the client as an HTTP response. This is a standard service available from any web server.
An applet is a Java class that executes in a web browser. To WebLogic Server, an applet is a file that is included in the body of a static HTML page, much like an image. The web browser executes the applet in its own Java interpreter. Applets are often used to visually activate a web page or to enhance the user interface and presentation logic on the client.
Servlets
Servlets are Java programs that reside on WebLogic Server. When a client requests a servlet, WebLogic Server executes the servlet on the client's behalf. The servlet generates a response with an HTML or XML body. To the client, the response from a servlet looks like any static web page. However, the contents of the page returned can be different each time the servlet executes.
A servlet can access data sent with the client's request, such as values entered into HTML form fields. A servlet can also execute other Java classes in WebLogic Server and include the results in its response.
JSP Pages
JSP pages are files that contain text formatted with standard HTML tags, and JSP tags and scriptlets. JSP pages are based on servlet technology. JSP tags provide access to data included in the client's HTTP request and to other WebLogic Server classes, including JavaBeans and Enterprise JavaBeans. JSP scriptlets contain Java code that is included in the generated servlet.
When a client requests a JSP page, the WebLogic JSP compiler translates the embedded JSP tags and scriptlets and generates a servlet. A page is only compiled the first time it is requested and when it has been revised.
JSP pages are more convenient to create than servlets because you can concentrate on page design using familiar HTML tags. This is in keeping with the J2EE model of tailoring work to the developer's domain of expertise; HTML is a more suitable medium for a page designer than is Java. The Java code embedded in a JSP page can be minimized by referencing JavaBean and Enterprise JavaBean components on the page, rather than writing logic into JSP scriptlets.
Web-based Component Application Model
In a web-based component application, a web browser client accesses servlets and JSP pages on WebLogic Server. The servlet or JSP page, in turn, accesses JavaBeans, Enterprise JavaBeans, and other services on WebLogic Server. Since no code is deployed on the client, the client is thin. The client and server exchange requests and responses over HTTP.
Figure 1-2 illustrates the model.
Figure 1-2 Web-based component application model
The web-based component application model extends the web services application model by adding EJB components to the middle tier. In Figure 1-2, a JDBC connection pool is also present in the middle tier to provide pooled access to a database.
This application model maintains the security, manageability, and deployment advantages of a thin client. There are performance advantages to co-locating the server-side presentation logic (servlets and JSP pages) and EJB components on the same server. The network activity is confined to the HTTP connection between the client and WebLogic Server.
Enterprise JavaBeans
EJB (Enterprise JavaBeans) is the standard component architecture for distributed Java applications. The EJB architecture simplifies developing and using components by insulating beans from the system-level services that support them. EJB defines the responsibilities of a container, which is implemented by the WebLogic EJB container. The container takes care of such tasks as creating and destroying bean instances, managing transactions and concurrency, and loading and saving bean data to a persistent store. The runtime characteristics of a bean are configured when the bean is deployed in WebLogic Server, not when it is created by the EJB developer.
The EJB model allows bean developers to concentrate on pure business logic without concern for the underlying system support. This speeds the development process and makes it possible for application developers to use beans in different environments without having to modify the Java code in the bean.
There are two types of enterprise beans: session beans and entity beans. A session bean is associated with one client at any time and contains procedural logic. Session beans provide services such as performing calculations and database queries for a client or managing a set of related entity beans for a client. A session bean can be stateless, which means that it maintains no client-related data, or it can be stateful, which means that it maintains a conversational state with the client.
An entity bean represents a data object, such as a catalog item, customer, or invoice. An entity bean has a primary key, which ensures that a single bean instance represents an individual business object in WebLogic Server. Entity beans are mapped to data in a persistent data store, such as a relational database or object database. Mapping a bean to a data store is a task performed when a bean is deployed. In Figure 1-2, entity beans are persisted in a relational database via a WebLogic Server JDBC connection pool. WebLogic EJB includes built-in support for this type of persistence. To use another store, you can provide your own persistence code, or use tools provided with the data store. For example, TOPLink for BEA WebLogic Server, from The Object Peoplehttp://www.objectpeople.com), provides integrated support for EJB persistence in a high-performance object relational database.
JDBC Connection Pools
Nearly all applications require database access. In Java, database access is accomplished using JDBC (Java Database Connectivity). JDBC provides a standard interface for executing SQL commands and processing results in Java programs. A database vendor-specific JDBC driver loaded at runtime makes it possible to write Java applications that are portable between database vendors. BEA supplies JDBC drivers for Oracle, Microsoft SQL Server, and Informix databases. The Cloudscape JDBC driver and the Sybase jConnect driver are bundled with WebLogic Server. You can also use any other standard JDBC driver with WebLogic Server.
Creating a connection to a database is an expensive process. For short database transactions, more system resources may be consumed connecting to the database than executing the transaction. The multitier architecture offers a solution to this in the form of JDBC connection pools. With a connection pool, a set of database connections are established once when WebLogic Server starts up and then connections can be borrowed from the pool as needed.
In the web-based component model, Enterprise JavaBeans can perform all of the JDBC access for applications. Entity beans that use JDBC persistence use the JDBC pool to save their values. Database queries can be performed using session beans.
A servlet or JSP page can also borrow a connection from the connection pool to perform a database operation without the assistance of EJB. But using EJB allows you to create shareable database access components that are managed by the EJB container and easily referenced in JSP pages.
Java Client Application Model
Standalone Java clients can access WebLogic Server resources, including Enterprise JavaBeans and JDBC connection pools. They can execute Java classes on WebLogic Server using RMI (Remote Method Invocation). Presentation logic must be handled by the Java client, perhaps using JFC (Java Foundation Classes) to build interactive graphical interfaces.
Java clients, by definition, require client-side code. They also require a JRE (Java runtime environment) and WebLogic Server classes installed on the client computer. Because of these deployment requirements, Java clients are more appropriate for enterprise applications than e-commerce applications, which should run solely in the client's web browser.
Java clients are not constrained by the browser security model, which prohibits some applets from accessing resources on the client's computer. For example, a good application for a Java client is transferring data between a mobile database and an enterprise database via a WebLogic Server connection pool.
Figure 1-3 Java client application model
Java clients use JNDI (Java Naming and Directory Interface) to gain access to WebLogic Server. WebLogic Server maintains a JNDI naming tree where all remotely-executable classes, EJBs, and other server-side resources are registered. Using JNDI calls, the client looks up the desired service and receives a "stub" from WebLogic Server. A stub is a light-weight client-side representation of a server-side object. The client makes a request on the stub and the RMI framework transparently transfers the request to the server and returns the results to the client.
Java Development with WebLogic Server
WebLogic Server implements a number of Sun Java specifications, each describing a technology in detail. Many of the Sun specifications include both client-side and server-side APIs. WebLogic Server implements the server-side classes of the specifications and you, the application developer, implement your application using Sun APIs. You only use WebLogic APIs if you want to use one of our proprietary APIs-WebLogic Events, for example-or in a few cases where we have extended a Sun API to support features missing from the specification.
For example, with the Java Servlet API, you can create an HTTP Servlet that interacts with a web browser, producing dynamic web pages. The Java Servlet specification defines a "container," whose responsibilities are to provide network services between the Servlet and the browser and to manage the Servlet through its lifecycle. In other words, a Servlet requires a Servlet engine to run it. WebLogic Server provides the Servlet engine.
Most Sun APIs have similar server-side/client-side implementation requirements. Sometimes, the server-side implementation is called a "container", other times it is called a "service provider."
Some Java APIs, for example JDBC (Java Database Connectivity), require no server-side implementation. A Java application can use JDBC to access a database without an application server in the middle tier. But the JDBC support implemented in WebLogic Server offers clear advantages, such as JDBC connection pools.
Also, because WebLogic Server implements all of the Enterprise Java APIs, applications hosted on WebLogic Server can access multiple services within a single JVM. For example, a servlet can use Enterprise JavaBeans, execute JDBC queries against a database, and send and receive JMS messages within a single WebLogic Server instance. This provides significant scalability and performance advantages. Web-based applications have access to a variety of Java client APIs without ever running Java code on the client.
Even with Java code running on the client, applications can benefit by concentrating their business logic in the middle tier. And since all requests from a Java client to WebLogic Server share a single connection to the server, network resources are used efficiently.
What's Next?
Here are some online resources to help you learn more about the Java language:
The next chapter describes WebLogic Server administration, including security features, administration tools and WebLogic Server clusters.
|
|
|
Copyright © 2000 BEA Systems, Inc. All rights reserved.
|