RE: [wsbpel] Issue - 90 - Assignment of external data into a variable

["Yaron Goland" <ygoland@bea.com>]

For me the crux of the issue is - is there a standard way to statically retrieve a file that will be portable across all BPEL implementations?

 

Given the failure of efforts of the last decade or so to come up with a standard file URL format my guess is that the answer is no.

 

Therefore any feature we provide to retrieve static files will, by definition, not be portable.

 

I think providing a feature in a spec that we know with a high degree of certainty won't be portable is almost an act of bad faith.

 

However....

 

Our import statement includes a location attribute that points to a static location. I realize that almost immediately someone is going to object and point out 'but wait, the true name of the import statement is the namespace and importType, the location is just a hint'.

 

The previous objection however presumes that each namespace/importType combination is universally unique and thus constitutes a proper location independent ID. But what would happen if, instead of importing a WSDL which includes (as opposed to imports) another WSDL (which by definition MUST be in the same namespace), I instead just import both WSDLs into BPEL? The same logic applies to schema. I can define two files that define the schema namespace so long as the contents of the files are mutual exclusive and/or dependent.

 

Unlike WSDL 2.0, for example, which discriminates between an import and an include, BPEL does not. Therefore one can have situations where the namespace/importType pair is not unique and the only possible way to disambiguate is to rely on the location.

 

It would therefore appear to me that if we are comfortable with import we should be comfortable with issue 90.

 

    Just a thought,

 

            Yaron

-----Original Message-----
From: Kristofer Agren [mailto:kagren@pakalert.com]
Sent: Monday, January 12, 2004 11:42 AM
To: 'Eckenfels. Bernd'; wsbpel@lists.oasis-open.org
Subject: RE: [wsbpel] Issue - 90 - Assignment of external data into a variable

Semantically, since the from-external source must be considered static, it does not matter when it is retrieved and thus the from-external source assign activity can be treated like any other activity. Since the external source is considered static, it is up to the implementation to decide when to do the actual retrieval, just like it is up to the implementation to decide when to actually load/parse the data that is found between the <from>literal</from> construct.

 

Kristofer

 

---

From: Eckenfels. Bernd [mailto:B.Eckenfels@seeburger.de]
Sent: Monday, January 12, 2004 12:52 PM
To: wsbpel@lists.oasis-open.org
Subject: RE: [wsbpel] Issue - 90 - Assignment of external data into a variable

 

Does this mean the from-external source is evaluated while the process definition is deployed, not while the assign is enabled? in that case it owuld make sence to put the assign actually in front of the initial activities. But I am quite oppsed to that. If somebody wants to include static data, he can do that by simple import or external entities, no need to define new semantics.

 

Mit freundlichen Grüßen
Bernd Eckenfels
Chief Architect
--
SEEBURGER AG - Edisonstr.1 , D-75015 Bretten, Germany
Fax: +49 (0)7252 96-2400 - Phone: +49 (0)7252 96-1256
mailto:b.eckenfels@seeburger.de - http://www.seeburger.de

-----Original Message-----
From: Kristofer Agren [mailto:kagren@pakalert.com]
Sent: Friday, January 09, 2004 8:49 PM
To: edwink@collaxa.com; 'Ron Ten-Hove'; wsbpel@lists.oasis-open.org
Subject: RE: [wsbpel] Issue - 90 - Assignment of external data into a variable

I would propose that the external content be treated just like the content that defines the BPEL process-static. If the content is to be considered dynamic, and thus not available for static analysis, then I agree with Ugo that it would be better to use a web service call for this. The external content would be part of the complete process definition, just like the BPEL file and any referenced WSDL files.

 

Kristofer

 

---

From: Edwin Khodabakchian [mailto:edwink@collaxa.com]
Sent: Friday, January 09, 2004 2:43 PM
To: 'Kristofer Agren'; 'Ron Ten-Hove'; wsbpel@lists.oasis-open.org
Subject: RE: [wsbpel] Issue - 90 - Assignment of external data into a variable

 

If the content served by the URI is dynamic and we can therefore not benefit from static analysis than this feature might be best implemented using a simple XPATH function. - Edwin

 

---

From: Kristofer Agren [mailto:kagren@pakalert.com]
Sent: Friday, January 09, 2004 10:51 AM
To: 'Ron Ten-Hove'; wsbpel@lists.oasis-open.org
Subject: RE: [wsbpel] Issue - 90 - Assignment of external data into a variable

 

Point taken; this is true for all but relative URI references, in which case I would treat it as part of the BPEL deployment package that would contain the .bpel, .wsdl and .xsd (if any) resources. My concern with modeling it as a service is that it will not be clear that the purpose of the call is to simply fetch static data.

 

Kristofer

 

---

From: Ron Ten-Hove [mailto:Ronald.Ten-Hove@Sun.COM]
Sent: Friday, January 09, 2004 12:50 PM
To: wsbpel@lists.oasis-open.org
Subject: Re: [wsbpel] Issue - 90 - Assignment of external data into a variable

 

    I worry about the use of direct references to files from within a BPEL process for several minor reasons, but one primary one: portability. The file cannot reasonably be at the same URI for every BPEL installation. Ugo's suggestion of modelling the file resource as a service is far more portable, since it wraps the inherently non-portable resource in a separate service that at the abstract level (that is, the BPEL view of services) is always the same.

Cheers,
-Ron

ws-bpel issues list editor wrote:

This issue has been added to the wsbpel issue list. The issues list is posted as a Technical Committee document to the OASIS WSBPEL TC pages on a regular basis. The current edition, as a TC document, is the most recent document with the title in the "Issues" folder of the WSBPEL TC document list - the next posting will include this issue. The list editor's working copy, which will normally include an issue when it is announced, is available at this constant URL.

Issue - 90 - Assignment of external data into a variable

Status: open
Date added: 9 Jan 2004
Submitter: Kristofer Agren
Date submitted: 09 January 2004
Document: BPEL specification
Description: The current assignment model allows for assigning literal data entered in directly under the <from> element. In practice, it may be desirable to have an external file/location where the data is maintained, which will allow for reuse if the same set of data is to be utilized in different business processes. The external file must be a valid XML document.
Submitter's proposal: I propose that this is solved by adding another form of the <form> element that can accept an external location uri and an optional query string:

<assign>

        <copy>

               <from location="uri" query="queryString"?/>

               <to.../>

        </copy>

</assign>

Changes: 9 Jan 2004 - new issue

---

To comment on this issue, please follow-up to this announcement on the wsbpel@lists.oasis-open.org list (replying to this message should automatically send your message to that list), or ensure the subject line as you send it starts "Issue - 90 - [anything]" or is a reply to such a message.

To add a new issue, see the issues procedures document (but the address for new issue submission is the sender of this announcement).

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_workgroup.php.