Web Application Architechture Client /

Server Architecture
Posted by: Bharat on: July 24, 2010

In: Theory
Leave a Comment

What is Architecture?
Architecture is the structure of software systems which is divided into different perspectives,
allowing us to manage the complexity of software systems in a better and easier way.
Frameworks
A framework is a reusable software system with general functionality already implemented. It
can be specialized into a ready-to-use application.
1. Examples Zend Framework for PHP
2. NET Framework for ASP etc
Benefits:

The simple reuse of architecture and functionality

Drawbacks: A high degree of training effort, a lack of standards for the integration of different
frameworks, and the resulting dependence on manufacturers.
Components of a Generic Web Application Architecture

Web browser sends a request to Web server and the response to this request is sent back.
Client = User agent. It is controlled by a user to operate the Web application. The clients
functionality can be expanded by installing plug-ins, add-ons and applets.
Firewall: A software or hardware regulating the communication between insecure networks
(e.g., the Internet) and secure networks (e.g., corporate LANs). This communication is filtered by
access rules.
Proxy: A proxy is typically used to temporarily store Web pages in a cache. However, proxies
can also assume other functionalities, e.g., adapting the contents for users (customization), or
user tracking.
Web server: A Web server is a software that supports various Web protocols like HTTP, and
HTTPS, etc., to process client requests.
Example:
1. Open source Apache Web Server
2. IIS Web Server
3. Tomcat Server
Database server: This server normally supplies an organizations production data in structured
form.

Example:
1. Open source MySQL
2. MS SQL Server
3. Oracle database server
Media server: This component is primarily used for content streaming of non-structured bulk
data like audio and video.
Content management server: Similar to a database server, a content management server holds
contents to serve an application. These contents are normally available in the form of semistructured data, e.g., XML documents.
Application server: An application server holds the functionality required by several
applications, e.g., workflow or customization.
Legacy application: A legacy application is an older system that should be integrated as an
internal or external component.
2-Layer Architectures = Client / Server Architechture

It uses a Web server to provide services to a client.

A client request can point directly to static HTML pages, without requiring any processing logic
on the server layer, or it can access a database via the application logic on the Web server (e.g.,
in the form of CGI scripts).
Dynamic HTML pages include script instructions directly in the HTML code, e.g., when SSI
(Server-Side Include) is used, and they are interpreted either by databases with HTML
functionality or by a Web server. The application logic, or dynamic HTML pages, can use
services (e.g., user identification or data encryption) when the HTML response is generated.

This architecture is suitable particularly for simple Web applications. In contrast, a multilayer
architectural approach is required for more demanding applications which are accessed by a
large number of concurrent clients or which provide complex business processes requiring the
access to legacy systems, amongst others.

J2EE Architecture
The JavaTM 2 SDK, Enterprise Edition (J2EE SDK) is the reference implementation provided by Sun
Microsystems, Inc. The following figure shows the major elements of the architecture for the J2EE SDK:

FIGURE 1-2 J2EE Architecture

J2EE Server
The J2EE server provides the following services:

Naming and Directory - allows programs to locate services and components through the Java
Naming and Directory InterfaceTM (JNDI) API

Authentication - enforces security by requiring users to log in

HTTP - enables Web browsers to access servlets and JavaServer PagesTM (JSP) files

EJB - allows clients to invoke methods on enterprise beans

EJB Container
Enterprise bean instances run within anEJB container. The container is a runtime environment that
controls the enterprise beans and provides them with important system-level services. Since you don't
have to develop these services yourself, you are free to concentrate on the business methods in the
enterprise beans. The container provides the following services to enterprise beans:

Transaction Management

Security

Remote Client Connectivity

Life Cycle Management

Database Connection Pooling

Transaction Management
When a client invokes a method in an enterprise bean, the container intervenes in order to manage the
transaction. Because the container manages the transaction, you do not have to code transaction
boundaries in the enterprise bean. The code required to control distributed transactions can be quite
complex. Instead of writing and debugging complex code, you simply declare the enterprise bean's
transactional properties in the deployment descriptor file. The container reads the file and handles the
enterprise bean's transactions for you.
Security
The container permits only authorized clients to invoke an enterprise bean's methods. Each client
belongs to a particular role, and each role is permitted to invoke certain methods. You declare the roles
and the methods they may invoke in the enterprise bean's deployment descriptor. Because of this
declarative approach, you don't need to code routines that enforce security.

Remote Client Connectivity

The container manages the low-level communications between clients and enterprise beans. After an
enterprise bean has been created, a client invokes methods on it as if it were in the same virtual
machine.
Life Cycle Management
An enterprise bean passes through several states during its lifetime. The container creates the
enterprise bean, moves it between a pool of available instances and the active state, and finally,
removes it. Although the client calls methods to create and remove an an enterprise bean, the container
performs these tasks behind the scenes.
Database Connection Pooling
A database connection is a costly resource. Obtaining a database connection is time-consuming and the
number of connnections may be limited. To alleviate these problems, the container manages a pool of
database connections. An enterprise bean can quickly obtain a connection from the pool. After the bean
releases the connection, it may be re-used by another bean.

Web Container
The Web container is a runtime environment for JSP files and and servlets. Although these Web
components are an important part of a J2EE application, this manual focuses on enterprise beans. For
more information on developing Web components, see the home pages for the JavaServer PagesTM and
Java Servlet technologies.

Enterprise Beans
Enterprise beans are server components written in the Java programming language. Enterprise beans
contain the business logic for your application. For example, a checkbook client might invoke the debit
and credit methods of an account enterprise bean.

There are two types of enterprise beans: session beans and entity beans.

Session Beans
A session bean represents a client in the J2EE server. A client communicates with the J2EE server by
invoking the methods that belong to an enterprise bean. For example, an online shopping client might
invoke the enterOrder method of its session bean to create an order. A session bean converses with
the client, and can be thought of as an extension of the client. Each session bean can have only one
client. When the client terminates, its corresponding session bean also terminates. Therefore, a session
bean is transient, or non-persistent.

Entity Beans
An entity bean represents a business object in a persistent storage mechanism such as a database. For
example, an entity bean could represent a customer, which might be stored as a row in the customer
table of a relational database. An entity bean's information does not have to be stored in a relational
database. It could be stored in an object database, a legacy application, a file, or some other storage
mechanism. The type of storage mechanism depends on the particular implementation of EJB
technology. The reference implementation (J2EE SDK) uses a relational database. See the section
"Database Access" for more information.

The persistence of an entity bean can be managed by either the entity bean itself, or by the EJB
container. Bean-managed persistence requires you to write the data access code in the Bean. For
example, a customer entity bean would include the SQL commands to access a relational
database via JDBC. Container-managed persistence means that the EJB container handles the
data access calls automatically.

Comparing Session and Entity Beans

Although both session and entity beans run in an EJB container, they are quite different. The following
table contrasts session and entity beans:
TABLE 1-1 Differences Between Session and Entity Beans
Session Bean

Entity Bean

Purpose

Performs a task for a client.

Represents a business entity object that exists

in persistent storage.

Shared
Access

May have one client.

May be shared by multiple clients.

Persistent. Even when the EJB container

Not persistent. When the client terminates
Persistence
terminates, the entity state remains in a
its session bean is no longer available.
database.

The flexibility of the EJB architecture allows you to build applications in a variety of ways. The
following illustration shows how you might create an online shopping application with both
session and entity beans. An HTML form displayed in a Web browser accesses a servlet in a
Web container. The servlet is the client of a shopping session bean. When the HTML form needs
to find a product or enter an order, it instructs the servlet to call the appropriate business methods
in the session bean. The session bean is the client of the order, product, and customer entity
beans. Because entity beans are persistent, their state is stored in the database.

FIGURE 1-3 Using Session and Entity Beans

Java BeansTM Components and Enterprise Beans

JavaBeans components and enterprise beans are not the same. Although both components are written
in the Java programming language, they are not interchangeable. JavaBeans components define a
convention for making a Java class instance customizable by design tools, allowing the tools to link these
customized objects via events. Enterprise beans implement multi-user, transactional services.

Programming Restrictions for Enterprise Beans

Enterprise beans make use of the services provided by the EJB container, such as life-cycle management.
To avoid conflicts with these services, enterprise beans are restricted from performing certain
operations:

Managing or synchronizing threads

Accessing files or directories with the java.io package

Using AWT functionality to display information or to accept information from a keyboard

Listening on a socket, accepting connections on a socket, or using a socket for multicast

Setting a socket factory used by ServerSocket, Socket, or the stream handler factory used by
the URL class

Loading a native library

Database Access
The Enterprise JavaBeans specification does not require an implementation to support a particular type
of database. Therefore, the databases supported by different J2EE implementations may vary. See the
Release Notes for a list of the databases currently supported by the J2EE SDK.

Both session and entity beans can access a database. The type of enterprise bean you choose
depends on your application. You might want to include SQL calls in a session bean under the
following circumstances:

The application is relatively simple.

The data returned by the SQL call will not be used by multiple clients.

The data does not represent a business entity.

You should probably access a database from an entity bean if any of the following conditions are true:

More than one client will use the data returned by the database call.

The data represents a business entity.

You want to hide the relational model from the session bean.

JDBC Architecture
The JDBC API supports both two-tier and three-tier processing models for database access.
Figure 1: Two-tier Architecture for Data Access.

In the two-tier model, a Java application talks directly to the data source. This requires a JDBC
driver that can communicate with the particular data source being accessed. A user's commands
are delivered to the database or other data source, and the results of those statements are sent
back to the user. The data source may be located on another machine to which the user is
connected via a network. This is referred to as a client/server configuration, with the user's
machine as the client, and the machine housing the data source as the server. The network can be
an intranet, which, for example, connects employees within a corporation, or it can be the
Internet.
In the three-tier model, commands are sent to a "middle tier" of services, which then sends the
commands to the data source. The data source processes the commands and sends the results
back to the middle tier, which then sends them to the user. MIS directors find the three-tier
model very attractive because the middle tier makes it possible to maintain control over access
and the kinds of updates that can be made to corporate data. Another advantage is that it
simplifies the deployment of applications. Finally, in many cases, the three-tier architecture can
provide performance advantages.
Figure 2: Three-tier Architecture for Data Access.

Until recently, the middle tier has often been written in languages such as C or C++, which offer
fast performance. However, with the introduction of optimizing compilers that translate Java
bytecode into efficient machine-specific code and technologies such as Enterprise JavaBeans,
the Java platform is fast becoming the standard platform for middle-tier development. This is a
big plus, making it possible to take advantage of Java's robustness, multithreading, and security
features.
With enterprises increasingly using the Java programming language for writing server code, the
JDBC API is being used more and more in the middle tier of a three-tier architecture. Some of
the features that make JDBC a server technology are its support for connection pooling,
distributed transactions, and disconnected rowsets. The JDBC API is also what allows access to a
data source from a Java middle tier.

JMS API Architecture

A JMS application is composed of the following parts.

A JMS provider is a messaging system that implements the JMS interfaces and provides
administrative and control features. An implementation of the Java EE platform includes
a JMS provider.
JMS clients are the programs or components, written in the Java programming language,
that produce and consume messages. Any Java EE application component can act as a
JMS client.
Messages are the objects that communicate information between JMS clients.
Administered objects are preconfigured JMS objects created by an administrator for the
use of clients. The two kinds of JMS administered objects are destinations and connection
factories, which are described in JMS Administered Objects.

Figure 31-2 illustrates the way these parts interact. Administrative tools allow you to bind
destinations and connection factories into a JNDI namespace. A JMS client can then use resource
injection to access the administered objects in the namespace and then establish a logical
connection to the same objects through the JMS provider.
Figure 31-2 JMS API Architecture

What is a Distributed Destination?

A distributed destination is a set of destinations (queues or topics) that are accessible as a single,
logical destination to a client. A distributed destination has the following characteristics:

It is referenced by its own JNDI name.

Members of the set are usually distributed across multiple servers within a cluster, with each
destination member belonging to a separate JMS server.

Why Use a Distributed Destination

Applications that use distributed destinations are more highly available than applications that use
simple destinations because WebLogic JMS provides load balancing and failover for member
destinations of a distributed destination within a cluster. Once properly configured, your
producers and consumers are able to send and receive messages through the distributed
destination. WebLogic JMS then balances the messaging load across all available members of
the distributed destination. When one member becomes unavailable due a server failure, traffic is
then redirected toward other available destination members in the set. For more information on
how destination members are load balanced, see "Configuring Distributed Destinations".

Creating a Distributed Destination

Distributed destinations are created by the system administrator using the Administration
Console. For more information, see "Configuring Distributed Destinations".

Types of Distributed Destinations

WebLogic Server supports two types of distributed destinations:

Uniform Distributed Destinations

Weighted Distributed Destinations

Uniform Distributed Destinations

In a uniform distributed destination (UDD), each of the member destinations has a consistent
configuration of all distributed destination parameters, particularly in regards to weighting,
security, persistence, paging, and quotas.
BEA recommends using UDDs because you no longer need to create or designate destination
members, but instead rely on WebLogic Server to uniformly create the necessary members on
the JMS servers to which a UDD is targeted. This feature of UDDs provides dynamic updating
of a UDD when a new member is added or a member is removed.
For example, if UDD is targeted to a cluster, there is a UDD member on every JMS server in the
cluster. If a new JMS server is added, a new UDD member is dynamically added to the UDD.
Likewise, if a JMS server is removed, the corresponding UDD member is removed from the
UDD. This allows UDDs to provide higher availability by eliminating bottlenecks caused by
configuration errors. For more information, see "Configuring Distributed Destinations".

Weighted Distributed Destinations

In a weighted distributed destination, the member destinations do not have a consistent
configuration of all distributed destination parameters, particularly in regards to weighting,
security, persistence, paging, and quotas.

BEA recommends converting weighted distributed destinations to UDDs because of the

administrative inflexibility when creating members that are intended to carry extra message load
or have extra capacity (more weight). Lack of a consistent member configuration can lead to
unforeseen administrative and application problems because the weighted distributed destination
can not be deployed consistently across a cluster.
For more information, see "Configuring Distributed Destinations".

JDBC Transaction example

"A transaction is a logical group of work that contains one or more SQL statements. Either all, or none of the
statements need to be performed in order to preserve data integrity"
A complete task which is a combination of the multiple smaller tasks.
For a major task to be completed, smaller tasks need to be successfully completed.
If any one task fails then all the previous tasks are reverted back to the original state, means that database server
guarantee to follow the ACID (Automicity, Consistency, Isolation and Durability) properties. A transaction is an
atomic unit.
ACID Properties

Atomicity :
o Implies indivisibility
o Any indivisible operation (one which will either complete in totally, or not at all) is said to be
atomic
Consistency :
o A transaction must transition persistent data from one consistent state to another
o In the event of a failure occurs during processing, data must be restored to the state it was in
prior to the transaction
Isolation :
o Transactions should not affect each other
o A transaction in progress, not yet committed or rolled back, must be isolated from other
transactions
Durability :
o Once a transaction commits successfully, the state changes committed by that transaction must
be durable < persistent, despite any failures that occur afterwards

JDBC Transaction Management :

The Connection interface is used to manage transactions in Java applications. There is three methods
setAutoCommit(), commit() and rollback() used to implement transaction in JDBC. By default true is set in
setAutoCommit() method, when any SQL statement submit to the database server, database server commit it. We
can set false in setAutoCommit() method to commit or rollback transaction either commit or rollback explicitly
respectively by calling commit(0 and rollback() method.

Example - I am using Account table. The amount must be available at least Rs.- 1000.00.
After withdrawing amount from account, it will check the amount in account, If it is less
than 1000 the transaction must be rollback.

JDBC Driver Types

There are four distinct types of JDBC drivers:

Type1 - JDBC-ODBC Bridge Driver (Bridge)

Type2 - Native API Java Driver (Native)
Type3 - Java to Network Protocol Driver (Middleware)
Type4 - Pure Java Driver (Pure)

Type1 - JDBC-ODBC Bridge Driver

Type 1 driver act as a "bridge" between JDBC & database connectivity mechanism like
ODBC
The bridge provides JDBC access using most standard ODBC drivers
This driver is included in the Java 2 SDK within the sun.jdbc.odbc package
JDBC statements call the ODBC by using the JDBC - ODBC Bridge and finally the
query is executed by the database
Only limitation is performance overhead since the calls have to go through the JDBC
overhead bridge to the ODBC driver
It works only with Micrsosoft Operating System

Type 2 - Native API Java Driver

Use the Java Native Interface (JNI) to make calls to a local database library API
Converts JDBC calls into a database specific call for databases such as SQL, ORACLE
etc.
Communicates directly with the database server & requires some native code to connect
to the database
The vendor client library needs to be installed on the client machine. So it cannot be used
in internet due the client side software needed

Type 3 - Java to Network Protocol Driver

Pure Java drivers that use a proprietary network protocol to communicate with JDBC
middleware on the server
The middleware then translates the network protocol to database-specific function calls
Do not require native database libraries on the client and can connect to many different
databases on the back end
Can be deployed over the Internet without client installation
Requires database-specific coding to be done in the middle tier. An extra layer added
may result in a time-bottleneck. But typically this is overcome by providing efficient
middleware services

Type4 - Pure Java Driver

Pure Java drivers that implement a proprietary database protocol to communicate directly
with the database
Like Type 3 drivers, they do not require native database libraries and can be deployed
over the Internet without client installation
One drawback is that they are database specific
Communicate directly with the database engine rather than through middleware or a
native library
Usually the fastest JDBC drivers available
Directly converts java statements to SQL statements

List of MIME Types

Web server can send response to the client in many format. This is possible through
different MIME(Multipurpose Internet Mail Extensions) type code. The following is the list
of MIME type used by the web servers :

Enterprise Java Bean (EJB) 3

EJB Introduction

An Enterprise JavaBean (EJB) is a server side managed J2EE (Java Enterprise Edition)
component architecture for distributed, modular construction of enterprise application. EJB is
based on RMI (Remote Method Invocation). To deploy the EJB application, the any application
server is required. The following are the popular application servers are available Oracle WebLogic Server,
JBoss Application Server,
IBM- Web Sphere Application Server,
Glassfish Application Server,
Apache Geronimo Applications Server,
Apache TomEE.
Stateless Session Bean

Execute a request and return a result without saving any client specific state information in
server side e.g. Credit card validation and do not maintain a conversational state for a particular
client. It is best example of onoe to one communication between clients and components.

Stateful Session Bean

Maintains client specific state e.g. a shopping cart.

The bean's state represents the interaction between the bean and a specific client.
The bean needs to hold information about the client across method invocations.
It creates seperate object for each client.

Java Persistence API (JPA)

An Entity is a light-weight entity object that manages persistent data, performs complex business
logic, potentially uses several dependent Java objects, and can be uniquely identified by a
primary key These represent persistent data stored in a relational database automatically using
container managed transaction

Entites in EJB3

The EJB 3.0 entity bean class is a non-abstract POJO class with implementations for the
accessor/mutator methods in comparison to the EJB 2.1 entity bean class, which is abstract with
abstract accessor/mutator methods.

EJB 3.0 does not require component and home interfaces.

The EntityManager class is used to create, find, and update an entity in EJB.
WebLogic JMS Architecture and Environment

The following figure illustrates the WebLogic JMS architecture.

Figure 2-1 WebLogic JMS Architecture

The major components of the WebLogic JMS architecture include:

A JMS server is an environment-related configuration entity that acts as management container

for JMS queue and topic resources defined within JMS modules that are targeted to specific that
JMS server. A JMS server's primary responsibility for its targeted destinations is to maintain
information on what persistent store is used for any persistent messages that arrive on the
destinations, and to maintain the states of durable subscribers created on the destinations. You
can configure one or more JMS servers per domain, and a JMS server can manage one or more
JMS modules. For more information, see Overview of JMS Servers.
JMS modules contain configuration resources, such as standalone queue and topic destinations,
distributed destinations, and connection factories, and are defined by XML documents that

conform to the weblogic-jmsmd.xsd schema. For more information, see What Are JMS
Configuration Resources?.
Client JMS applications that either produce messages to destinations or consume messages
from destinations.
JNDI (Java Naming and Directory Interface), which provides a server lookup facility.
WebLogic persistent storage (a server instance's default store, a user-defined file store, or a
user-defined JDBC-accessible store) for storing persistent message data.

Connection Object
A Connection object represents an open communication channel between an application and the
messaging system, and is used to create a Session Object for producing and consuming
messages. A connection creates server-side and client-side objects that manage the messaging
activity between an application and JMS. A connection may also provide user authentication.
A Connection is created by a ConnectionFactory Object, obtained through a JNDI lookup.
Due to the resource overhead associated with authenticating users and setting up
communications, most applications establish a single connection for all messaging. In the
WebLogic Server, JMS traffic is multiplexed with other WebLogic services on the client
connection to the server. No additional TCP/IP connections are created for JMS. Servlets and
other server-side objects may also obtain JMS Connections

Session Object
A Session object defines a serial order for the messages produced and consumed, and can create
multiple message producers and message consumers. The same thread can be used for producing
and consuming messages. If an application wants to have a separate thread for producing and
consuming messages, the application should create a separate session for each function.

Common Domain Types

There are two basic types of domains:

Domain with Managed Servers: A simple production environment can consist of a

domain with several Managed Servers that host applications, and an Administration
Server to perform management operations. In this configuration, applications and
resources are deployed to individual Managed Servers; similarly, clients that access the
application connect to an individual Managed Server.
Production environments that require increased application performance, throughput, or
availability may configure two or more of Managed Servers as a cluster. Clustering
allows multiple Managed Servers to operate as a single unit to host applications and
resources. For more information about the difference between a standalone and clustered
Managed Servers, see Managed Servers and Clustered Managed Servers.

Standalone Server Domain: For development or test environments, you may want to
deploy a single application and server independently from servers in a production
domain. In this case, you can deploy a simple domain consisting of a single server
instance that acts as an Administration Server and also hosts the applications you are
developing. The examples domain that you can install with WebLogic Server is an
example of a standalone server domain.

Note: In production environments, deploy applications only on Managed Servers in the domain.
The Administration Server should be reserved for management tasks. For more information, see
Creating and Configuring Domains Using the Configuration Wizard.

One-Way and Two-Way SSL

SSL can be configured one-way or two-way:

With one-way SSL, the server must present a certificate to the client, but the client is not
required to present a certificate to the server. The client must authenticate the server, but
the server accepts a connection from any client. One-way SSL is common on the Internet
where customers want to create secure connections before they share personal data.
Often, clients will also use SSL to log on in order that the server can authenticate them.
With two-way SSL (SSL with client authentication), the server presents a certificate to
the client and the client presents a certificate to the server. WebLogic Server can be
configured to require clients to submit valid and trusted certificates before completing the
SSL connection.

Java Authentication and Authorization Service (JAAS)

Whether the client is an application, applet, Enterprise JavaBean (EJB), or servlet that requires
authentication, WebLogic Server uses the Java Authentication and Authorization Service (JAAS)
classes to reliably and securely authenticate to the client. JAAS implements a Java version of the
Pluggable Authentication Module (PAM) framework, which permits applications to remain
independent from underlying authentication technologies. Therefore, the PAM framework allows

the use of new or updated authentication technologies without requiring modifications to your
application.
WebLogic Server uses JAAS for remote fat-client authentication, and internally for
authentication. Therefore, only developers of custom Authentication providers and developers of
remote fat client applications need to be involved with JAAS directly. Users of thin clients or
developers of within-container fat client applications (for example, those calling an Enterprise
JavaBean (EJB) from a servlet) do not require the direct use or knowledge of JAAS.
JAAS LoginModules

A LoginModule is the work-horse of authentication: all LoginModules are responsible for

authenticating users within the security realm and for populating a subject with the necessary
principals (users/groups). LoginModules that are not used for perimeter authentication also
verify the proof material submitted (for example, a user's password).
If there are multiple Authentication providers configured in a security realm, each of the
Authentication providers' LoginModules will store principals within the same subject. Therefore,
if a principal that represents a WebLogic Server user (that is, an implementation of the WLSUser
interface) named "Joe" is added to the subject by one Authentication provider's LoginModule,
any other Authentication provider in the security realm should be referring to the same person
when they encounter "Joe". In other words, the other Authentication providers' LoginModules
should not attempt to add another principal to the subject that represents a WebLogic Server user
(for example, named "Joseph") to refer to the same person. However, it is acceptable for another
Authentication provider's LoginModule to add a principal of a type other than WLSUser with the
name "Joseph".
JAAS Control Flags

If a security realm has multiple Authentication providers configured, the Control Flag attribute
on the Authenticator provider determines the ordered execution of the Authentication providers.
The values for the Control Flag attribute are as follows:

REQUIRED - This LoginModule must succeed. Even if it fails, authentication proceeds

down the list of LoginModules for the configured Authentication providers. This setting
is the default.
REQUISITE - This LoginModule must succeed. If other Authentication providers are
configured and this LoginModule succeeds, authentication proceeds down the list of
LoginModules. Otherwise, return control to the application.
SUFFICIENT - This LoginModule needs not succeed. If it does succeed, return control to
the application. If it fails and other Authentication providers are configured,
authentication proceeds down the LoginModule list.
OPTIONAL - The user is allowed to pass or fail the authentication test of this
Authentication providers. However, if all Authentication providers configured in a
security realm have the JAAS Control Flag set to OPTIONAL, the user must pass the
authentication test of one of the configured providers.

WebLogic 10.3.5 SSL Handshake

As a function of the SSL handshake, WebLogic Server compares the common name in the SubjectDN in
the SSL servers digital certificate with the host name of the SSL server used to initiate the SSL
connection. If these names do not match, the SSL connection is dropped. The SSL client is the actual
party that drops the SSL connection if the names do not match.
SSL handshake failure with Weblogic Server 11g
4 Jun 2013
weblogic server 10.3.5 error during SSL handshake
16 Jan 2013
javax.net.ssl.SSLKeyException: [Security:090477]Certificate chain ...
10 May 2011
<IP> was not trusted causing SSL handshake failure : Weblogic 10 .

Using Host Name Verification

A host name verifier ensures the host name in the URL to which the client connects matches the
host name in the digital certificate that the server sends back as part of the SSL connection. A
host name verifier is useful when an SSL client (or a WebLogic Server acting as an SSL client)
connects to an application server on a remote host. It helps to prevent man-in-the-middle attacks.
By default, WebLogic Server has host name verification enabled. As a function of the SSL
handshake, WebLogic Server compares the common name in the SubjectDN in the SSL server's
digital certificate with the host name of the SSL server used to initiate the SSL connection. If
these names do not match, the SSL connection is dropped. The SSL client is the actual party that
drops the SSL connection if the names do not match.
If anything other than the default behavior is desired, either turn off host name verification or
configure a custom host name verifier. Turning off host name verification leaves WebLogic
Server vulnerable to man-in-the-middle attacks. BEA recommends leaving host name
verification on in production environments.
In this release of WebLogic Server, the host name verification feature is updated so that if the
host name in the certificate matches the local machine's host name, host name verification passes
if the URL specifies localhost, 127.0.01, or the default IP address of the local machine.

Specifying the Version of the SSL Protocol

WebLogic Server supports both the SSL V3.0 and TLS V1.0 protocols. When WebLogic Server
is acting as an SSL server, it will agree to use whichever of these protocols the client specifies as
preferred in its client hello message. When WebLogic Server is acting as an SSL client, it will
specify TLS1.0 as the preferred protocol in its SSL V2.0 client hello message, but will agree to
SSL V3.0 as well, if that is the highest version that the SSL server on the other end supports. The
peer must respond with an SSL V3.0 or TLS V1.0 message or the SSL connection is dropped.
While in most cases the SSL V3.0 protocol is acceptable there are circumstances (compatibility,
SSL performance, and environments with maximum security requirements) where the TLS V1.0
protocol is desired. The weblogic.security.SSL.protocolVersion command-line argument
lets you specify which protocol is used for SSL connections.
Note: The SSL V3.0 and TLS V1.0 protocols can not be interchanged. Only use the TLS V1.0
protocol if you are certain all desired SSL clients are capable of using the protocol.
The following command-line argument can be specified so that WebLogic Server supports only
SSL V3.0 or TLS V1.0 connections:

-Dweblogic.security.SSL.protocolVersion=SSL3Only SSL V3.0

messages are

sent and accepted.

-Dweblogic.security.SSL.protocolVersion=TLS1Only TLS

V1.0 messages are

sent and accepted.

-Dweblogic.security.SSL.protocolVersion=ALLThis

is the default behavior.