Nandini/Hong,
At least when I try to read the one pager, it's mystifying--I have to
read and re-read the intro and I still don't understand what this
project does. Numerous assumptions, run-on sentences, weird
constructs like "the SailFin", etc. I have a hard understanding
sections 2.1 and 2.2, and I certainly don't know why the content of
2.2 is a "Risk".
This project seems to be about introducing new MBean methods and new
CLI commands--focus on the interfaces and functionality that are
exposed to the user, NOT the technical details.
"Since 8.1" is not a stability level. Is it going into 8.1 or 8.2 or
9.0 or 9.1 or 9.2 or all of the above?
===> I have no idea what release(s) this applies to. What previous
case(s) if any are relevant?
===> Reduce the number of buzzwords/phrases and write in plain English.
===> Assume your readers don't know what Sailfin/AMF/SAF are (I just
recently came to understand what SailFin is myself).
===> I just don't see how section 4.1 is useful to anyone. It's very
technical, and makes so many undefined references to other existing
pieces that days of learning would be needed to understand if it's
accurate or not.
===> "Either need to make this MBean available in
PlatformMBeanServer or the JAA-AMF Provider native code can call into
the Appserver's MBeanServer." => Hopelessly confusing (to me at
least). Is this relevant to an end user or another project importing
it?
Lloyd
On Sep 21, 2007, at 1:55 PM, Nandini Ektare wrote:
> Here is the one pager for reference. We will discuss this.
>
> Nandini
>>
>
> One Pager: SAF/AMF support for SailFin release.
>
> 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_at_sun.com
>
> Hong Zhang : hong.zhang_at_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.
>
> 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.
>
> 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
>
> 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.
> Deployment: The (root) JSR77 MBean should be available after the
> deployment, even if the application was deployed in a disabled state.
> 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.
> 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
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net