1. Introduction

This document presents Management Task Force (MTF) proposed additions to the Web Services Architecture (WSA) as described in the following draft document http://dev.w3.org/cvsweb/~checkout~/2002/ws/arch/wsa/wd-wsa-arch.html. The contents of this document was contributed by the members of the MTF and discussed among the following active members of the MTF: Heather Kreger (IBM), Mark Potts (Talking Blocks), Igor Sedukhin (CA), Hao He (Thomson), Ying-Lin Husband (HP), Zulah Eckert (HP). The final consensus on the details in this document was not reached.

The proposal is to add clarity to certain aspects of the WSA and to make possible for the MTF to express sensible Web Services Management Architecture.

2. Service Lifecycle

A Service lifecycle is expressed in the state transition diagrams below. There are two separate transition paths: service itself and request processing.

2.1. Service

States

UP (compound) - a Service is capable of accepting and processing requests (i.e. available).
DOWN (compound) - a Service is not capable of accepting any requests (i.e. not available).

Transitions

Enter to UP or DOWN (Start of Life) - a Service starts its life in UP or DOWN states.
Exit from UP or DOWN (End of Life) - a Service ends its life from DOWN or UP states.
Activate - a Service can become available which transitions it from DOWN to UP state.
Passivate - a Service can become unavailable (for many reasons, see Down Substates) which transitions it from UP to DOWN state.

State Transition Table

Action	From State	To State	Sub-State	Comment
Start of Life	Enter	UP	IDLE	Instantiated and available
Start of Life	Enter	DOWN	STOPPED	Instantiated but not available
End of Life	UP	Exit	-o-	Destroyed
End of Life	DOWN	Exit	-o-	Destroyed
Activate	DOWN	UP	-any-	Becomes available.
Passivate	UP	DOWN	-any-	Becomes not available.

Up Substates

States

IDLE - a Service is not processing any requests currently.
BUSY - a Service is processing requests currently.

Transitions

A Service normally enters UP state in IDLE state.
Relieved - a Service enters UP state in BUSY state if it was relieved (from DOWN/SATURATED, see Down Substates).
A Service may transfer from IDLE to BUSY and vice versa.
A Service exits UP state from either IDLE or BUSY.

State Transition Table

Action	Super State	Current State	End State	Comment
Accepts Request	UP	IDLE	BUSY	Currently PROCESSING requests
Completes all processing	UP	BUSY	IDLE	All requests completed (either FAILED or PROCESSED)

Down Substates

States

STOPPED - a Service was intentionally stopped (e.g. for administrative purposes).
SATURATED - a Service has exhausted its resources and cannot accept any new requests.
CRASHED - a Service is unavailable because of an internal malfunction (e.g. environmental problem).

Transitions

A Service enters DOWN state in either a STOPPED, CRASHED or SATURATED state.
Stopped - A Service may be stopped from any UP or DOWN state.
Relieve - a Service is relieved from saturation and exits a DOWN state (transitioning to an UP/BUSY state).
Recover - a Service was (automatically) recovered from malfunction and exits the DOWN state. It enters its UP state in the IDLE state
Restart - a Service was started again (manually) and exists a DOWN state. It naturally transitions to an UP/IDLE state.
Administrate - a Service can be stopped from being crashed (manually) for administration and maintenance.

State Transition Table

Action	Super State	Current State	End State	Comment
Manual Administration	UP	IDLE or BUSY	STOPPED	No longer accepting requests because of administrative action
Malfunction	UP	IDLE or BUSY	CRASHED	Malfunction in any UP state
Accepts Request	UP	BUSY	SATURATED	No longer accepting requests due to exhausted resources
Administrate	DOWN	CRASHED or SATURATED	STOPPED	No longer accepting requests because of administrative action
Processed or Failed Request(s)	DOWN	SATURATED	BUSY	Resources available after being exhausted such that requests can again be accepted
Recovery	DOWN	CRASHED	IDLE	Accepting requests again after a malfunction
Restart	DOWN	CRASHED or STOPPED	IDLE	Accepting requests again after being restarted
Manual Administration	DOWN	CRASHED	STOPPED	No longer CRASHED but not accepting requests

2.2. Request Processing

States

Request Received - a Service has accepted a request to perform one of its functional responsibilities.
Processing - a Service is doing some internal processing/execution to fulfill the requested function.
Processed - a Service successfully completed requested function returning results to the requestor.
Failed - a Service encountered an error and didn't complete the requested function, returning error to the requestor.

Transitions

A Service starts request processing when it accepts (receives) a request.
A Service starts execution (actual processing) after it received a request.
A Service transitions to either processed or failed state depending on the outcome of the processing/execution stage.
A Service exits request processing from either processed or failed state (which are mutually exclusive according to the previous transition).

State Transition Table

Action	Current State	End State	Comment
Accepts Request	Enter	REQUEST RECEIVED	Request received by the Service
Process the Request	REQUEST RECEIVED	PROCESSING	Commence execution of service function based on request received
Completion of processing	PROCESSING	PROCESSED	Successful completion of function executed based on the request received
Failure in processing	PROCESSING	FAILED	Unsuccessful completion of function executed based on the request received