Web Service Management: Service Lifecycle

Editors:: Hao He; Mark Potts; Igor Sedukhin

Abstract

This document expresses the life cycle of a Web service.

Status of this Document

This document captures work done by the management task force of the W3C Web Services Architecture Working Group. The Working Group felt this work was valuable but beyond the scope needed in the Web Services Architecture document. It is provided here for archival purposes.

This document was proposed in November 2002 by the Management Task Force of the Web Services Architecture Working Group. It is based on the 14 November 2002 version of the Web Services Architecture and the 14 November 2002 version of the Web Services Architecture Requirements. Consequently, this document is not entirely consistent with the current Web Services Architecture document.

Comments on this document should be sent to www-ws-arch@w3.org (public archives).

Patent disclosures relevant to this specification may be found on the Working Group's patent disclosure page.

Service Lifecycle

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

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

Start of Life (SOL) — a Service starts its life in UP state.
End of Life (EOL) — a Service ends its life from DOWN state.
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
Activate	None - SOL	UP	IDLE	Instantiated and able to accept requests
Activate	None - SOL	DOWN	STOPPED	Instantiated but not able to accept requests
Passivate	UP	None - EOL	-o-	Destroyed
Passivate	DOWN	None - EOL	-o-	Destroyed

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

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	-o-	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

Acknowledgements

This document is a product of the management task force of the Web Services Architecture Working Group: Zulah Eckert (HP), Hao He (Thomson), Yin-Leng Husband (HP), Heather Kreger (IBM), Mark Potts (Talking Blocks), Igor Sedukhin (CA).

Members of the Working Group are (at the time of writing, and by alphabetical order): Geoff Arnold (Sun Microsystems, Inc.), Mukund Balasubramanian (Infravio, Inc.), Mike Ballantyne (EDS), Abbie Barbir (Nortel Networks), David Booth (W3C), Mike Brumbelow (Apple), Doug Bunting (Sun Microsystems, Inc.), Greg Carpenter (Nokia), Tom Carroll (W. W. Grainger, Inc.), Alex Cheng (Ipedo), Michael Champion (Software AG), Martin Chapman (Oracle Corporation), Ugo Corda (SeeBeyond Technology Corporation), Roger Cutler (ChevronTexaco), Jonathan Dale (Fujitsu), Suresh Damodaran (Sterling Commerce(SBC)), James Davenport (MITRE Corporation), Paul Denning (MITRE Corporation), Gerald Edgar (The Boeing Company), Shishir Garg (France Telecom), Hugo Haas (W3C), Hao He (The Thomson Corporation), Dave Hollander (Contivo), Yin-Leng Husband (Hewlett-Packard Company), Mario Jeckle (DaimlerChrysler Research and Technology), Heather Kreger (IBM), Sandeep Kumar (Cisco Systems Inc), Hal Lockhart (OASIS), Michael Mahan (Nokia), Francis McCabe (Fujitsu), Michael Mealling (VeriSign, Inc.), Jeff Mischkinsky (Oracle Corporation), Eric Newcomer (IONA), Mark Nottingham (BEA Systems), David Orchard (BEA Systems), Bijan Parsia (MIND Lab), Mark Potts (Talking Blocks, Inc), Adinarayana Sakala (IONA), Waqar Sadiq (EDS), Igor Sedukhin (Computer Associates), Hans-Peter Steiert (DaimlerChrysler Research and Technology), Katia Sycara (Carnegie Mellon University), Bryan Thompson (Hicks & Associates, Inc.), Sinisa Zimek (SAP).

Previous members of the Working Group were: Assaf Arkin (Intalio, Inc.), Daniel Austin (W. W. Grainger, Inc.), Mark Baker (Idokorro Mobile, Inc. / Planetfred, Inc.), Tom Bradford (XQRL, Inc.), Allen Brown (Microsoft Corporation), Dipto Chakravarty (Artesia Technologies), Jun Chen (MartSoft Corp.), Alan Davies (SeeBeyond Technology Corporation), Glen Daniels (Macromedia), Ayse Dilber (AT&T), Zulah Eckert (Hewlett-Packard Company), Colleen Evans (Sonic Software), Chris Ferris (IBM), Daniela Florescu (XQRL Inc.), Sharad Garg (Intel), Mark Hapner (Sun Microsystems, Inc.), Joseph Hui (Exodus/Digital Island), Michael Hui (Computer Associates), Nigel Hutchison (Software AG), Marcel Jemio (DISA), Mark Jones (AT&T), Timothy Jones (CrossWeave, Inc.), Tom Jordahl (Macromedia), Jim Knutson (IBM), Steve Lind (AT&T), Mark Little (Arjuna), Bob Lojek (Intalio, Inc.), Anne Thomas Manes (Systinet), Jens Meinkoehn (T-Nova Deutsche Telekom Innovationsgesellschaft), Nilo Mitra (Ericsson), Don Mullen (TIBCO Software, Inc.), Himagiri Mukkamala (Sybase, Inc.), Joel Munter (Intel), Henrik Frystyk Nielsen (Microsoft Corporation), Duane Nickull (XML Global Technologies), David Noor (Rogue Wave Software), Srinivas Pandrangi (Ipedo), Kevin Perkins (Compaq), Fabio Riccardi (XQRL, Inc.), Don Robertson (Documentum), Darran Rolls (Waveset Technologies, Inc.), Krishna Sankar (Cisco Systems Inc), Jim Shur (Rogue Wave Software), Patrick Thompson (Rogue Wave Software), Steve Vinoski (IONA), Scott Vorthmann (TIBCO Software, Inc.), Jim Webber (Arjuna), Prasad Yendluri (webMethods, Inc.), Jin Yu (MartSoft Corp.) .