Web Service Management: Service Life Cycle

W3C Working Group Note 11 February 2004

This version:: http://www.w3.org/TR/2004/NOTE-wslc-20040211/
Latest version:: http://www.w3.org/TR/wslc/
Editors:: Hao He, The Thomson Corporation; Mark Potts, Talking Blocks, Inc.; Igor Sedukhin, Computer Associates

Abstract

This document describes the life cycle of a Web service, and of the processing of a request by a Web service.

Status of this Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This is a public W3C Working Group Note produced by the Web Services Architecture Working Group, which is part of the Web Services Activity.

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.

Discussion of this document is invited on the public mailing list www-ws-arch@w3.org (public archives).

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

Publication as a Working Group Note does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress. Other documents may supersede this document.

Service Life Cycle

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

The terminology used is the one defined in the Web Services Glossary.

Service

To be used, a service must be realized by a concrete provider agent.

Life cycle of a service

States

UP (compound) — the provider agent is capable of accepting and processing requests (i.e. the service is available).
DOWN (compound) — the provider agent is not capable of accepting any requests (i.e. the service is not available).

Transitions

Start of Life (SOL) — the service starts its life in UP state.
End of Life (EOL) — the service ends its life from DOWN state.
Activate — the service can become available which transitions it from DOWN to UP state.
Passivate — the 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

Up substrates

States

IDLE — the provider agent is not processing any requests currently.
BUSY — the provider agent 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

Down substrates

States

STOPPED — the service was intentionally stopped (e.g. for administrative purposes).
SATURATED — the provider agent has exhausted its resources and cannot accept any new requests.
CRASHED — the service is unavailable because of an internal malfunction of the provider agent(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

Life cycle of a request processing

States

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

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 was authored by 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).

This document is a product of the Web Services Architecture Working Group.

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), 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 Softwar.e, 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), Mark Potts (Talking Blocks, Inc), 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.) .