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]