Using the HTTP Binding Component

Contents

• Using the HTTP Binding Component
• About the HTTP Binding Component
• HTTP/SOAP Binding Architecture
• HTTP Binding Component Features
• HTTP Binding Component Example Scenario
• SOAP Processing
• HTTP Processing
• HTTP GET and POST Processing
• HTTP Binding Component Runtime Properties
• HTTP Binding Component Client Endpoint Properties
• Using Normalized Message Properties to Propagate Binding Context Information
• Configuring Quality of Service (QOS) Features
• Using the Tango Web Service Attributes with the HTTP Binding Component
• Configuring Web Service Attributes
• HTTP Binding Component Security
• Using Application Variables to Define Name/Value Pairs
• Using Application Configuration to Configure Connectivity Parameters
• Logging and Statistics Monitoring
• Using WS-Atomic Transaction
• Clustering Support for the HTTP Binding Component
  • HTTP Load Balancer
  • Configuring the HTTP Binding Component for Clustering
  • Understanding the ${HttpDefaultPort} Token
• Common User Scenarios

Clustering Support for the HTTP Binding Component

---

A cluster is a collection of application server instances that can distribute a workload throughout the clustered application instances for optimal performance. These server instances share the same set of applications, resources, and configuration information. A clustered server instance belongs to exactly one cluster, and inherits everything from that parent cluster. Instances in a cluster can extend over any number of computers.

GlassFish supports clustering of homogenous application server instances that contains the same set of JBI components, applications, and configuration information that are installed on a single host or on multiple hosts. Applications that run on each application server instance are independent, but are also manageable by an administration infrastructure, either through web browser based (DAS) or command line clients.

HTTP Load Balancer

The HTTP Load Balancer is a web server plug-in that accepts HTTP and HTTPS requests and distributes them to application server instances in a cluster. This allows the HTTP Binding Component to be scaled horizontally, running on multiple instances in a Sun Java System Application Server cluster.

The advantages of clustering include:

• Increases overall system throughput by distributing workload among multiple physical machines
• Servers with different hardware capacities can have the work load distributed in favor of more powerful hosts
• In the event that one particular application server instance is overloaded or becomes unavailable, requests can be re-routed to the least loaded application server instances
• Clustering is invisible to the client. As far as the client is concerned, all HTTP requests are directed to the web server instance where the load balancer is configured

The HTTP Load Balancer includes the following features:

• Sticky Round Robin load balancing algorithm
• Support for multiple clusters
• Configurable health failover capability (less than 30 ms)
• Checks and reloads for dynamic changes made to the load balancer configuration
• Support for quiescence, enabling rolling web service upgrades
• Automatic retry of failed requests for idempotent URLs
• Configurable error pages

Configuring the HTTP Binding Component for Clustering

For the most part, configuring the HTTP Binding Component for clustering is handled by Sun Java System Application Server (GlassFish). The HTTP Binding Component is a pre-installed component in the application server. Default HTTP and HTTPS port numbers are calculated and pre-assigned when the binding components are installed in the server instances. A web service, serviced by an HTTP Binding Component, is identified by a unique URL identifier with the structure: "http://hostname:port/context ".

Each component instance in the cluster must have exclusive access to the resource, therefore a unique port number is assigned to each component instance. A predefined token name is used in the WSDL artifact to resolve the actual port value when the component is deployed into each instance.

Predefined HTTP Port Tokens

The predefined token names are:

• "${HttpDefaultPort}" for the HTTP port
  
• "${HttpsDefaultPort}" for the HTTPS port
  

These token names are used in lieu of a real port number in the endpoint URL (soap:address) to enable the application client to direct HTTP requests to the default port. The value of the token is then resolved by the HTTP Binding Component based on the configured default values when an application is deployed.

Understanding the ${HttpDefaultPort} Token

The following section provides a little background on the ${HttpDefaultPort} token and how it's resolved when an application is deployed.

Just like the GlassFish web services, which are always deployed to a designated HTTP port (8080 is the configured default), the HTTP Binding Component also has a default HTTP port to which web services are deployed. Because the HTTP Binding Component comes with GlassFish as a preinstalled component, a default HTTP port is always assigned to it. The default port is configured in the JBI Runtime module during the installation of GlassFish, at which time it allocates an available port for each HTTP Binding Component instance in the GlassFish domains.

Originally, this default port setting and the ${HttpDefaultPort} token were placed in the WSDL URL to support clustering where multiple HTTP BC instances could be running on the same machine. When an application is deployed, the port token is used to resolve the actual port value to the assigned port in each instance, with no chance of port collisions.

Since then, the use of the port has evolved such that the HTTP Binding Component (the web service container in JBI) acts in a fashion that is similar to the GlassFish web service container. When The binding component receives an application, it looks up the default HTTP port setting, and replaces the token in the URL with the actual port number. If the default port number is not configured, an Initialization failed exception is thrown.

Previous
Next

This page (revision-9) was last changed on 08-May-09 15:52 PM, -0700 by rjacobus.
This page was created on 12-Sep-08 13:37 PM, -0700 by rjacobus.

More info...