Comparing GUMS with other tools
No. GUMS runs under tomcat/apache, and will run fine no matter what userid you use to run tomcat/apache.
The only non-J2EE part that is being used is the authentication. If they can be configured to use the egee trustmanager, or to accept Grid Certificates and proxies, the rest shouldn't be a problem.
First of all, GUMS is a site tool and VOMS is a VO tool. I.e., you have a BNL GUMS, whereas you have an ATLAS VOMS. A VO uses VOMS to keep a list of members and their roles within the organization. A site uses GUMS to maintain the mapping between members' GRID credentials (certificates) and local site credentials (e.g., UNIX accounts).
GUMS can contact VOMS to retrieve the list of VO users that require a particular mapping. For example, if the GUMS configuration says: "all ATLAS members should be mapped to the 'atlas' account" then GUMS would contact the ATLAS VOMS server to find out who all the ATLAS members are.
If you want to use grid-mapfiles, GUMS can be used to generate them, as can various other external tools. Usually grid-mapfiles are generated according to the information present in the VOMS servers. For example, the external tool would contact the ATLAS VOMS, download the list of current users, and add them to the grid-mapfile.
Using grid-mapfiles by itself is typically good only in testing environments. GUMS provides an alternative. GUMS can be configured to provide dynamic mapping, thereby making grid-mapfiles unnecessary. In this configuration, the gatekeeper contacts GUMS directly when it needs a mapping, instead of consulting a grid-mapfile.
Edg-mkgridmap and the GUMS host (client) tool can both be used to create a grid-mapfile for a host. Edg-mkgridmap is a client (gatekeeper) tool only; it connects to the VOMRS databases, downloads info and creates a grid-mapfile for that gatekeeper only. GUMS has server and client portions. The GUMS server (which serves all the gatekeepers at the site) connects to the VOMRS databases, downloads info, and performs the mapping, then the GUMS host tool creates the site-wide grid-mapfile. GUMS provides a way to centrally manage resource access and the mapfile generation. Edg-mkgridmap can be used to contact GUMS to retrieve an already prepared grid-mapfile.
In addition, GUMS supports a richer, more complex and flexible policy than does edg-mkgridmap. You can also use GUMS for both grid-mapfile generation and in conjuction with a gatekeeper (or service) callout. For a small site with a simple configuration, edg-mkgridmap might be a simpler solution. For a bigger site, with a more complicated environment, GUMS offers more control and flexibility.
WARNING: I am not an expert in LCMAPS. This is my understanding of the differences.
The short (and not 100% precise) answer is: GUMS is a Policy Decision Point while LCMAPS is a Policy Enforcement Point. The longer answer is: GUMS allows you to set a policy at the site level for all your gatekeepers or resources. It's a service that waits for and responds to questions like: "Who should I map this guy to?". It doesn't actually enforce the mapping. In fact, GUMS cannot stand by itself; it needs to have other software contact it to either retrieve a grid-mapfile or to request a specific mapping (e.g., the GUMS host tools, or the gatekeeper callout).
LCMAPS, on the other hand, is inside the gatekeeper (or the gridftp server). It implements the callout, it determines and enforces the mapping. There is one for every gatekeeper; there is no central mapping, and no central policy. You configure each gatekeeper individually.
They are two different things, even though they implement some similar functionalities. In fact, LCMAPS could be used as the PDP for GUMS (i.e., LCAMPS could connect to GUMS as part of its decision process).