An IBM® WebSphere® Proxy Server can be an HTTP proxy
or a SIP proxy server, or both. The DCS_UNICAST_ADDRESS is also known
as the High Availability Manager Communication Port, and is the primary
channel to route user connections to back end servers.
WebSphere proxy servers
When you install a WebSphere Proxy
Server, you configure it to be an XMPP Proxy Server, HTTP Proxy Server,
or a SIP Proxy Server. When using a WebSphere proxy server to tunnel through
a firewall, servers and nodeagents use the DCS_UNICAST_ADDRESS to
determine where to route traffic to servers. DCS is how the servers
know what servers are available to route traffic to. The actual traffic
will follow along the appropriate ports, webcontainers for HTTP/S
and SIP for SIP/S. Use virtual hosts to tie an application's context
root to a host and port.
- When DCS reports a server is up, the WebSphere Proxy Server adds it to the pool
- When DCS reports a server is down, the WebSphere Proxy Server removes it from
the pool
- If there are no available servers to route the URI, 503 is returned
to the client
The following graphic shows how a client must access the HTTP Proxy
Server in front of the IBM
Sametime® Meeting Servers.
While you may only be using a WAS HTTP Proxy for a given service,
the proxy is still aware of the entire cell. Therefore, using distinct
virtual hosts are key to insure that routing is correctly done.
A WebSphere SIP Proxy
is tied to a specific cluster for SIP routing. When using a WebSphere Proxy Server, the
end user connects to the following ports:
- PROXY_HTTP_ADDRESS
- PROXY_HTTPS_ADDRESS
- PROXY_SIP_ADDRESS
- PROXY_SIPS_ADDRESS
When the end user connects to a port, WebSphere Proxy then routes the request
to the appropriate back end servers, WebContainers, or SIP ports A WebSphere Proxy Server can
be on the same node as other application servers
Using virtual hosts to route precisely
A virtual host lets a single host computer resemble multiple host
computers when you create multiple host names for the same IP address.
In WebSphere Application
Server, a virtual host ties an application's context root or URI to
host:port combinations. By default,
Sametime uses the
default_host.
The default host uses
* for the hostname(s)
(match any). But when you create distinct virtual hosts, you can be
very specific. For example:
- meetings.company.com is in the "stmeeting_host"
- stproxy.company.com is in the "stproxy_host"
- Both applications are assigned to the virtual host.
Note: Be sure to validate virtual host mappings after applying
any Sametime updates.
If the WebSphere HTTP
Proxy Server address has two DNS aliases, for example: "meetings.company.com"
and"'stproxy.company.com", when the WebSphere HTTP Proxy gets a request for
http://meetings.company.com/ it
knows to correctly route it to one of the nodes that has the
Sametime Meeting application
and not to any other node that also has a 'root (/)' context. If there
was only the
default_host and *, it would not
know how to distinguish the request.
Even though you may have a WebSphere HTTP
Proxy Server on a node that only listens for "Sametime Meeting" addresses,
the WAS HTTP Proxy is a cell level item and it still knows about and
can route to the other nodes in the cell if there is another context
root that matches.
The following graphic shows a WebSphere SIP
Proxy Server in front of a
SametimeSIP Proxy/Registrar
cluster. TCP 5060 is the port for communication between the client
the WebSphere SIP Proxy
Server, and between the WebSphere SIP
Proxy Server and
Sametime SIP
Proxy/Registrar nodes.
