Table of Contents (Status: Draft, Ready for Review, Reviewed, ARC'ed )
1. Introduction

1.1 Project/Component Working Name
1.2 Name(s) and e-mail address of Document Author(s)/Supplier
1.3. Date of This Document

2.1 Project Description
2.2 Risks and Assumptions

3.1 Problem Area
3.2 Justification

4.1 Details
4.2 Bugs/RFE's
4.3 Scope
4.4 Out-of-scope
4.5 Interfaces
4.6 Documentation Impact
4.7 Configuration/administration Impact
4.8 High Availability Impact
4.9 Internationalization
4.10 Packaging
4.11 Security Impact
4.12 Compatibility
4.12 Dependencies

5. References
6. Schedule
7. Document History

1. Introduction

1.1. Project/Component Working Name

GlassFish V2/Sun Java System Application Server 9.1.

1.2. Name(s) and e-mail address of Document Author(s)/Supplier

Kedar Mhaswade (Kedar.Mhaswade@Sun.Com)

1.3. Date of This Document

09/11/2006.

2. Project Summary

This project discusses the support for application server usage profiles (profiles, for short). A usage profile (or profile) identifies how a particular kind of users use the application server software. Once a profile is identified by a user, the support for the same planned for this release will take care of relevant out-of-the box configuration of the application server runtime such that its user-experience is in sync with the expectation.

2.1. Project Description

Application Server Software is used in a few significantly different ways for significantly different purposes. A developer might want to try out the latest technology advancements in and out of the Java EE Specifications in a relatively painless manner. In such cases, the general security requirements are not that stringent. A fast response from the server however, can make significant difference to the user-experience. A deployer on the other hand, might want to deploy the state-of-the-art Java EE applications in a production environment that has to be inherently secure. Although the same software can be manually tuned to specific requirements using administrative tools, it is the out-of-the-box configuration (that reasonably meets user expectations) that matters and that is the focus of this project.

Traditionally, this kind of tweaking of the configuration of the runtime was achieved through provision of multiple editions of the software. For example, the Platform Edition of Sun's Application Server was geared towards developers and Enterprise Edition was geared towards large enterprises. However, this is too heavyweight a solution to realize the aim to use the software in a particular manner and has following limitations:

• It creates unnecessary barricades in users' perception of capabilities of the application server software. This problem worsens when virtually all of the source-code is open. It becomes complex to maintain different distributions in that case and then limit a particular distribution of the open-source project to a subset of things that you can do with it.
• It unnecessarily associates application server binaries and configurable domain runtime in an inseparable manner. For example, all the distinct server runtimes (domains) created in a Platform Edition distribution are functionally equivalent. In other words, in a given distribution of application server software, you cannot easily configure two runtimes, one of which is tuned for developers and other for deployers. This is an artificial demarcation that is not sustainable for long.

What is needed is a single distribution of application server software (that fully implements Java EE Specification) that is capable of behaving according to its expected primary usage, based on its configuration. Usage Profiles is supposed to be a step in that direction. In this release, the foundations for this will be laid. The exact relationship of the deliverables of this project with server software distributions is rather unspecified at this point. A key reason for this is the backward compatibility requirements of application server and various environments (e.g. Solaris Operating System, Java Enterprise System etc.) in which it integrates. It might then be the case that a particular profile is available on a particular distribution of application server, but it would make sense to not have such a distinction as far as possible.

It is important to distinguish the intended scope of profiles in GlassFish V2 and their (that of profiles) conceptual extensions. Going ahead, it is required that application server runtime is configured to a particular kind of applications rather than a particular kind of users. This is expected to optimize the performance (startup time, memory footprint etc.) of application server while hosting applications of a given kind. An example would be a Web Developer Profile, where the users intend to use the runtime to develop/deploy only the web applications. To truly support such an on-demand usage of application server, a more modular structure of application server components is needed and that is clearly out-of-scope for this release (but it is in line with the general direction we seem to be taking now). Both these points of view should work in concert and should not interfere with each other.

A key enabler of this feature is the careful distinction between binaries and runtime configuration that Sun's application server has been promoting, historically. When the bits are put on the disk, what is of essence is the concept of an administrative domain which optionally provides a pre-configured runtime for the user applications. Various administrators are already able to exploit the same set of bits to suit their specific needs. This project builds on this sound foundation.

2.2. Risks and Assumptions

There are no major technical risks with this project. A moderate risk is with respect to making various capabilities of application server implemented as life cycle modules, configurable. These are pluggable components of application server which are very closely related with the notion of profiles. In theory, a particular life cycle module should be made pluggable and should be enabled/disabled depending upon its association with respect to a profile. In practice however, this is a stretch goal for this release.

A moderate risk (non-technical) is with respect to the distribution of application server software. Even though a loose coupling is desired between usage profiles and application server editions, an unspecified behavior here might lead to confusion and might result in lack of interest. A detailed discussion of various bundles and compositions thereof is however beyond the scope of this document. A recommendation is made below in this regard.

For GlassFish V2, a set of predefined profiles will be provided. There is no provision of custom profiles for this release.

3. Problem Summary

3.1. Problem Area

Several questions have been asked and suggestions have been given to improve the developer experience of GlassFish. This specification is a vehicle to accumulate all such suggestions and formalize them into a product feature. The basic problem that is being attempted to solve is how to improve the response of application server when it is put to a specific use.

3.2. Justification

This is the best time to offer such a feature, mainly to drive the GlassFish adoption efforts. Given the various flavors in which GlassFish platform is available, it makes sense to provide usage-profile support for GlassFish V2.

4. Technical Description

4.1. Details

4.1.1 Presenting Profiles to Administrators/Developers

The proposed manner in which a user comes across the profiles is using the asadmin create-domain command with a --profile option. An example invocation of this is as follows:

asadmin create-domain --user admin --adminport 4848 --profile developer dev-domain

The domain here symbolizes an application server runtime that is suitable for both server administration and user applications.

The valid values that the option profile accepts are: developer, cluster and enterprise. All the values are case insensitive. What follows describes in detail the contract of this command.

• The value developer implies that the domain should be configured (as best as it could) to be run in a development environment. The value cluster implies a user should be able to create clusters of application server instances. The value enterprise implies that a user intends to use the given domain in production environment for large-scale deployments. The details of these configurations that define this profile are covered in 4.1.2 below.
• Actually, there is no need for a separate cluster profile because it is logical for developers to be able to create clusters incurring only marginal overhead. However, it is the current state of implementation that mandates such a separate profile which mostly resembles the developer profile, except that the clusters of application server instances could be created. The main reason that we are introducing this profile is to avoid sweeping changes to the server-side Pluggable FeatureFactory implementation for GlassFish V2 release. At some point in time, these two profiles are expected to merge. That will happen when additional capabilities implemented in the server (as life cycle modules) to support cluster deployments can be easily turned off if needed. From this point of view, the developer profile is a degenerate case of the cluster profile.

In addition to the above, two classic profiles are introduced. It might be possible to remove the classic profiles going ahead. The need for classic profiles arises because we are introducing profiles for the first time in this release. See section on installers for details.

4.1.2 Comparison of Various Profiles w.r.t. Configuration Parameters

The two tables (1, 2) below describe the gist of this project. The first table gives a glimpse of how the configuration of a domain for a given profile should look like, whereas the second table provides the rationale for choosing a particular configuration parameter.

It is important to note that even if most of domain's configuration is stored in the well-known interface called domain.xml (here is the schema), there are other configuration files that will have to change to support various profiles.

Table 1: Distinction within Profiles

Table 2: Why a particular parameter is a profile-defining-parameter

4.1.3 Distinction Among Profiles

This specification does not define any specific rules regarding defining a profile. It (defining a profile) is largely an outcome of need. There are various items to consider while defining a profile and hence it is not easy to make any rules around this. In general, it is subjective whether to create a new profile or to make a set of configuration changes a part of an existing profile.

This brings up an interesting point: Why have 2 profiles like developer and enterprise or developer and cluster? Can these be subsumed under one profile?

A reasonable explanation can be provided along the following lines:

• At the center of it, a profile is almost completely defined by a set of configuration parameters. These are called defining parameters of a profile. Two different profiles have different values for most (if not all) defining parameters.
• A profile should result in optimized performance, expected user experience right of the bat and minimal post-creation configuration changes to achieve its promise. A few changes here and there do not result in a new profile. Thus a profile must represent a class of users.

Food for thought:

Do developers Need to Create Application Server Clusters? (Do we need yet another profile so that there is a runtime support for clusters)?

4.1.4 Profiles and Administrative Clients

Profiles is a server-side phenomenon. It is not expected that admin clients know the profile of a particular domain and behave differently. Here is how various admin clients will be impacted by profiles:

• asadmin client: The asadmin client is designed in such a way that it can help an administrator administer various domain runtimes (with unknown usage profiles) from a single shell. In other words, asadmin is backend-agnostic and as such, it cannot (and should not) present a command set that is applicable to a domain with given profile. For example, if there is asadmin is directed to a domain with developer profile, it is not possible for asadmin to hide a command like create-cluster. The command set is thus not impacted by this project.
• AMX client: AMX is the programmatic API. We have exactly one API that caters for the entire application server administration. This is true for previous releases. Thus, by definition, AMX is not impacted by profiles. For this release, as said elsewhere, there will be no AMX support to realize a particular profile. AMX can only be used after the domain has been created and started.
• Admin GUI client: This is implemented as a web application deployed to a particular domain that is being administered. The current plan is to query the administrative MBeans about certain capabilities and show visual differences when certain support is not present in the MBeans. This, however is independent of this project on profiles.

4.1.5 Profiles and Application Server Installers and GlassFish Bundles

As of now, we have following basic distribution mechanisms (this excludes the Java EE SDK distributions and variations thereof. The Java EE SDK distributions are based on PE distribution).

Following has been decided at the architecture forum in this regard:

• PE user and Java EE SDK user should be able to create clusters. In other words, in PE, cluster profile is available.

To take care of these differences in the way we bundle the application server software, the provision of asaenv.conf[bat] has been made. Ideally, a pluggable architecture that lets users download and use pieces of software is a model we should embrace.

One of the goals for GlassFish V2 is provision of one bundle that has capabilities of clustering. This means that there will be one bundle by merging bundles 3 and 4. The setup.xml will set up the developer profile, whereas the setup-cluster.xml will set up the cluster profile.

Following should be noted in this regard:

• Only a single set of templates will be used for all types of installations. These templates are stored at install-dir/lib/install/templates/ee. The portion "ee" in the name of this path is restored to mitigate the risks associated with various environments in which application server is integrated. This should not be a problem because if a particular jar (referred to in a particular template) is not available in given distribution, the associated functionality will not be available.
• In order to retain the user expectation of domain creation process, two additional profiles will be introduced which will be the default profiles for respective installations. These are classic-pe and classic-ee. The classic-pe will be the default profile for PE installation, whereas classic-ee will be the default profile for EE installation.
• The values for various profile-defining parameters in the case of classic-pe and classic-ee is not noted above because they are defined by the classic templates that are available in PE and EE installations.
• It is desirable that the standalone installers for PE and EE provide a choice to the users so that they can choose the profile for the default domain. Note that the default domain is created by the installer and it is expected that users installing the product get to choose the profile for the default domain. It is explained above, what the default profiles for each installer should be. Thus,
  • PE installer has a choice among developer, cluster and classicp-pe.
  • EE installer has a choice among developer, cluster, enterprise and classic-ee.

4.1.6 Profiles: Noteworthy

Here is something that you should know, about this implementation of profiles:

• A running domain does not know anything about its own profile. For example, a domain created like asadmin create-domain --profile enterprise ... does not have any knowledge at runtime about specifics of this profile. Coupling it loosely like this has several benefits above and beyond making migration within profiles easy. If a user has forgotten about what profile a particular domain is, AMX and Admin GUI will have ways to identify possible profile of a domain but it is not a defined attribute of a domain. The shortcoming of doing it this way is that the startup of the server cannot (easily) change its behavior, since configuration does not have an explicit indication of the profile of the domain being started. [TBD: Discussion Required].
• In general, a user is supposed to know the profile of a domain. A profile is a user's view of application server configuration.
• It is quite possible that user reconfigures an existing domain to behave in a profile different from its original profile. From this standpoint, a profile is a fluid property of a domain.
• An important outcome of this discussion is that the so-called ClientPluggableFeatureFactory will be removed. The way the asadmin client deals with the domain creation will be determined completely by the profiles.

4.1.7 More about Enterprise and Cluster Profiles

       
       ________________________________________________	  
      |  ____________        ___________               |               NA: Node Agent
      | |            |      | Instance 1|---|cfg1|     |
      | |   DAS      |      |___________|      |       |
      | |____________|          (NA1)      |Template|  |
      |        |                           |Config  |  |
      |     ___|___          ___________      |        |
      |    |das-cfg|        |Instance 2 |---|cfg2|     |--------Domain Boundary
      |    |_______|        |___________|              |
      |                         (NA2)                  |
      |________________________________________________|
	  

The enterprise architecture (schematic) of the application server is shown above. DAS is the administration server that manages other Java EE Engines (in that domain) that host the user applications. As an additional benefit, (at additional costs that are arguably unnecessary) DAS is a fully functional, compliant Java EE Engine. Administrators can choose (though they rarely, if at all, do so) to deploy applications to the DAS The essence however, of the enterprise profile is the provision of standalone and clustered server instances. As shown in the diagram, each instance has a configuration (shared or not) that is based on a Template Configuration. Note that Template Configuration applies not only to the existing server instances, but also to the instances that might be created in future. DAS too, has its own configuration (shown as das-cfg) that is independent of the Template Configuration. Thus, following holds:

It is quite important then to know what the profile-specific configurations apply to -- DAS Configuration or Template Configuration. It applies to both unless specified otherwise. A significant outcome of this is:

• When an administrator chooses to create a domain with Cluster/Enterprise Profile, a blueprint of the server instances is also reasonably determined. This further reduces the administrative overhead to separately tune those server instances when enterprise deployments occur.

4.2. Bug/RFE Number(s)

These are indicated throughout the document where applicable. This feature however, is an outcome of various discussion threads on GlassFish Discussion Forum.

4.3. In Scope

All that has been said about realizing usage profiles in Section 4.1 is in scope for this project. Note that the composition of any defined profile is based on experiential knowledge. It is a learning process. For example, we may learn over time that a particular configuration setting is suitable for a particular usage.

4.4. Out of Scope

Since this entire topic is of general interest and naturally has various interpretations, it is important to list down what this project is not. Following things are not in scope for this project, at least for this release:

• There is no programmatic (AMX) configuration support or Admin GUI (Console) support planned for profiles, for this release. The only means to manifest profiles shall remain the asadmin command, create-domain.
• There is no migration planned for an existing domain that's created (or not) with a particular profile. It is not planned that the profile of a domain can be changed after it is created. Thus, this feature is not intended to conflict with the upgrade story for application server. It is to be noted however that this work can be extended to provide a reasonable upgrade path, in following releases.
• Although the concept of profiles can easily be extended to take care of custom needs, it is not planned to provide such a support for this release. GlassFish V2 will only provide a profile foundation and basic profiles integrated into the product.

4.5. Interfaces

• http://www.opensolaris.org/os/community/arc/policies/interface-taxonomy/ describes the permitted interface taxonomy.

4.5.1 Exported Interfaces

4.5.2 Imported interfaces

4.5.3 Other interfaces (Optional)

4.6. Doc Impact

There will be considerable impact of this project on documentation. The following will be impacted:

• Admin Guide.
• asadmin create-domain manpage.

4.7. Admin/Config Impact

This has been dealt with elsewhere (1, 2). If this dependency is resolved to have an indication of profile in a domain's configuration, the configuration schema might change (although we can leverage a <property> element provision) to accommodate that.

4.8. HA Impact

Not applicable.

4.9. I18N/L10N Impact

No considerable impact above and beyond product impact.

4.10. Packaging & Delivery

Here is the packaging impact:

For installation impact, see here (section 4.1.5).

4.11. Security Impact

Not applicable.

4.12. Compatibility Impact

// Incompatible changes to interfaces that others expect
// to be stable may cause other parts of application server or
// other dependent products to break.

// Discuss changes to the imported or exported interfaces.
// Describe how an older version of the interface would
// be handled.

// List any requirements on upgrade tool and migration tool.

4.13. Dependencies

No dependencies on other projects. Some subtle dependencies with respect to positioning.

5. Reference Documents

Refer to Product Documentation for Sun's Application Servers, especially the admin guide.

6. Schedule

6.1. Projected Availability

Fully functional implementation by Milestone 3 - GlassFish V2. Refer to overall milestone document.

7. Document History