Difference between revisions of "ALF/CoreServices/AdminService"

Revision as of 16:06, 27 September 2006

ALF Applications

Introduction

An ALF application is a set of ALF events and Service Flows configured together with the intent of providing a coherent service. An ALF application can be expressed in an ALF Event Map.

Building

To build an ALF application it is necessary to construct an ALF Event Map expresses the relationships between the various ALF events and the Service Flows that are intended to run on those events. Typically the set of events and the Service Flow definitions will differ between applications. However, tools that participate in ALF cannot distinguish between ALF applications. This is left to the ALF event manager. The ALF event manager distinguishes between applications via the application name provided in the ALF Event Map

Deployment

To deploy an ALF application, an ALF Event Map for that application is provided to the ALF event manager. The ALF event manager loads the ALF event map and merges it into its runtime event dispatch table. The dispatch table entries are distinguished by the application name provided in the Event Map. This allows independent runtime control (pause resume etc) over each of applications deployed to the ALF event manager. An ALF event manager can host one or more ALF applications. ALF applications are distinguished by only by name. The ALF event manager does not manage versions. it is the responsibility of the deployment tool to keep track of application versions and how they are named and related. Generally this is not an issue since only one version of an application is deployed at once. Thus the deployment tool could choose to un-deploy the old version and re-deploy the new version using the same name. However, if it is desired to distinguish between versions of an application at runtime then the deployment tool must deploy these versions using different names. For example and application named “BuildAll” may have various versions over time. These may be distinguished using a naming convention that appends a version designator as in “BuildAll-1_0”, “BuildAll-1_5”, “BuildAll-2_0” etc. The ALF event manager sees these as separate applications and does not relate them in anyway. Any records generated by ALF will be correlated to the application name. If the application needs to correlate data between its various versions then either the various application versions must be deployed using the same name or the application design must provide its own mechanism to do so.

Runtime

ALF applications may overlap in their use of tool emitted Events and Service Flows. These entities are defined by the system configuration from the perspective of the ALF event manager. The event manager cannot implicitly distinguish them by application. If two or more applications share the same event to service flow mapping then the event manager must be able to distinguish between these cases when it is configured. In this case the event manager will treat each application’s event to service flow mapping as distinct. Where deployed applications share a common event to service flow mapping definition, it will dispatch the event once per application creating a new instance of the service flow for each application. This convention anticipates the use of separate BPEL servers per application. The separate service flow instances will be distinguished by the application identifier supplied by the event manager in the event.

ALF Event Manager Administration Service

Introduction

The ALF Event Manager has a number of runtime management controls that can be invoked via its Admin web service. These controls include • The ability to deploy and un-deploy an application event map. • The ability to pause and resume a deployed application. • The ability to retrieve a deployed application event map • The ability to report the current status of the deployed applications. • The ability to retrieve the content of the ALF Event Manager Logs

Deploy

string deploy(string eventMap, bool startImmediately ) throws alfError.invalidApplicationName, alfError.invalidEventMap

The given application event map is send to the to the ALF event manager which merges it into the running event map. If “startImmediately” has the value “true” then the deployed application is immediately started and any events that match its definition are dispatched accordingly.

Returns the application name from eventMap.

If application named by the event map is already deployed the operation will throw alfError.invalidApplicationName . If the eventMap is invalid then the operation will throw alfError.invalidEventMap If no application name is specified in the eventMap then it is assumed to represent an application named “default”. In this case the current “default” application must be un-deployed before the new “default” application can be deployed.

Un-deploy

void undeploy(string applicationName) throws alfError.invalidApplicationName

The named application is paused (see Pause below) if it is not already in that state and then undeployed. The various event-service flow mappings are removed from the run event map.

If application named by the event map is not deployed to the event manager, the operation will throw alfError.invalidApplicationName .

Pause

void pause()

All events currently being dispatched are completed. All new event dispatching is stopped. Events received after a pause is requested are logged but will never be dispatched and may be considered lost.

If the ALF Event manager is already paused this operation just returns without taking any action.

Note: Should pausing queue events?

Pause Application

void pause(string applicationName) throws alfError.invalidApplicationName

All events currently being dispatched to the given application are completed. All event dispatching to the named application is stopped. Events received for the given application are logged but lost.

If application named by the event map is not deployed to the event manager, the operation will throw alfError.invalidApplicationName . If an application is explicitly paused it must be explicitly resumed

Note: Should pausing an application queue the events to that application?

Resume

void resume()

Event dispatching is resumed to all applications that are not explicitly paused. If the ALF Event manager is not paused this operation just returns without taking any action.

Resume Application

void resume(string applicationName) throws alfError.invalidApplicationName

Event dispatching is resumed to the named application. If the application is not paused, this operation just returns without taking any action. If application named by the event map is not deployed to the event manager, the operation will throw alfError.invalidApplicationName .

Get Runtime EventMap

string GetEventMap(string) The full runtime event map is returned as an XML string Note: Will this get too big for this operation to be practical?

Get Application EventMap

string GetEventMap(string applicationName) throws alfError.invalidApplicationName The event map associated with the named application is returned as an xml formatted string. If application named by the event map is not deployed to the event manager, the operation will throw alfError.invalidApplicationName .

Get Application Status

applicationStatus[] GetApplicationStatus() An array of status structures for all the deployed applications is returned. The status structure contains, at least the application name, whether it is paused or running. Note: Should we extend this to include some minimal statistics? Fex Time deployed, time last resumed, number of events since past resume etc.

Logging

string[] listLogNames() The list of named logs stored by the ALF Event Manager is returned string listLog(LogName) throws alfError.invalidLogName The Content of the named log is returned as a string If application named by the event map is not deployed to the event manager, the operation will throw alfError.invalidApplicationName .