We help IT Professionals succeed at work.

Help me understand websphere

brittonv
brittonv asked
on
Medium Priority
1,044 Views
Last Modified: 2013-12-14
The developers are telling me something that goes against my admittedly limited understanding of Websphere.  I am very new to WAS so please bear with me.

It was my understanding that I could have 2 forward facing web servers and connect as many application servers that I wish behind it (with in reason), and that those applications could have their own URL's and be different applications in general.

So for example I have 2 web servers
'behind that' I have 4 pairs of application servers.  Each pair running a unique application that has it's own fqdn
demo1.domain.com
demo2.domain.com...etc

Additionally I can configure the forward web server to allow each application to have it's own IP address (For SSL)

Please correct me if I am wrong.

Additionally does anyone have a good systems administration information source that isn't 4,000 pages.  I don't want to know everything about websphere, I just want to know how to set it up and maintain it.

THanks
Comment
Watch Question

HonorGodSoftware Engineer
CERTIFIED EXPERT

Commented:
Let's start from the top.

> I am very new to WAS so please bear with me.

  Not a problem.  I am very old to WebSphere... I've been working with it for ... 10 years.

> It was my understanding that I could have 2 forward facing web servers and connect as many application servers that I wish behind it (with in reason), and that those applications could have their own URL's and be different applications in general.

  "Within reason" is an appropriate clarification. The way that web servers "know about" WebSphere is by having a web server load module to check requests against WebSphere resources, and if a match exists, a connection is established to the appropriate Application Server and the request is forwarded to the Application Server to be processed.  The web server load module (called the plugin), then waits for the response from the AppServer, and when it is received, it returns it to the client that initially sent the request to the web server.

  So, in order for you to have "multiple web servers" that know about the entire list of resources, each would need to have a copy of the merged list of AppServer resources.  The file that contains this list of resources is nameded plugin-cfg.xml, and is generated whenever a resource configuration change occurs on the AppServer.

  Here's the tricky part.  When you have a single stand-alone AppServer, this is a simple configuration file.  If you have a Deployment Manager (DM) environment (which requires a different license), the Deployment Manager (sometimes called the Network Deployment (ND) node), is responsible for managing and administering multiple AppServers in the cell.  You can even have clusters, which are "virtually" identical AppServers.  The only real difference between two cluster members is that each AppServer has its own hostname, and possibly Java Virtual Machine configuration information. This allows you to have one cluster member on a "bigger and faster" machine, and another cluster member on a smaller and slower machine.  But, this is not recommended.

  If your AppServers are not cluster members, then each machine can still be part of the DM cell by a process called federation.  When a stand-alone AppServer is federated, a separate entity for controlling the AppServer is created.  This entity is called a node agent.  The DM manages, and manipulates federated AppServers, and cluster members through node agents.  So, applications may only be deployed on AppServers, not node agents, or the Deployment Manager itself.

  What does federating buy you?  It allows all federated AppServers to be managed from one place, the DM server.  When an application needs to be deployed, the deployment process updates the complete resource list (i.e., plugin-cfg.xml file), as part of the deployment process.

  Since the DM server "knows" about all of the resources, and manages the plugin-cfg.xml file, you, the administrator, don't have to deal with the details of what resource exists on which AppServer.

  Are there any limitations to having federated AppServers (i.e., not cluster members)? Well, one is that you can't have the same Application (with the same URI) deployed on multiple federated AppServers.  This would be ambiguous.  When a request for /whatever came to the DM, to which AppServer should the request be routed?  In a cluster, the request could be sent to any, and subsequent requests to the same resource, from the same client, would use something called session level affinity, to route the follow on requests to the same cluster member... unless, of course, the cluster member somehow became unavailable.  In which case, if it is configured properly, the DM could cause the request to be sent to another cluster member, and the whole session would be moved from the server that is no longer available, to one that is...  This one of the big benefits of a DM environemnt.

  If you don't have a DM, but just stand-alone AppServers, then each has its own plugin-cfg.xml file, and if you want one, or more web servers to know about all of the resources of all of the AppServers, you have to figure out a way to merge the plugin-cfg.xml information from all of the AppServers into one file, which needs to be put on, or made available to, each web server.

>> Can I configure the forward web server to allow each application to have it's own IP address (For SSL)

  Yes, this can be done.  First, you need to have your DNS set up so that all of the requests get sent to the web server, and the plugin-cfg.xml has to be configured to recognize the hostname for each AppServer, and know how to route the request.

> Additionally does anyone have a good systems administration information source that isn't 4,000 pages.

  With which version of WebSphere are you working/using?  There are some books about the overall product, but as you might imagine, the topic is very large, and complex.

  The starting place for the online documentation is:

http://www.IBM.com/software/webservers/appserv/was/library/

Author

Commented:
Wow, that is an outstanding answer thank you.

I am a little confused on the URI Comment.

If I had a product called 'webservice'.  When I sell this every client would get there own instance of "webservice" on our 'application server farm' (or what ever you'd call it)

People access it at
www.domain.com/webservice
www.nextdomain.com/webservice
secure.applesauce.com/webservice

Are you saying this wouldn't be possible?  
We'd instead have to name the application something different for every customer?
Software Engineer
CERTIFIED EXPERT
Commented:
The URI is the Uniform Resource Identifier portion of the URL, i.e., the stuff after the hostname (and optional portnumber).

So for a URL of:

http://www.domain.com/webservice

"http" is the protocol,
"www.domain.com" is the hostname of the server to which the request is to be sent
and since no port number is specified, the default port for the "http" protocol will be used (i.e., port 80).

 
Q: Are you saying that I can't have:

www.domain.com/webservice
www.nextdomain.com/webservice
secure.applesauce.com/webservice

    all in the same environment?

A: Well, the answer is ... maybe.  In a simple web server environment (described above), the request would be received by the web server, and it would basically ask the WebSphere Application Server plugin module:

Can you handle this request?

  WebSphere doesn't like ambiguity, so it doesn't allow you to have the same resource deployed on two different (i.e., non-clustered) federated application servers.

  Is there a way to do it?  Yes.

  How depends upon whether a Deployment Manager is involved or not.

  For a non-DM scenario, the plugin-cfg.xml files for each of the AppServers would have to be merged. And the same resource could exist on as many AppServers are you want.  However, the plugin code will need to have the resources "fully qualified" in order to get the request routed to the proper AppServer.  By default, the virtual host for an application will be '*', i.e., whatever hostname.  But, if you try to merge two plugin-cfg.xml files, each with the same resource (i.e., "webservice") both having  the default hostname of "*", then the plugin code will never send requests to the 2nd instance because they are "equally valid", and it will always pick the first.

  So, in the plugin-cfg.xml from machine #1, where the resource "webservice" is mapped to "*", you need to fully qualify the hostname (i.e., change "*" to "www.domain.com").  And when you add the resource information from host #2, you need to change the "*" to "www.nextdomain.com", and for the 3rd, change the "*" to "secure.applesauce.com".

  This way, the plugin will be able to differentiate the request, and route it to the appropriate AppServer.

Does this make sense?

Author

Commented:
Single greatest most complete answer I have ever gotten on EE!  Thank you so much!
HonorGodSoftware Engineer
CERTIFIED EXPERT

Commented:
Wow, thank you so much for the nice words.

Thank you also for the grade & points.

Good luck & have a great day.

Explore More ContentExplore courses, solutions, and other research materials related to this topic.