Web addresses, or Universal Resource Locators (URLs), have an important role when HTTP or SSL
(HTTPS) protocols are used.
The HTTP proxy servlet passes the requests from the servlet container to the broker and vice
versa.
Each HTTP or SOAP input node expects to receive requests from a specific web address (or web
addresses when wildcard characters are used). The servlet container also uses the web
address to locate the servlets that are going to process the HTTP or HTTPS requests that
the servlet container receives on behalf of the broker.
The web address is structured in the following way:
schema://host_name:port/url_path
where:
- schema
- Specifies the protocol (HTTP or HTTPS).
- host_name
- Specifies the host name or IP address of the server where the servlet container is
running.
- port
- Specifies the port number on which the servlet container is listening.
- url_path
- Specifies the URL path; a series of tokens (separated by slashes /) that
identify both the HTTP proxy servlet, and the HTTP or SOAP input nodes.
When you use the HTTP proxy servlet, the URL path is partitioned as follows:
context_root/node_url_path
where:
- context_root
- Specifies the part of the URL path (context root) that is allocated to the
proxy servlet by the servlet container when the proxy servlet is
deployed.
- node_url_path
- Specifies the part of the URL path that makes the web address unique to a
specific HTTP or SOAP input node.
Note: You can set context_root to / in
which case url_path and node_url_path are the
same.
The entire URL path must be configured in the properties of the HTTPInput or SOAPInput node. For more information, see HTTPInput node and SOAPInput node.
For example, you might have
HTTPInput nodes that are
configured to receive requests for the following web addresses:
- Node1: http://myhost.com/app1
- Node2: http://myhost.com/public/app2
- Node3: http://myhost.com/public/app3
- Node4: http://myhost.com/private/app4
If you set the context root for your HTTP proxy servlet to
/public, then you can communicate with Node2 and Node3 via the HTTP
proxy servlet.
If you set the context root for your HTTP proxy servlet to /private, then you
can communicate with Node4 via the HTTP proxy servlet.
If you set the context root for your HTTP proxy servlet to /, then you can
communicate with all of the HTTPInput nodes via
the HTTP proxy servlet.
- Choosing a context root for the HTTP proxy servlet
-
- If you have many existing applications that you want to access with the HTTP proxy
servlet, and the input nodes or integration services do not use URLs
with a common root, you might want to set the context root for the HTTP
proxy servlet to /. Then you do not need to modify
the URLs used by your input nodes or integration services. However, if you
set the context root for the HTTP proxy servlet to
/, then the HTTP proxy servlet becomes the
default application for the servlet container, and the HTTP proxy
servlet attempts to process all requests that do not match the context
root of any other applications that are hosted by the servlet
container.
- If you want to access a subset of your existing applications with the HTTP proxy servlet,
you might configure the URLs for the input nodes or integration services to start with a
consistent value, for example /public. Then you must
set the context root of the HTTP proxy servlet to the same value.
- If you are building applications from scratch, then consider the requirements of the HTTP
proxy servlet when you plan the structure of the URLs you configure for
your input nodes or integration services.
Before you install and test the HTTP proxy servlet, ensure that you understand the
following concepts:
When you have gained an understanding of the HTTP proxy servlet concepts, read the
following topics to help you configure, install, and test the HTTP proxy servlet:
Last updated Friday, 21 July 2017