[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Issue - 2 - subfunctions inside or outside of files
Chris's response to my e-mail brought up the issue of - should subfunctions (or as Chris calls them, subprocesses) be defined only external to a BPEL file or both inside of a BPEL file and in an external file? There are two reasons why I think we should allow subfunctions to be defined both inside of a BPEL file as well as outside of it: Visibility - As I will demonstrate in the example below allowing subfunctions to be defined inside of a BPEL allows for the use of BPEL's scoping rules so it is possible to make a subfunction declaration truly private. This is a feature that every language ends up adding at one point or another so I figure we should just get ahead of the curve. Organization - I find that when it comes to files my customers fall into two broad camps. You have the proliferators who can never get enough files. These are people who would define every method in every class in a separate file if they could. Then you have the compactors, these are people who hate file proliferation and want to put as much as possible into a single file. By allowing subfunctions to be defined both inside and outside of the BPEL file we can make both groups happy with little added complexity beyond that already required to deal with visibility. I propose that the way we import subfunction definitions is by using the import feature implemented as a consequence of Issue 7. I think we should define a new importType I will call http://www.oasis.com/2003/wsbpeltc/subfunctionimport. Imported subfunctions MUST be contained in a subfunction file. This is an XML file whose root element is subfunctiondeclaration and whose contents are subfunction elements. An example is given below. When importing a subfunction file all the subfunctions declared in that file are treated as if they were copied into the global scope of the process that made the import. The example below consists of two files. There is a subfunction file that defines two functions, e1 and e2. Only e1 will be used in the example, I only include e2 just to drive home the point that a subfunction file can contain an arbitrary number of subfunctions. There is also a BPEL process file which imports the subfunction file. Inside of the BPEL process file is a scope and in that scope a subfunction also called e1 is defined. The point is to show that name visibility rules apply so that if e1 is called from inside of the scope then it will be the e1 defined in the scope but if e1 is called from outside of the scope then it will be the e1 imported into the global scope. <subfunctiondeclaration name="eFunctions" xmlns="http://www.oasis.com/2003/wsbpeltc/subfunctiondeclaration"> <subfunction name="e1"> ... </subfunction> <subfunction name="e2"> ... </subfunction> <subfunctiondeclaration> 1 <process> 2 <bpel:import location="eFunctions" importType="http://www.oasis.com/2003/wsbpeltc/subfunctionimport"/> 3 ... 4 <sequence> 5 <scope> 6 <subfunction name="e1"> 7 ... 8 </subfunction> 9 <function functionName="e1"/> 10 </scope> 11 <function functionName="e1"/> 12 </sequence> 13 </process> The function call in line 9 will call the function defined in line 6. The function call in line 11 will call the function defined in the eFunctions file that was imported in line 2.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]