[no subject]

Kind Regards
DK



=20

             "Kristofer Agren"

             <kagren@pakalert.

             com>
To=20
                                       Dieter Koenig1/Germany/IBM@IBMDE

             26.04.2004 22:09
cc=20
                                       <wsbpel@lists.oasis-open.org>

=20
Subject=20
                                       RE: [wsbpel] Issue - 90 -
Proposal =20
                                       to vote

=20

=20

=20

=20

=20

=20





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

=20
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=3D"document-location" query=3D"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




To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgr
oup.php.