Table of Contents
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. Project Summary

2.1 Project Description
2.2 Risks and Assumptions

3. Problem Summary

3.1 Problem Area
3.2 Justification

4. Technical Description

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

1. Introduction

1.1. Project/Component Working Name

SAF/AMF support in SailFin

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

Nandini Ektare : nandini.ektare@sun.com

Hong Zhang : hong.zhang@sun.com

1.3. Date of This Document

09/17/2007

2. Project Summary

2.1. Project Description

Enable support for AMF (Availability Management Framework) in an environment where availability of SailFin instances is managed by SAF (Service Availability Framework) based middleware.

2.2. Risks and Assumptions

Definition and Configuration of SailFin cluster topology / application (un)deployments is still done by the SailFin Domain Application Server (aka DAS). The one-pager addresses management of SailFin cluster runtime only.

The translation of the domain configuration information (presently available in DAS) to AMF understandable form is done using separate SailFin tools. Availability and stability of these translation tools, though orthogonal, is core to proper functioning of the presented solution.

3. Problem Summary

3.1. Problem Area

Production deployments of the SailFin need the ability to leverage the SAF implementations which are gaining popularity in the telecommunications industry as they allow system designers to build highly available applications that are interoperable and portable across a variety of compliant middleware and platforms.

This one-pager proposes a mechanism to plug SailFin into a SAF compliant implementation.

More information on SA Forum efforts, their two interface specifications: AIS (Application Interface Specification) and HPI (Hardware Platform Interface) and role of AMF within the AIS is available here

Within SAF, AMF specifies a software entity that provides service availability by coordinating redundant resources within a cluster to deliver a system with no single point of failure. This framework provides a set of APIs to enable highly available applications. It drives the high availability state of various system components, and monitors their health by invoking callback functions of these components. It also manages the readiness state without exposing it to components and further allows a component to query the framework for information about a given component's high availability state, using functions defined in the set AMF APIs.

3.2. Justification

4. Technical Description

4.1. Details

Start/Stop of Instances

As part of providing service availability through AMF, AMF controls start/stop of the instances which is traditionally done by the Node Agent.

AMF starts instances through the existing MBean interface in Node Agent. AMF stops instances using the J2EEServer JSR-77 MBean present in the Server Instance.

1. AMF may start and stop the server instances when DAS is not running. i.e. Life-cycles of DAS and Server Instance need to be independent. AMF initiates the startup of an instance through Node Agent and relies on Node Agent's existing capability and constraints to synchronize config and application data repository to ensure a reliable and consistent experience of instance start-up.

Note: Node Agent does synchronization in a split fashion. Preparation to synchronize is done by Node Agent and actual synchronization is done in a separate Sync VM. If this functionality could be separated out and exposed individually AMF can use that and dependency on Node Agent will be completely removed.

2. Node Agent should not start it's managed instances during startup, nor should it shut them down during shutdown. Node Agent should not watchdog instances being made highly available through AMF. These tasks are delegated to the AMF implementation

3. SailFin instance needs to load an AMF-enabling (native) code during startup. This code is referred to as JAA-AMF (Java Availability API - Application Management Framework) code. JAA-AMF Provider code has to be loaded during Instance(and DAS) and Node Agent start-up.

A system-all LifeCycle Module within DAS and instances will load the JAA-AMF provider code. This can be handled by creating the domain with a profile like "amf". For details on profiles see GlassFish Profiles Specification. When it is done this way, it applies uniformly for all Server Instances including the DAS.

Since Node Agent does not have the equivalent entity, this logic is embedded in the NodeAgent startup Alternatively an equivalent extensible entity could be introduced in Node Agent, but it's not clear who else will use this extension. So alternative may not be required.

The Provider code will be in the form of a native library. Add details of the library name

Every Instance obtains an environment variable "SA_AMF_COMPONENT_NAME" during startup

Start/Stop of Application

In addition to managing the starting and stopping of the instances, the AMF also manages the starting and stopping of the applications deployed in the instances.

AMF will manage the starting and stopping of the applications through JSR77 MBean start/stop interface.

1. Deployment: The (root) JSR77 MBean should be available after the deployment, even if the application was deployed in a disabled state.

2. Server (instance) start up: The (root) JSR77 MBeans should be available for all deployed applications after the server is started, even if the applications were previously deployed in disabled state.

3. The implementation of the JSR77 MBean start/stop should enable an authenticated client to start/stop (load/unload) an application:

• For standalone modules, load/unload the modules. Additionally:

• for standalone resource adapter, it will also load all the associated connector configurations and resources.

• for standalone AppClient, it will initialize the necessary Java WebStart Server environment.

• for standalone SIP module, equivalent MBean will be created and used to load/unload sip module.

• For application, the root JSR77 MBean will be invoked to load/unload all the modules of the application including any SIP modules if they exist.

Note: Definition/configuration of instances forming the cluster and deployment/undeployment of the applications to this cluster are still the responsibility of DAS and Node Agent.

4.2. Bug/RFE Number(s)

Add ids for --startinstances, --restartinstances RFEs

4.3. In Scope

Start/Stop of SailFin Instances by AMF

Loading AMF provider plug-in during SailFin instance startup

Start/Stop of Applications deployed on SailFin Instances

4.4. Out of Scope

Definition/configuration of clusters and instances in the SailFin and their translation to AMF`

Deployment/Undeployment of the applications to this cluster.

4.5. Interfaces

4.5.1 Exported Interfaces

4.5.2 Imported interfaces

// Disclose interfaces this project imports.

4.5.3 Other interfaces (Optional)

// Any private interfaces that may be of interest?

Interface

Stability

Exporting Project: Name, Specification or other Link.

Comments

com.sun.appserver.nodeagent.NodeAgentMBean

Since 8.1

StartInstance 

Either need to make this MBean  available in PlatformMBeanServer or the JAA-AMF Provider native code can call into the Appserver's MBeanServer.

add the JSR 77 MBean name

Since 8.1

StopInstance

4.6. Doc Impact

Yes. Additional options to de-couple Node agent and instance lifecycle management need to be documented and the impact of delegating availability to AMF instead of Node agent need to be captured

4.7. Admin/Config Impact

Asadmin CLI for start-node-agent has a new

–-stopinstances=true/false option

–-restartinstances=true/false option

4.8. HA Impact

The proposal provides a way to replace existing HA capabilities within SailFin with the industry standards proposed by SAF for achieving high-availability.

4.9. I18N/L10N Impact

None.

4.10. Packaging & Delivery

// Add packages names

Installation scripts would provide the JAA-AMF Provider native library. Again this may not be seen as an issue for this one pager, because it will be taken care of in the broader SailFin initiative FS.

4.11. Security Impact

None.

4.12. Compatibility Impact

None.

4.13. Dependencies

add the link for FS documentation of SailFin

5. Reference Documents

SAF and GlassFish : An Architectural document

SA Forum Home

6. Schedule

6.1. Projected Availability

November 2007