GlassFish V2— |
|||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1. Introduction1.1. Project/Component Working NameUsage Profiles for GlassFish 1.2. Name(s) and e-mail address of Document Author(s)/SupplierKedar Mhaswade (Kedar.Mhaswade@Sun.Com) 1.3. Date of This DocumentFeb. 16, 2007 2. Project SummarySee section 3 . 2.1. Project DescriptionProvision of custom and predefined usage profiles. 2.2. Risks and Assumptions3. Problem Summary3.1. Problem AreaAn application server distribution consists of two main components -- a set of binaries and a set of templates that are processed in a particular manner to create certain configurations out-of-the-box. A configuration can be tweaked after it is created in such a way that it can support (or not support) certain capabilities. It is just that it is quite administration-intensive task in that the administrator has to execute several configuration operations. It is also important that we impart a certain shape and form to the configuration right from the beginning. Customers have also expressed interest in being able to customize the configuration creation process in a defined manner. This is because the configuration that they want to start with denotes their typical use of application server runtime. Most of the configuration is stored in an XML document named "domain.xml". The advent of GlassFish made it mandatory to plug-in different implementations for a particular functionality rather than rigidly bundling the components in a particular distribution. This bundling was something that used to happen in earlier releases. An example would be if the user downloaded the Enterprise Edition of the product, the session persistence had to be based on the HADB (third-party) software. This is rather too constraining. 3.2. JustificationGlassFish requires clustering capability and a way to configure various components of application server to facilitate the typical use of the software. 4. Technical Description4.1. DetailsThe general approach is to be able to process the configuration files in a customizable manner such that a particular configuration is created. It is expected that administrators augment the process using the standard techniques like XML style-sheets. A number of predefined profiles are bundled along with the product distribution so that existing users continue to configure the product in a way they used to. Administrator runs a single command "asadmin create-domain" specifying the name of the profile for which the configuration should be created. A profile is a well-defined set of files according to interface table specified below and are stored in a known location. When the domain.xml is to be created during the create-domain process, a properties file that contains various customization hooks is read and processing is according to them. In short, it provides ways and means to control how the initial domain.xml will look like. This approach simplifies the customization because more often than not, administrators are interested to build upon existing base templates and tweak them using transformation techniques. In order to fully support the created configuration at runtime, all the binary components of the server should be available in all the distributions. This is another deviation from the previous releases, where the type of installation dictated the name and number of product packages installed on the system. This project helps us to reach a transition stage where a particular installation of software packages gives rise to co-existence of domains with different capabilities rather than rigidly binding the type of configuration of the runtime with the type of installation. This was a limitation with earlier releases. This project also gives us a vehicle to optimize predefined profiles for their intended use. For example, a developer profile by default configures the server such that web server's access logs are disabled, resulting in better responsiveness. Several such improvements were suggested by the users of the GlassFish application server, on the discussion forum. 4.2. Bug/RFE Number(s)4.3. In ScopeThis project will provide an interface to customize the application server domain creation process. This release provides such a capability to only the domain.xml file. The project guarantees that backward compatibility is preserved. 4.4. Out of ScopeIt is not the aim of this project to provide customization support for all the configuration files (e.g. startup/shutdown scripts, security policy files) that are required for proper functioning of the server runtime. 4.5. Interfaces4.5.1 Exported Interfaces
4.5.2 Imported interfaces
4.6. Doc ImpactAdmin Guide, primarily, which explains how to create custom configurations, man pages. 4.7. Admin/Config ImpactThis projects defines default configurations for three basic profiles that are bundled along with the product. 4.8. HA ImpactThere are no new requirements. 4.9. I18N/L10N ImpactNone. 4.10. Packaging & DeliveryBundled "developer" profile: Optimized for developers SUNWasu/lib/install/templates/developer Bundled "cluster" profile: Provides clustering capability, uses in-memory session persistence and JKS for security. SUNWasu/lib/install/templates/cluster Bundled "enterprise" profile: Provides clustering capability and preserves backward compatibility for high availability solution (HADB) and uses NSS for security. SUNWasu/lib/install/templates/enterprise Bundled example for a custom profile: Explains the custom domain creation process. SUNWasu/lib/install/templates/custom 4.11. Security ImpactNone anticipated. 4.12. Compatibility ImpactNone anticipated. Care has been taken to preserve the previous distributions. 4.13. DependenciesNone. |