You are on page 1of 42

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 client’s
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 organization’s production data in structured
form.

when SSI (Server-Side Include) is used. MS SQL Server 3. Dynamic HTML pages include script instructions directly in the HTML code. e.Example: 1.. can use services (e. e. . Open source MySQL 2. or it can access a database via the application logic on the Web server (e. A client request can point directly to static HTML pages. 2-Layer Architectures = Client / Server Architechture It uses a Web server to provide services to a client.g.. user identification or data encryption) when the HTML response is generated. e. Application server: An application server holds the functionality required by several applications. Oracle database server Media server: This component is primarily used for content streaming of non-structured bulk data like audio and video. workflow or customization. Content management server: Similar to a database server. and they are interpreted either by databases with HTML functionality or by a Web server.. a content management server holds contents to serve an application. XML documents. without requiring any processing logic on the server layer. Legacy application: A legacy application is an older system that should be integrated as an internal or external component. The application logic.. in the form of CGI scripts).g..g.g.g. or dynamic HTML pages. These contents are normally available in the form of semistructured data.

This architecture is suitable particularly for simple Web applications. 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. In contrast.

.

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

.

The code required to control distributed transactions can be quite complex. Because the container manages the transaction.enforces security by requiring users to log in  HTTP . Since you don't have to develop these services yourself. you do not have to code transaction boundaries in the enterprise bean. Each client belongs to a particular role. You declare the roles and the methods they may invoke in the enterprise bean's deployment descriptor.allows clients to invoke methods on enterprise beans EJB Container Enterprise bean instances run within anEJB container. 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.enables Web browsers to access servlets and JavaServer PagesTM (JSP) files  EJB . and each role is permitted to invoke certain methods.FIGURE 1-2 J2EE Architecture J2EE Server The J2EE server provides the following services:  Naming and Directory . . you are free to concentrate on the business methods in the enterprise beans. you simply declare the enterprise bean's transactional properties in the deployment descriptor file. the container intervenes in order to manage the transaction. you don't need to code routines that enforce security.allows programs to locate services and components through the Java Naming and Directory InterfaceTM (JNDI) API  Authentication . Because of this declarative approach. Security The container permits only authorized clients to invoke an enterprise bean's methods. The container is a runtime environment that controls the enterprise beans and provides them with important system-level services. The container reads the file and handles the enterprise bean's transactions for you. Instead of writing and debugging complex code.

The container creates the enterprise bean. After an enterprise bean has been created.Remote Client Connectivity The container manages the low-level communications between clients and enterprise beans. a session bean is transient. A session bean converses with the client. the container performs these tasks behind the scenes. Database Connection Pooling A database connection is a costly resource. it may be re-used by another bean. There are two types of enterprise beans: session beans and entity beans. the container manages a pool of database connections. Each session bean can have only one client. Therefore. Session Beans A session bean represents a client in the J2EE server. a checkbook client might invoke the debit and credit methods of an account enterprise bean. its corresponding session bean also terminates. moves it between a pool of available instances and the active state. For more information on developing Web components. A client communicates with the J2EE server by invoking the methods that belong to an enterprise bean. and can be thought of as an extension of the client. Enterprise beans contain the business logic for your application. For example. An enterprise bean can quickly obtain a connection from the pool. For example. To alleviate these problems. When the client terminates. removes it. Although the client calls methods to create and remove an an enterprise bean. Although these Web components are an important part of a J2EE application. a client invokes methods on it as if it were in the same virtual machine. see the home pages for the JavaServer PagesTM and Java Servlet technologies. . Obtaining a database connection is time-consuming and the number of connnections may be limited. Enterprise Beans Enterprise beans are server components written in the Java programming language. this manual focuses on enterprise beans. Web Container The Web container is a runtime environment for JSP files and and servlets. Life Cycle Management An enterprise bean passes through several states during its lifetime. and finally. an online shopping client might invoke the enterOrder method of its session bean to create an order. or non-persistent. After the bean releases the connection.

product. May be shared by multiple clients. Even when the EJB container Not persistent. It could be stored in an object database. Represents a business entity object that exists in persistent storage. See the section "Database Access" for more information. For example. The persistence of an entity bean can be managed by either the entity bean itself.Entity Beans An entity bean represents a business object in a persistent storage mechanism such as a database. The servlet is the client of a shopping session bean. The following illustration shows how you might create an online shopping application with both session and entity beans. Container-managed persistence means that the EJB container handles the data access calls automatically. For example. database. The session bean is the client of the order. An HTML form displayed in a Web browser accesses a servlet in a Web container. the entity state remains in a its session bean is no longer available. The flexibility of the EJB architecture allows you to build applications in a variety of ways. The reference implementation (J2EE SDK) uses a relational database. . or some other storage mechanism. and customer entity beans. Comparing Session and Entity Beans Although both session and entity beans run in an EJB container. When the client terminates Persistence terminates. 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. which might be stored as a row in the customer table of a relational database. a legacy application. a file. it instructs the servlet to call the appropriate business methods in the session bean. their state is stored in the database. or by the EJB container. An entity bean's information does not have to be stored in a relational database. they are quite different. an entity bean could represent a customer. Because entity beans are persistent. a customer entity bean would include the SQL commands to access a relational database via JDBC. Bean-managed persistence requires you to write the data access code in the Bean. Shared Access May have one client. The type of storage mechanism depends on the particular implementation of EJB technology. When the HTML form needs to find a product or enter an order. Persistent.

enterprise beans are restricted from performing certain operations:  Managing or synchronizing threads . JavaBeans components define a convention for making a Java class instance customizable by design tools. they are not interchangeable. Although both components are written in the Java programming language. allowing the tools to link these customized objects via events.FIGURE 1-3 Using Session and Entity Beans Java BeansTM Components and Enterprise Beans JavaBeans components and enterprise beans are not the same. such as life-cycle management. Programming Restrictions for Enterprise Beans Enterprise beans make use of the services provided by the EJB container. transactional services. To avoid conflicts with these services. Enterprise beans implement multi-user.

Therefore. The type of enterprise bean you choose depends on your application. . accepting connections on a socket.  The data does not represent a business entity.  You want to hide the relational model from the session bean.io package  Using AWT functionality to display information or to accept information from a keyboard  Listening on a socket. 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. Accessing files or directories with the java. or using a socket for multicast  Setting a socket factory used by ServerSocket. 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. You might want to include SQL calls in a session bean under the following circumstances:  The application is relatively simple. 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.  The data returned by the SQL call will not be used by multiple clients. Socket.  The data represents a business entity.

This requires a JDBC driver that can communicate with the particular data source being accessed. and the results of those statements are sent back to the user.JDBC Architecture The JDBC API supports both two-tier and three-tier processing models for database access. with the user's machine as the client. Another advantage is that it simplifies the deployment of applications. commands are sent to a "middle tier" of services. This is referred to as a client/server configuration. 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. the three-tier architecture can provide performance advantages. A user's commands are delivered to the database or other data source. for example. in many cases. Figure 2: Three-tier Architecture for Data Access. The network can be an intranet. The data source processes the commands and sends the results back to the middle tier. and the machine housing the data source as the server. In the three-tier model. The data source may be located on another machine to which the user is connected via a network. which then sends the commands to the data source. which then sends them to the user. connects employees within a corporation. which. a Java application talks directly to the data source. . Finally. In the two-tier model. or it can be the Internet. Figure 1: Two-tier Architecture for Data Access.

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

.

.

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. which are described in JMS Administered Objects. An implementation of the Java EE platform includes a JMS provider. written in the Java programming language. Figure 31-2 illustrates the way these parts interact.JMS API Architecture A JMS application is composed of the following parts. Any Java EE application component can act as a JMS client. that produce and consume messages. Figure 31-2 JMS API Architecture . The two kinds of JMS administered objects are destinations and connection factories. Administered objects are preconfigured JMS objects created by an administrator for the use of clients. JMS clients are the programs or components. Messages are the objects that communicate information between JMS clients. Administrative tools allow you to bind destinations and connection factories into a JNDI namespace.     A JMS provider is a messaging system that implements the JMS interfaces and provides administrative and control features.

.

.

.

.

.

s .

What is a Distributed Destination? A distributed destination is a set of destinations (queues or topics) that are accessible as a single. your producers and consumers are able to send and receive messages through the distributed destination. with each destination member belonging to a separate JMS server. traffic is then redirected toward other available destination members in the set. logical destination to a client. For more information on how destination members are load balanced. When one member becomes unavailable due a server failure. Once properly configured. . A distributed destination has the following characteristics:   It is referenced by its own JNDI name. WebLogic JMS then balances the messaging load across all available members of the distributed destination. 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. see "Configuring Distributed Destinations". Members of the set are usually distributed across multiple servers within a cluster.

particularly in regards to weighting. paging. the corresponding UDD member is removed from the UDD. 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). persistence. a new UDD member is dynamically added to the UDD. but instead rely on WebLogic Server to uniformly create the necessary members on the JMS servers to which a UDD is targeted. security. paging. if a JMS server is removed. Likewise. For more information. there is a UDD member on every JMS server in the cluster. and quotas. . Weighted Distributed Destinations In a weighted distributed destination. For more information. This feature of UDDs provides dynamic updating of a UDD when a new member is added or a member is removed. This allows UDDs to provide higher availability by eliminating bottlenecks caused by configuration errors. particularly in regards to weighting. if UDD is targeted to a cluster.Creating a Distributed Destination Distributed destinations are created by the system administrator using the Administration Console. BEA recommends using UDDs because you no longer need to create or designate destination members. each of the member destinations has a consistent configuration of all distributed destination parameters. see "Configuring Distributed Destinations". security. If a new JMS server is added. the member destinations do not have a consistent configuration of all distributed destination parameters. and quotas. persistence. For example.

means that database server guarantee to follow the ACID (Automicity. JDBC Transaction example "A transaction is a logical group of work that contains one or more SQL statements. despite any failures that occur afterwards . A transaction is an atomic unit. not yet committed or rolled back. see "Configuring Distributed Destinations".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). 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. For more information. smaller tasks need to be successfully completed. If any one task fails then all the previous tasks are reverted back to the original state. must be isolated from other transactions Durability : o Once a transaction commits successfully. 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. 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. 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. Consistency. Either all. Isolation and Durability) properties. For a major task to be completed. the state changes committed by that transaction must be durable < persistent. ACID Properties     Atomicity : o Implies indivisibility o Any indivisible operation (one which will either complete in totally.

After withdrawing amount from account.JDBC Transaction Management : The Connection interface is used to manage transactions in Java applications.I am using Account table.Java to Network Protocol Driver (Middleware) Type4 . commit() and rollback() used to implement transaction in JDBC. If it is less than 1000 the transaction must be rollback. By default true is set in setAutoCommit() method.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 . The amount must be available at least Rs. when any SQL statement submit to the database server. So it cannot be used in internet due the client side software needed . JDBC Driver Types There are four distinct types of JDBC drivers:     Type1 . There is three methods setAutoCommit().00. 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.jdbc.Native API Java Driver (Native) Type3 . 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..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 Bridge Driver (Bridge) Type2 . Example .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. database server commit it.1000. it will check the amount in account. ORACLE etc.odbc package JDBC statements call the ODBC by using the JDBC .

Pure Java Driver       Pure Java drivers that implement a proprietary database protocol to communicate directly with the database Like Type 3 drivers. But typically this is overcome by providing efficient middleware services Type4 . This is possible through different MIME(Multipurpose Internet Mail Extensions) type code.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. The following is the list of MIME type used by the web servers : Enterprise Java Bean (EJB) 3 . An extra layer added may result in a time-bottleneck.Type 3 . 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.

a shopping cart. JBoss Application Server. It is best example of onoe to one communication between clients and components. Java Persistence API (JPA) An Entity is a light-weight entity object that manages persistent data. The bean needs to hold information about the client across method invocations. It creates seperate object for each client.EJB Introduction An Enterprise JavaBean (EJB) is a server side managed J2EE (Java Enterprise Edition) component architecture for distributed. IBM. . Apache TomEE. Glassfish Application Server. The following are the popular application servers are available Oracle WebLogic Server. The bean's state represents the interaction between the bean and a specific client. potentially uses several dependent Java objects.1 entity bean class. EJB is based on RMI (Remote Method Invocation). Apache Geronimo Applications Server.0 entity bean class is a non-abstract POJO class with implementations for the accessor/mutator methods in comparison to the EJB 2. the any application server is required. Credit card validation and do not maintain a conversational state for a particular client.g. performs complex business logic. which is abstract with abstract accessor/mutator methods. Stateful Session Bean Maintains client specific state e. To deploy the EJB application. Stateless Session Bean Execute a request and return a result without saving any client specific state information in server side e. modular construction of enterprise application.Web Sphere Application Server.g. 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.

see Overview of JMS Servers. and connection factories. The EntityManager class is used to create. such as standalone queue and topic destinations. 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. WebLogic JMS Architecture and Environment The following figure illustrates the WebLogic JMS architecture. and are defined by XML documents that .EJB 3. 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. For more information. and to maintain the states of durable subscribers created on the destinations. and a JMS server can manage one or more JMS modules. JMS modules contain configuration resources. You can configure one or more JMS servers per domain. distributed destinations. find. and update an entity in EJB.0 does not require component and home interfaces.

If an application wants to have a separate thread for producing and consuming messages. a user-defined file store. JNDI (Java Naming and Directory Interface). Common Domain Types There are two basic types of domains: . the application should create a separate session for each function. most applications establish a single connection for all messaging. A connection may also provide user authentication. A connection creates server-side and client-side objects that manage the messaging activity between an application and JMS. Connection Object A Connection object represents an open communication channel between an application and the messaging system. No additional TCP/IP connections are created for JMS. Due to the resource overhead associated with authenticating users and setting up communications. which provides a server lookup facility. WebLogic persistent storage (a server instance's default store. A Connection is created by a ConnectionFactory Object. In the WebLogic Server.   conform to the weblogic-jmsmd. see What Are JMS Configuration Resources?. Client JMS applications that either produce messages to destinations or consume messages from destinations.xsd schema. 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 is used to create a Session Object for producing and consuming messages. or a user-defined JDBC-accessible store) for storing persistent message data. For more information. and can create multiple message producers and message consumers. obtained through a JNDI lookup. The same thread can be used for producing and consuming messages. JMS traffic is multiplexed with other WebLogic services on the client connection to the server.

see Managed Servers and Clustered Managed Servers. deploy applications only on Managed Servers in the domain. 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 Administration Server should be reserved for management tasks. In this case. For more information about the difference between a standalone and clustered Managed Servers. throughput. see Creating and Configuring Domains Using the Configuration Wizard. applications and resources are deployed to individual Managed Servers. Clustering allows multiple Managed Servers to operate as a single unit to host applications and resources. Production environments that require increased application performance. you may want to deploy a single application and server independently from servers in a production domain. The examples domain that you can install with WebLogic Server is an example of a standalone server domain. and an Administration Server to perform management operations. Note: In production environments. For more information. similarly.  Standalone Server Domain: For development or test environments. . Domain with Managed Servers: A simple production environment can consist of a domain with several Managed Servers that host applications. clients that access the application connect to an individual Managed Server. or availability may configure two or more of Managed Servers as a cluster. In this configuration.

.

s .

s .

s s .

Enterprise JavaBean (EJB). the server presents a certificate to the client and the client presents a certificate to the server. JAAS implements a Java version of the Pluggable Authentication Module (PAM) framework. One-way SSL is common on the Internet where customers want to create secure connections before they share personal data. Java Authentication and Authorization Service (JAAS) Whether the client is an application. applet. WebLogic Server can be configured to require clients to submit valid and trusted certificates before completing the SSL connection. Often. the PAM framework allows . but the client is not required to present a certificate to the server. or servlet that requires authentication. Therefore. WebLogic Server uses the Java Authentication and Authorization Service (JAAS) classes to reliably and securely authenticate to the client. With two-way SSL (SSL with client authentication). which permits applications to remain independent from underlying authentication technologies.One-Way and Two-Way SSL SSL can be configured one-way or two-way:   With one-way SSL. The client must authenticate the server. clients will also use SSL to log on in order that the server can authenticate them. the server must present a certificate to the client. but the server accepts a connection from any client.

Therefore. WebLogic Server uses JAAS for remote fat-client authentication.This LoginModule must succeed. only developers of custom Authentication providers and developers of remote fat client applications need to be involved with JAAS directly. If other Authentication providers are configured and this LoginModule succeeds. LoginModules that are not used for perimeter authentication also verify the proof material submitted (for example. those calling an Enterprise JavaBean (EJB) from a servlet) do not require the direct use or knowledge of JAAS. each of the Authentication providers' LoginModules will store principals within the same subject. Otherwise. if a principal that represents a WebLogic Server user (that is. return control to the application. Even if it fails.The user is allowed to pass or fail the authentication test of this Authentication providers. return control to the application. a user's password). If it does succeed. if all Authentication providers configured in a security realm have the JAAS Control Flag set to OPTIONAL. OPTIONAL . However. SUFFICIENT . However. The values for the Control Flag attribute are as follows:     REQUIRED . . If there are multiple Authentication providers configured in a security realm. This setting is the default. Users of thin clients or developers of within-container fat client applications (for example. the other Authentication providers' LoginModules should not attempt to add another principal to the subject that represents a WebLogic Server user (for example.This LoginModule needs not succeed. Therefore. the Control Flag attribute on the Authenticator provider determines the ordered execution of the Authentication providers. authentication proceeds down the list of LoginModules for the configured Authentication providers. and internally for authentication. REQUISITE . authentication proceeds down the list of LoginModules. 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). an implementation of the WLSUser interface) named "Joe" is added to the subject by one Authentication provider's LoginModule. authentication proceeds down the LoginModule list.the use of new or updated authentication technologies without requiring modifications to your application.This LoginModule must succeed. In other words. the user must pass the authentication test of one of the configured providers. named "Joseph") to refer to the same person. JAAS Control Flags If a security realm has multiple Authentication providers configured. it is acceptable for another Authentication provider's LoginModule to add a principal of a type other than WLSUser with the name "Joseph". If it fails and other Authentication providers are configured. any other Authentication provider in the security realm should be referring to the same person when they encounter "Joe".

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 host name verification feature is updated so that if the host name in the certificate matches the local machine's host name..3. 10 May 2011 <IP> was not trusted causing SSL handshake failure : Weblogic 10 . either turn off host name verification or configure a custom host name verifier. the SSL connection is dropped. the SSL connection is dropped.ssl. Specifying the Version of the SSL Protocol .SSLKeyException: [Security:090477]Certificate chain . BEA recommends leaving host name verification on in production environments. 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. host name verification passes if the URL specifies localhost. 127.5 SSL Handshake As a function of the SSL handshake. WebLogic Server has host name verification enabled.net. If anything other than the default behavior is desired. 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. 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.5 error during SSL handshake 16 Jan 2013 javax. The SSL client is the actual party that drops the SSL connection if the names do not match. If these names do not match. SSL handshake failure with Weblogic Server 11g 4 Jun 2013 weblogic server 10. The SSL client is the actual party that drops the SSL connection if the names do not match.WebLogic 10. In this release of WebLogic Server. It helps to prevent man-in-the-middle attacks. or the default IP address of the local machine. As a function of the SSL handshake.3.. Turning off host name verification leaves WebLogic Server vulnerable to man-in-the-middle attacks.0. By default.01.

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