[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue - 90 - Proposal to vote
Dieter, There are a number of uses, many of which I think I can categorize as either deployment-specific information or just common data. For deployment-specific information, you may want to have an external file to define the endpoint references for the partner links that you invoke in your various BPEL scripts (if you do not rely on some other form of endpoint discovery, such as UDDI). In our case, we also have a number of client-specific data that change depending on where we deploy a certain business process. It makes a lot more sense to change in one file rather than modifying all the BPEL scripts. The latter case may of course be achieved by calling a web service to retrieve that information, but not the first case where the endpoint reference will be needed in order to make any calls. For common data, it just seems to me like an easy way to place common data in one place, such as initialization structures for the various variables in the BPEL that need initialization, such as reply variables/message types. Best regards, Kristofer -----Original Message----- From: Dieter Koenig1 [mailto:dieterkoenig@de.ibm.com] Sent: Monday, April 26, 2004 3:46 AM To: Kristofer Agren Cc: wsbpel@lists.oasis-open.org Subject: Re: [wsbpel] Issue - 90 - Proposal to vote Kristofer, the use case for having an external document that is part of the business process is not clear to me. Why is this not a literal residing inside of the process definition. In addition, such document references would create a new problem as I see no obvious way of recognizing changes of the external artifacts. Kind Regards DK "Kristofer Agren" <kagren@pakalert. com> To <wsbpel@lists.oasis-open.org> 23.04.2004 04:49 cc Subject [wsbpel] Issue - 90 - Proposal to vote Hello all, Here is a proposal to vote for issue 90 ( http://www.choreology.com/external/WS_BPEL_issues_list.html#Issue90): ----------------- Proposed solution: Introduce a new form of the <from> element: <from location="document-location" query="queryString"?/> The query attribute has the same semantics as the normal query attribute on the <from> element, i.e. it must be an absolute location path and select exactly one node. If no query is specified, the root node of the XML document is selected. The document-location is a URL (as defined in RFC 2396) that refers to an XML document, and in the case that the XML document is not valid and/or a single node cannot be returned, a selectionFailure fault should be thrown by a compliant implementation. The document that is retrieved from the URL is considered static in the same way the business process definition is considered static during execution. Furthermore, the external document is considered part of the business processes that reference it, and conversely, the business process definition should not be considered complete or valid without the external document. A change in the external document should be treated in the same way as a change in the business process definition. This <from> form can be used in conjunction with all the <to> forms. ----------------- Regards, Kristofer Agren
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]