[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 2- requirements for a sub function solution
The first time I read the BPEL4WS 1.0 spec, one of my strongest reactions was "where are the subprocesses?" Over a year later, one revision of the spec, and countless re-readings, and my initial reaction is unchanged. Modelling subprocesses as separate web services is an unsatisfactory substitute. This creates unreadable processes, with, as you observed today, really messy <assign> activities used to pack and unpack requests and responses. Not only are the assignments ugly, cluttering the process, but the dedicated BPEL reader will be faced with
Assuming that we can agree that sub-functions, as you have defined them, can be used as a simple form of sub-process, then we may be able to converge on a satisfactory solution. The rest of my comments are in-line: Yaron Goland wrote: I would add that sub-functions must integrate into the host's serializable scopes, when shared variables are passed by reference to the sub-function.Here is my view on what the requirements are for a solution to Issue 2. Terminology: Host - This is the process that called the sub-function. Requirements: Integration into host fault/compensation model - The sub-function MUST be able to throw faults that will propagate to the host. The host MUST be able to call compensation handlers defined in the sub-function. I believe we established this as a requirement for BPEL very early on, in the debate over whether <sequence> was necessary.Functional Programming - One of the key concepts of functional programming is the idea of isolation. Functions in functional programming systems are expected to be able to run in their own context and to only have contact with the host context through explicit value passing. The sub-function solution MUST enable for isolation. Human Usable - It MUST be reasonably easy for a programmer to read/write sub-function definitions and calls without requiring the aid of a tool. While passing by reference has good, pragmatic foundations in managing the impact of those ever-growing XML payloads, I believe another line of argument would support the need for clear, controllable parameter passing to the subfunction, such that the process author can clearly control and understand how data are passed to and from the sub-function.By Reference - Messages seem only to get larger with multi-megabyte XML messages now commonly seen. Therefore when passing data into a sub-function it is critical that it be possible to hand over the data by reference so that the data does not have to be copied on its way in or out. That is an interesting idea. Such sub-functions would need to have restricted "signatures" to map to XPath functions; also, isn't XPath supposed to always be side-effect free? That would imply that all input variables of the sub-function must be read-only; a single output variable would be nominated as the function result.Use in Expressions - It MUST be possible to call a sub-function anywhere one could call a XPATH or other type of general/query/date expression and have the sub-function return the desired value. Agreed.Import - A mechanism is needed to allow sub-functions to be defined in stand alone files which can then be referenced by multiple BPEL processes. -Ron |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]