Ken's questions reflect a need to describe how GMS is accessed in GF v3.1 architecture.
Mahesh and I discussed the need for a Glassfish proxy to GMS API so other modules do not
have a direct dependency on Shoal GMS jar unless it is needed.

I'd like to go over here just what the ORB needs from GMS.  The code seems to be mainly in the orb/orb-impl
bundle in ASORBUtilities and GlassFishORBManager.  GlassFishORBManager uses two methods in
ASORBUtilities:
    * isGMSAvailableAndClusterHeartBeatEnabled
    * initGIS( ORB )
           o Mainly calls initFISUsesGMS
                 + This in turn creates a new instance of com.sun.enterprise.ee.ejb.iiop.IiopFolbGmsClient
                 + This is in the EE part of the code for GFv2
     * IiopFolbGmsClient
           o Directly reference com.sun.enterprise.ee.cms.core.GMSFactory to call getGMSModule
                 + We use the following from GroupManagementService:
                       # addActionFactory
                             * The ORB uses:
                                   o FailureNotificationActionFactory
                                   o JoinNotificationActionFactory
                                   o PlannedShutdownActionFactory
                       # getAllMemberDetails

 Right now, both of these depend on loading a class:

     * isGMSAvailableAndClusterHeartBeatEnabled:
           o loads com.sun.enterprise.ee.cms.core.GMSFactory, but does not create an instance of it
           o It also used the server beans (config beans now?) to get a Cluster object
           o The Cluster object is then queried for isClusterHeartbeatEnabled
           o Is there any equivalent for this in v3.1?  Or do we just need to inject some object (GMSFactory?)
     * initGIS

 From all of this, assuming that the low-level APIs have not changed, it looks like the main thing the
 ORB needs is to @Inject GMSFactory.  Does this fit with the GMS architecture in v3.1?