Skip Navigation Links | |
Exit Print View | |
Oracle Java CAPS HTTP Binding Component User's Guide Java CAPS Documentation |
Using the HTTP Binding Component
About the HTTP Binding Component
HTTP/SOAP Binding Architecture
HTTP Binding Component Features
HTTP Binding Component Example Scenario
SOAP 1.1 WSDL Extensibility Elements
SOAP 1.1 header and headerfault Elements
SOAP 1.2 WSDL Extensibility Elements
SOAP 1.2 header and headerfault Elements
HTTP WSDL Extensibility Elements
Configuring the HTTP Binding Component for HTTP Get Interactions
Using the HTTP Binding Component with the HTTP POST Method
Configuring the HTTP Binding Component for HTTP Get Interactions
HTTP POST Treatment of http:urlEncoded and http:urlReplacement
HTTP Binding Component Runtime Properties
HTTP Binding Component Client Endpoint Properties
Accessing the HTTP Binding Component Client Endpoint Properties
HTTP BC Client Endpoint Configuration Properties
Using Normalized Message Properties to Propagate Binding Context Information
Using Normalized Message Properties in a BPEL Process
Using Predefined Normalized Message Properties in a BPEL Process
To use predefined normalized message properties in a BPEL process
Adding Additional Normalized Message Properties to a BPEL Process
To add a Normalized Message Property Shortcut to a BPEL process
To edit an NM Property Shortcut
To delete an NM Property Shortcut
To add a Normalized Message Property to a BPEL process
BPEL Code Generation Using NM Properties
SOAP HTTP Binding Component Specific Normalized Message Properties
Quality of Service (QOS) Features
Configuring the Quality of Service Properties
Message Throttling: Configuring and Using
Configuring the HTTP Binding Component Endpoint for Throttling
Redelivery: Configuring and Using
Using the Tango Web Service Features with the HTTP Binding Component
Configuring Reliable Message Delivery
Installing the Synchronous BPEL Process sample
Configuring Web Services for a Project from the CASA Editor
Configuring the Tango Web Services Attributes exposed by the HTTP Binding Component
Accessing the Tango (WSIT) Web Service Attribute Configuration
Accessing the WS-Policy Attachment Editor for a Specific Endpoint
Server Configuration--Web Service Attributes
Client Configuration -- Web Service Attributes
HTTP Binding Component Security
Using Basic Authentication with the HTTP Binding Component
Basic Authentication Supported Features
Authentication Mechanisms for Consumer Endpoints
WssTokenCompare Username/Password Authentication
Using the Access Manager for Authentication and Authorization
Installing the Access Manager Add-on
Installing Access Manager with Java Application Platform SDK
Configure the HTTP Binding Component to use Access Manager
Using the OpenSSO Web Services Security (WSS) Agent for Authentication and Authorization
Install OpenSSO Enterprise Server
Configure the HTTP Binding Component to use OpenSSO Web Service Security
Using the GlassFish Realm Security to Authenticate the HTTP Client Credentials
Configuring Security Mechanisms
Username Authentication with Symmetric Key
Message Authentication over SSL
SAML Sender Vouches with Certificates
STS Issued Token with Service Certificate
Using Application Variables to Define Name/Value Pairs
Using Application Variables for password protection
Creating a password Application Variable
Using Application Configuration to Configure Connectivity Parameters
To apply a named Config Extension to the Application Configuration
Clustering Support for the HTTP Binding Component
Validating HTTP Extensibility Elements from the WSDL Editor
Adding a SOAP Template to a WSDL Document
Adding an HTTP Template to a WSDL Document
Web Service Client Calling an Operation Using HTTP Basic Authentication
Web Service Implementing an Operation Protected by HTTP Basic Authentication
Web Service Client Calling an Operation Using SSL Authentication
Web Service Implements an Operation Protected by SSL Authentication
A cluster is a logical entity encompassing zero or more server instances. Simply speaking, 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.
The GlassFish Application Server supports clustering of homogenous application server instances (containing the same set of JBI components, applications, and configuration information) 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.
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 GlassFish Application Server cluster.
The advantages of clustering are many:
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 30ms)
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 impotent URLs
Configurable error pages
For the most part, configuring the HTTP Binding Component for clustering is handled by GlassFish Application Server. The HTTP Binding Component is a pre-installed component in the application server. Default HTTP and HTTPS port numbers are calculated and preassigned 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
Predefined token names:
"${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 allow 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.
Note - If you reinstall an HTTP Binding Component, you must reconfigure the default ports properly for each component instance.
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. Since the HTTP Binding Component comes with GlassFish as a pre-installed 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 domain(s).
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. As such, 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 an application “arrives“ in the binding component, it looks up its default HTTP port setting, and replace the token in the URL with the actual port number. If the default port number is not configured, an Initialization failed exception is thrown.