WebSphere applications are assigned to virtual hosts during installation and configuration process.
The virtual hosts are bound to one or more aliases (host names and ports), allowing a single application server to respond to multiple inbound request formats.
The virtual host aliases that are configured within WebSphere define the pattern match possibilities for which WebSphere application server will respond with data.
For example, if we have 7 aliases defined for a given virtual host ‘foo-app’ on application server, ‘fooserver?.
Virtual Host: ‘foo-app’
Hostname Port
thisport 8080
thatport 8081
secureport 8443
secureport2 9443
otherport 10001
otherport2 10002
otherport3 10003
Hence, for any inbound request for ‘foo-app’, if the URL does not match against the list above, the request is denied, else the client gets the access. The Application Server is the gatekeeper here.
Usually all default application server ports are removed from the ‘default_host’ virtual host once you do some ‘hardening’, forcing all inbound requests to be channeled through a proxy mechanism.
Hence, you will not be able to access the application ‘foo-app’ directly, if the default listening port is not in the list above. e.g. ‘foo-app’ listens on 1234. To get to ‘foo-app’, you need to get through the aliases above to get to ‘foo-app’.
I use Apache in the web layer above Websphere Application Server. Need to install the Websphere Proxy-Plugin and generate the xml file.
When client access the URL, the GET request reaches Apache, which then checks the request against the Websphere Proxy Plugin for the host or virtual host corresponding to the requested URL.
The Websphere Proxy Plugin has a list of valid WebSphere virtual hosts and virtual-host associated resources. Here, if matched, those requests are forwarded to the appropriate WebSphere application server. If not matched, 404 is generated.
Recent Comments