Help me understand websphere

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/

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?

Single greatest most complete answer I have ever gotten on EE!  Thank you so much!

Wow, thank you so much for the nice words.

Thank you also for the grade & points.

Good luck & have a great day.