Internet DRAFT - draft-li-whole-lifecycle-model
draft-li-whole-lifecycle-model
LIFECYCLEMODEL Zengzhi. Li
Yanping. Chen
Internet Draft Xian Jiaotong University
Expires: January 2007 July 25, 2006
Whole life cycle model of composed Web services
draft-li-whole-lifecycle-model-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of
BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on January 19, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006). All Rights Reserved.
Abstract
Dynamic composing Web Services provides an efficient mechanism to
offer complex large systems. Substantial progress has already been
made towards composing Web Services. Unfortunately, these approaches
cannot build a model of the whole life cycle of composed Web Services.
In order to solve this problem, this draft designed a whole life cycle model
named Service-Cloud model based on the forming picture of clouds
in nature. Service-Cloud model can describe the whole life cycle of the
composed web Services: discovery, compose, publish, and terminate.
Zengzhi Expires January 19, 2007 [Page 1]
Internet-Draft lifecycle model July 2006
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [5].
Table of Contents
1. Introduction............................................ 2
2. A whole life cycle of composed Web Services............. 2
3. Acknowledgments......................................... 4
4. References.............................................. 5
Author's Addresses......................................... 5
Intellectual Property Statement ........................... 6
Disclaimer of Validity..................................... 6
Copyright Statement........................................ 6
Acknowledgment ............................................ 6
1. Introduction
Unanticipated dynamic Web Services composition has increasing
relevance in software today because of the constant change and
evolution of technologies, protocols, and standards. It can be a
very important mechanism for use in mission-critical, high availability,
and hard real-time E-commerce systems and anywhere else where there is
a need to perform unanticipated changes to software without discontinuing
its operation. Many e- and m-commerce systems fall into this category[1- 3].
Web services composition establishes on the Web Service architecture, and
it has become a key technology of enterprise level integration. The main
problem in Web service composition is how to flexibly compose the
existing, autonomy services into the enterprise level applications.
Alone with the development of Web service and correlated technologies,
enterprise level service composition step by step transits to Web
service composition which based on service oriented architecture. Then
how to realize flexible enterprise service composition based on SOA
becomes a problem urgent to be solved.
The real challenge in Web Services composition lies in how to provide a
complete solution [4]. This means to develop a tool that supports the entire
life cycle of service composition, i.e., discovery, consistency checking
and composition in terms of reuse and extendibility. This draft based on [6,7]
proposes a whole life cycle of composed Web Services.
2. A whole life cycle of composed Web Services
W3C provided a life cycle of Web Service [5], but dynamic composed
Web Services are more complex than use pre-existing Web Services
directly, and the courses of providing a composed Web Service are also
different of providing a pre-existing Web Service. So, here based on
the life cycle of Web Services in [5]. We present a whole life cycle of
composed Web Services.There are two separate transition paths in [5]:
service itself and request processing. A composed Web Service life cycle
is mainly deferent in request processing, and the first one is the same
as the expressions in [5]. A composed Web Service request processing
expressed in the state transition diagrams below.
*--------*
/| done | \
/ *--------* \
*--------* *--------*/ \
O ---->| getReq |---->| doReq |{ OR } { OR }O'
*--------* *--------*\ /
\ /
\ *--------*/
| failed |
*--------*
Figure 1. State Transition Diagram of Request Processing of A Composed
Web service
States:
getReq: the provider agent has accepted a request to provide a service.
doReq: the provider agent does some process to fulfill the requests.
done: the provider agent successfully completed the requests and
return the results to request agent.
failed: the provider agent encounter some errors and cannot fulfill the
request, and return errors to request agent.
Transitions:
A composed service starts getReq when it accepts a request.
A composed service starts execution after it received a request.
A composed service transitions to either done or failed state depending
on the outcome of the doReq stage.
A composed service exits doReq from either done or failed state (which are
mutually exclusive according to the previous transition).
Substrates transition diagram of doReq is given in figure 2.
*----------*
/->| compFail |
/ *----------*
*--------* *--------*/ { OR }
O ---->| doSea |---->| doComp | ----> *--------*
*--------* | *--------* | doChe |-----|\
| { OR } *--------* \
| | { OR } \
| *---------* | *--------* \
|-->| seaFail | | | doPub |<--|
*-----|---* |----| *--------*
| | | |
| | *--------* | |
| |->| cheFail| | |
| *--------* | |
| | |
|<------------------- | |
| |
| *--------* |
|<--| pubFail|<-----------|
O'<--------------------------| *--------*
Figure 2. Substate Transition Diagram of doReq
Zengzhi Expires January 19, 2007 [Page 2]
States:
doSea: the provider agent is doing searching to fulfill the requests.
doComp: the provider agent is doing composition to fulfill the requests.
doChe: the provider agent is doing checking to meet the requests.
doPub: the provider agent is doing publication for reuse.
seaFail: the provider agent encountered a searching error and didn't
complete the requested functions, returning a searching error to the
request agent.
compFail: the provider agent encountered a composing error and didn't
complete the composition, returning a composing error to the request
agent.
cheFail: the provider agent encountered a checking error and didn't
complete the requested functions, returning a checking error to the request
agent.
pubFail: the provider agent encountered a publishing error and didn't
complete the publication, returning a publishing error to the request
agent.
Transitions:
A composed service starts execution doSea after it accepts a request.
A composed service transitions to doComp, compFail, or doSea depending
on the outcome of the doSea stage.
A composed service transitions to either doChe or compFail depending
on the outcome of the doComp stage.
A composed service transitions to either doPub or cheFail depending on the
outcome of the doChe stage.
A composed service exists doReq from doPub, failed, or doSea state
which are mutually exclusive.
Zengzhi Expires January 19, 2007 [Page 3]
Internet-Draft lifecycle model July 2006
3. Acknowledgments
We would like to thank Chuang Wang for his comments and support of this
specification.
Zengzhi Expires January 19, 2007 [Page 4]
Internet-Draft lifecycle model July 2006
4. References
[1] Mennie, D., Pagurek, B.: An Architecture to Support Dynamic Composi-
tion of ServiceComponents. Presented at WCOP 2000 (Sophia Antipolis,
France, June 2000).Rosenberg, J., Schulzrinne, H., Camarillo, G.,
Johnston, A.,
[2] Tosic, V., Pagurek, B., Esfandiari, B., Patel, K. Management of
Compositions of E and M-Business Web Services with Multiple
Classes of Service", in Proc. of NOMS 2002.
[3] Tosic, V., Mennie, D., Pagurek, B. "On Dynamic Service Composition
and Its Applicability to E-Business Software Systems", in Proc.
of the WOOBS'01 2001.
[4] Jian Yang and Mike. P. Papazoglou, Web Component: A Substrate for Web
Service Reuse and Composition, in Procs of the 14th International
Conference on Advanced Information Systems Engineering (CAiSE02),
May, Toronto, Lecture Notes in Computer Science, Vol. 2348, p21-36,
Springer, 2002.
[5] Web Service Management: Service Life cycle.
http://www.w3.org/TR/2004/NOTE-wslc-20040211/.
[6] Chen Yanping, Li Zengzhi, Jin Qinxue. A Whole Life Cycle Model to Dynamic
Composed .Web Services. International conference on machine learning and
cybernetics (ICMLC¡¯05).
[7] Chen Yanping, Li Zengzhi, Jin Qinxue, Wang Chuang. Study on Life Cycle
Model of Dynamic Composed Web Services. The 6th International Conference on
Algorithms and Architectures for Parallel. LNCS Volume 3719 / 2005.
Author's Addresses
Zengzhi Li
Department of computer science,
Xi'an Jiaotong University£¬ No.29 Xianning West Rd.
Xian ShaanXi, P.R. of China
Phone: +86 29 82668642 8001
Email: lzz@mail.xjtu.edu.cn
Yanping Chen
Department of computer science,
Xi'an Jiaotong University£¬ No.29 Xianning West Rd.
Xian ShaanXi, P.R. of China
Phone: +86 29 82668642 8005
Email: cyp.xjtu@gmail.com
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
Zengzhi Expires January 19, 2007 [Page 5]
Internet-Draft lifecycle model July 2006
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Zengzhi Expires January 19, 2007 [Page 6]
