Method and apparatus for manipulating data during automated data processing6757888Abstract A number of items of data from a data source (12) can be processed and then deposited in at least one data destination (16, 17). The data can be image data, text data, numeric data or some other type of data, or a combination of these types of data. Processing of the data is controlled by a project definition (14, 71, 101) which includes a plurality of modules selected from a variety of available modules (Tables 1-4). The modules have input and output ports that are interrelated by binding information. Some of the modules are capable of taking an item of data and splitting it into two or more component parts. Other modules are capable of taking separate items of data and combining them. Claims What is claimed is: Description TECHNICAL FIELD OF THE INVENTION
TABLE 1
SOURCE DEFINITIONS
DATABASE ACCESS
Uses a database table or query to identify data to
process. Unless processing strings, one field in the
table must contain a string with a complete path to the
image data. May optionally select one or more
additional fields that will be output separately (for
binding by subsequent functions). The database table
or query must already exist and be defined as an ODBC
(Open DataBase Connectivity) connection prior to using
this function.
Variable Name Port Type Description
ImageOut Output emImage Image data.
Specified Field Output emString Each selected field
is converted to
string output, and
retains field name.
FILE BROWSER
Adds one file at a time to a list of images to process.
The resulting list is saved, and is subsequently used
during execution to automatically retrieve the
specified images in sequence.
Variable Name Port Type Description
ImageOut Output emImage Image data.
INTERNET FILES
Collects all of the image files from a specified URL
(Universal Resource Locator) address. Optionally, the
function will continue to other pages to which the
specified site is linked (from one to five levels, as
specified by the Depth setting). By default, it only
follows links within the same domain name, but this can
optionally be disabled.
Variable Name Port Type Description
ImageOut Output emImage Image data.
LOCAL FILES
Indicates a folder or a virtual path to where images to
be processed are stored. Can select whether or not
subfolders (subdirectories) of the indicated folder
will be accessed.
Variable Name Port Type Description
ImageOut Output emImage Image data.
AltText Output emString Alternate text of
the image on that
page.
In FIG. 1, the modules within the project definition 14 are each shown as a rectangular box with a respective label of "source", "branch", "action", or "destination". Alternatively, however, within the scope of the present invention, these module types may each be visually represented by a respective icon. For example, FIGS. 2-5 show icons respectively representing a source module, a branch module, an action module, and a destination module. The particular icons shown in FIGS. 2-5 are exemplary icons used in the disclosed embodiments, and it will be recognized that a variety of other icons could alternatively be used. FIG. 6 is a block diagram of a very simple project definition 71, which will be used to demonstrate the format in which project definitions are stored for purposes of the disclosed embodiments of the present invention. The project definition 71 includes one source module 72, and two action modules 73 and 74. The binding lines for image data are indicated at 77 and 78, and a binding line for string data is indicated at 79. In order to keep the example simple, the project definition 71 does not include any branching or destination modules. It can be considered to be a project definition which is in the process of being created, but is not yet complete. In the project definition 71, the source module 72 is a Database Access module. This particular Database Access module obtains image data by effecting a predefined query to a table in a database, and by obtaining from respective fields in each record of the table a first string which defines the path to the actual location of a file containing a respective image, and a second string which represents a corresponding price. The Database Access module 72 then uses each first string to retrieve the corresponding image, which is output at 77, while outputting at 79 for each image the corresponding second string which represents a price. Thus, the module 72 successively outputs a number of images and associated prices. The action module 73 is a Fill module, which adds color to an active object of the image, and then outputs at 78 the modified image data. The action module 74 is a Text Stamper module, which superimposes onto the image data received at 78 the text string received at 79. As noted above, this text string represents a price. The text will be added as a new and further object in the image data, which thereafter becomes the active object. The project definition 71 of FIG. 6 can be represented visually in other ways. For example, FIG. 7 is a diagrammatic view showing the same project definition 71, but with a different visual appearance. In FIG. 7, there are three pipe sections 82-84 arranged end-to-end, so as to collectively give the appearance of a pipeline through which image data and/or other data can flow. The pipe section 82 represents the Database Access module, the pipe section 83 represents the Fill module, and the pipe section 84 represents the Text Stamper module. With respect to the binding lines 77-78 in FIG. 6, which represent image data, there are no corresponding binding lines in FIG. 7, because the end-to-end relationship of the pipe sections is representative of the flow of image data from module to module. With respect to the binding line 79 of FIG. 6, which represents text string data, it has been arbitrarily omitted in FIG. 7, in order to emphasize that this type of binding line can optionally be included or excluded from a view such as that shown in FIG. 7. Where the binding line is excluded, the text string data may be considered to be flowing through the pipeline with the image data. The modules 82-84 of FIG. 7 each have in the middle thereof an icon which is different from the icons shown in FIGS. 2, 4 and 6, in order to make the point that the invention permits the use of various different icons. One feature of the present invention is that each project definition, such as those shown at 14 and 71 in FIGS. 1 and 6, is stored in a form which is expressed in a public communication protocol. The public communication protocol used in the disclosed embodiments is the extensible Markup Language (XML) protocol, which is well known in the industry. However, some other public communication protocol could alternatively be used. Referring to TABLE 5, the right column shows how the project definition 71 of FIG. 6 would be expressed in the XML protocol, according to the disclosed embodiments of the invention. For convenience, various levels of indentation have been provided in order to make the XML information more readable, but the indentation is not intended to suggest that the actual XML file includes characters to effect such indentation. The line numbers presented in the left column of TABLE 5 are not part of the XML expression of the project definition, but instead have been added to sequentially number the lines of the XML definition, in order to facilitate an explanation of the XML information, which is set forth below. For readability and convenience, some single lines of the XML file are shown as two or more lines in TABLE 5, and the line numbers added in the left column help show where this has occurred. Much of TABLE 5 is believed to be generally self-explanatory. Accordingly, the following discussion does not address every line in TABLE 5, but instead offers comments regarding only selected lines, as appropriate. In this regard, line 1 shows that the project definition 71 has been arbitrarily given the name "Project Name". Line 2 refers to a group name, but the concept of groups has been included for a future purpose which is not relevant to an understanding of the present invention, and groups are therefore not discussed here. Line 3 indicates that the process name has arbitrarily been set to be "First Process". In an XML definition of the type shown in FIG. 5, one process is defined first in its entirety, and then any other processes are each defined in their entirety, in a sequence. Within each process, the sub-processes are defined in sequence, with the main process being defined first in its entirety, after which the sub-processes (if any) are each being defined in their entirety, in sequence. In the simple project definition 71 shown in FIG. 6, of course, the project definition includes only one process, which in turn includes only one sub-process, namely the main process. Line 4 of TABLE 5 identifies the beginning of a module list, which is a sequential listing of all modules in the main process portion of the process. As shown in FIG. 6, the main process of the project definition 71 has only the three modules 72-74. The Database Access module 72 is defined in lines 5-30 of TABLE 5, the Fill module 73 is defined in lines 31-43 of TABLE 5, and the Text Stamper module 74 is defined in lines 44-108 of TABLE 5. Line 109 identifies the end of the modules for the main process. Line 110 is a heading which identifies where other sub-processes would be defined, if this process included any sub-processes other than the main process. Line 111 identifies the end of the first process. Lines 112-115 are headers which identify where one or more other processes of the project definition would be defined, if the project definition included more than one process. Lines 116-117 of TABLE 5 identify the end of the project definition. Turning in more detail to lines 5-30 of TABLE 5, which define the Database Access module 72, line 5 includes an "Id" of "com.image2web.databaseaccess" which, in the disclosed embodiments, is an internal code identifying a segment of object code that implements the functionality of the Database Access module. The next portion of line 5 refers to an "Instance", which in this example is set to the numeral "1". This indicates that this is the first occurrence of the Database Access type of module in the project definition 71. If the project definition 71 included two or more Database Access modules, they would be respectively identified by successive integer instance numbers, corresponding to the order in which they appear in the XML file. Lines 13-14 in TABLE 5 identify the database which should be accessed in order to retrieve image data, which in this case is a database named "photography". As noted in the explanation in TABLE 1 of the Database Access definition, the connection for this database must already exist and be defined as an Open DataBase Connectivity (ODBC) connection. This permits the Database Access module to easily interact with pre-existing databases through the use of public communication protocols, without any need to make any change to the databases. In the specific example of TABLE 5, the word "photography" in line 14 provides a unique link to an existing ODBC connection, which in turn provides the link to and query for the specified database. Lines 10-12 of TABLE 5 define the particular table within the database which is to be accessed. In this particular example, the "photography" database has several tables which are each named after a respective photographer, and that each relate to photographs taken by that particular photographer. Each table has a name which corresponds to the name of the associated photographer, which in this example is "Robert Shutterbug". Lines 7-9 and lines 20-22 of TABLE 5 each define a respective field within the indicated table, the contents of which are to be obtained by and output from the Database Access module 72. Lines 25-29 of TABLE 5 define the various output ports of the Database Access module 72. In particular, line 28 defines an output port for the image data, which is associated with the binding line 77 in FIG. 6. Line 28 in TABLE 5 defines an output port for a string which represents a price, and which is associated with binding line 79 in FIG. 6. Line 27 defines an output port for the filename of the image, but this output port is not used in FIG. 6. Turning to the Fill module 73, line 38 in TABLE 5 defines an input port for image data, and includes a term "BoundTo", which effectively defines the binding line 77 of FIG. 6, by identifying the output port of the module 72 to which the input port of the module 73 is bound. Turning to the Text Stamper module 74 of FIG. 6, its definition in TABLE 5 appears at lines 44-108. Within this definition, lines 46-99 define a number of parameters, which are collectively referred to herein as control information, and which may be specified by a user in order to define the particular operational characteristics which this particular instance of the Text Stamper module is to have. For example, to the extent that the Text Stamper module 74 is superimposing onto an image some text which represents a price, the parameters define characteristics of that text, such as its location, font, size, color, and so forth. Line 103 of TABLE 5 defines the input port of the text stamper module at which it receives the image data, and includes a "BoundTo" term which defines its association with an output port of the Fill module 73. In other words, the "BoundTo" term defines the binding line 78 of FIG. 6. Similarly, line 102 of TABLE 5 defines for the Text Stamper module 74 an input port for text, which in this case represents a price. Line 102 also includes a "BoundTo" term which defines the association of this input port with an output port of the data access module 72, or in other words the binding line 79.
TABLE 5
PROJECT DEFINITION IN XML
1 <Project Name="Project Name" Desc=" "
Version="1.0">
2 <Group Name="Project Name" Desc=" ">
3 <Process Name="First Process" Desc=" ">
4 <ModuleList>
5 <Module Name="Database_Access"
Id="com.image2web.databaseaccess"
Instance="1">
6 <Properties>
7 <Property Name="Output-ImageFilename"
DataType="emVariant">
8 <Value>ImageFilename</Value>
9 </Property>
10 <Property Name="Table"
DataType="emVariant">
11 <Value>Robert
Shutterbug</Value>
12 </Property>
13 <Property Name="DSN"
DataType="emVariant">
14 <Value>photography</Value>
15 </Property>
16 <Property Name="Input-Field"
DataType="emVariant">
17 <Desc>Image Path</Desc>
18 <Value>ImageFilename</Value>
19 </Property>
20 <Property Name="Output-Price"
DataType="emVariant">
21 <Value>Price</Value>
22 </Property>
23 </Properties>
24 <Inputs/>
25 <Outputs>
26 <Property Name="Price"
DataType="emVariant"/>
27 <Property Name="ImageFilename"
DataType="emVariant"/>
28 <Property Name="ImageOut"
DataType="emImage"/>
29 </Outputs>
30 </Module>
31 <Module Name="Fill"
Id="com.image2web.fill" Instance="1">
32 <Properties>
33 <Property Name="FillColor"
DataType="emVariant">
34 <Value>1973978</Value>
35 </Property>
36 </Properties>
37 <Inputs>
38 <Property Name="ImageIn"
DataType="emImage"
BoundTo="com.image2web.database
access.1.Output.ImageOut"/>
39 </Inputs>
40 <Outputs>
41 <Property Name="ImageOut"
DataType="emImage"/>
42 </Outputs>
43 </Module>
44 <Module Name="Text_Stamper"
Id="com.image2web.textstamper"
Instance="1">
45 <Properties>
46 <Property Name="PageColor"
DataType="emVariant">
47 <Value>16777215</Value>
48 </Property>
49 <Property Name="LiteralXPosition"
DataType="emVariant">
50 <Value>0</Value>
51 </Property>
52 <Property Name="Bold"
DataType="emVariant">
53 <Value>0</Value>
54 </Property>
55 <Property Name="Transparency"
DataType="emVariant">
56 <Value>100</Value>
57 </Property>
58 <Property Name="FontSize"
DataType="emVariant">
59 <Value>24</Value>
60 </Property>
61 <Property Name="Bound"
DataType="emVariant">
62 <Value>-1</Value>
63 </Property>
64 <Property Name="BorderText"
DataType="emVariant">
65 <Value>0</Value>
66 </Property>
67 <Property Name="MergeMode"
DataType="emVariant">
68 <Value>Normal</Value>
69 </Property>
70 <Property Name="Underline"
DataType="emVariant">
71 <Value>0</Value>
72 </Property>
73 <Property Name="BoundName"
DataType="emVariant">
74 <Value>Price</Value>
75 </Property>
76 <Property Name="ExpandToFit"
DataType="emVariant">
77 <Value>-1</Value>
78 </Property>
79 <Property Name="Color"
DataType="emVariant">
80 <Value>0</Value>
81 </Property>
82 <Property Name="TextPosition"
DataType="emVariant">
83 <Value>CenterCenter</Value>
84 </Property>
85 <Property Name="LiteralYPosition"
DataType="emVariant">
86 <Value>0</Value>
87 </Property>
88 <Property Name="Angle"
DataType="emVariant">
89 <Value>0</Value>
90 </Property>
91 <Property Name="Font"
DataType="emVariant">
92 <Value>Arial</Value>
93 </Property>
94 <Property Name="UseLiteralPosition"
DataType="emVariant">
95 <Value>0</Value>
96 </Property>
97 <Property Name="Italic"
DataType="emVariant">
98 <Value>0</Value>
99 </Property>
100 </Properties>
101 <Inputs>
102 <Property Name="TextLine"
DataType="emVariant"
BoundTo="com.image2web.database
access.1.Output.ImageFilename"/>
103 <Property Name="ImageIn"
DataType="emImage"
BoundTo="com.image2web.fill.1.
Output.ImageOut"/>
104 </Inputs>
105 <Outputs/>
106 <Property Name="ImageOut"
DataType="emImage"/>
107 </Outputs>
108 </Module>
109 </ModuleList>
110 <SubProcessList/>
111 </Process>
112 <Process Name="Second Process" Desc=" ">
113 <ModuleList/>
114 <SubProcessList/>
115 </Process>
116 </Group>
117 </Project>
The project definitions discussed above in association with FIGS. 1 and 6-7 are relatively simple. FIG. 8 is a diagrammatic view of a further project definition 101, which is more sophisticated. It includes a single process which is shown in its entirety in FIG. 8, and which includes three sub-processes 102-104, namely a main process 102, and two further sub-processes 103 and 104. It also includes a feature which has not previously been discussed, which is a global portion 107 having a plurality of global ports 111-114. The ports 111-114 of the global portion 107 can be accessed by modules within the main process 102 or by modules within either of the sub-processes 103-104. The ports 111-114 can each act as an input port and/or an output port, depending on the particular operational configuration. More specifically, the ports 111-114 can each act as a form of register or memory location, in which one module can store information, and from which another module can later read it. The data in the port can thus change dynamically during project execution. The port 112 in FIG. 8 is configured to operate in this manner, and thus acts as both an input port and an output port. Further, the ports 111-114 can each be initialized to a predetermined value. If no module changes the initial value stored in that port, then that initial value serves as a form of data constant which does not change, and which can be accessed by any module throughout execution of the project definition. In FIG. 8, the port 114 is configured to act in this manner, and thus acts as an output port. In more detail, the port 114 is initialized to a string value which is superimposed onto images, as explained later. If, in addition to the process defined by the main process 102 and the sub-processes 103-104, the project definition 101 included an additional process, then each process would have its own global portion 107. The ports of each global portion 107 would be global to the associated process, but not the other process. In addition to the two global portions 107, a further global portion would appear in FIG. 8 adjacent the global portion 107. The ports of the further global portion would be global to both processes, or in other words the entire project definition. The ports of the further global portion could be referred to as project level ports, and the ports of each of the global portions 107 could be referred to as process level ports. The various types of modules which make up the project definition 101 of FIG. 8 are each described in TABLES 1-4. However, for purposes of clarity and completeness, each is also briefly discussed below. More specifically, the main process 102 includes a Database Access module 121, which obtains and outputs a plurality of successive images from a not-illustrated database, in a manner similar to that discussed above in association with the Database Access module 72 of FIG. 6. These images are supplied at 122 to an Image Info module 126. The Image Info module 126 does not change the image data, but does output certain information about the image data, including the height of the image at 127 and the width of the image at 128. The height and width are each output in the form of a string representation of a numeric value which is the number of pixels in the height or width. The height is supplied at 127 to the port 112 of the global portion 107, and is saved there for later use. The width is output at 128. The binding line 128 is a special type of binding line known as a conditional binding, which is explained later. The module 126 outputs the unchanged image data at 129, where it flows to a Send Email module 131. The module 131 does not change the image data, but sends an email (electronic mail message) in response to the occurrence of a predefined condition, where the email is a predefined text message that is sent to a predefined email address. In the Send Email module 131 of the project definition 101, the condition that causes the module 131 to send an email is met when the last image produced by the Database Access module 121 is being processed. There are various ways in which this could be detected, for example by counting images if the number of images to be processed is known in advance, or by detecting a predetermined file name assigned to the last image. Alternatively, as a process completes, an "execution finished" message could be provided to all modules of the process, or at least to each Send Email module in the process, thereby causing each Send Email module to proceed to send its email. The text of the email might notify a person that all of the image data in question has been processed by the project definition 101, and is available for use. The unchanged image data from the module 131 flows at 132 to a String Builder module 136, which does not change the image data. As explained in TABLE 3, the String Builder module 136 can generate a sequence of names, where each name in the sequence is generated when a respective one of the images passes through the module 136. In the project definition 101, the module 136 is configured to generate a sequence of names which are "Image01" "Image02", "Image03", and so forth. These sequential names are successively supplied through an output port of the String Builder module 136, which is associated with a binding line 137. The unchanged image data from the Stringer Builder module 136 flows at 138 to a File Size module 141. The module 141 does not change the image data. It outputs the image data at either 142 or 143, depending on the size of the file which contains the image data, in a manner already discussed above. Image data that is output at 143 flows to the sub-process 103, as discussed later. Image data that is output at 142 flows to an Interactive module 146 of the main process 102. The Interactive module 146 does not change the image data. It does pause execution of the project definition 101, while requesting that a person manually specify where the current image is to be sent. In particular, the person can specify that the current image is to be sent at 148 to the sub-process 104, or that the image can continue at 147 along the main process 102. In view of the fact that the Interactive module 147 has the effect of pausing execution for each image processed by the project definition 101, and in view of the fact that an important application of the present invention is automated processing of data, modules of the Interactive type would typically be omitted from most project definitions. However, the Interactive module 146 has been included in the exemplary project definition 101 of FIG. 8 in order to facilitate a better understanding of this feature of the present invention. With reference to TABLE 2, and as discussed in more detail later, the Interactive module 146 provides a user with the capability to manually and interactively specify whether data is to be directed to 147 or 148. In addition, it provides the user with the capability to specify that the Interactive module 146 should automatically take a specified action for all subsequent images which are processed during the current execution of the project definition 101. Assuming that, in response to a query from the Interactive module 146, a person indicates that image data from the module 146 is to continue along the main process 102, the module 146 causes the unchanged image data to flow at 147 to a Text Stamper module 151. The Text Stamper module 151 has an additional input port, which is associated by the binding line 128 with the image width output from the Image Info module 126, and also with the port 112 of the global portion 107. As mentioned above, the binding line 128 is a conditional binding. This means that the binding 128 can selectively supply data to the input port of the Text Stamper module 151 from either of two different output ports, which in FIG. 8 are the image width output of the module 126, and the port 112 of the global portion 107. Conceptually, the condition should be viewed as an internal part of the binding 128 itself, rather than as a part of the global portion 107, the module 126, or the module 151. Considered this way, it will be recognized that the condition can be based on data which is available to the binding 128 from either of the associated output ports, which in FIG. 8 include the image height information and image width information that it respectively receives from the output ports of the global portion 107 and the module 126. For example, the condition might be set to specify that the binding 128 is to compare the height and width values, and to supply the larger of the two values to the Text Stamper module 151. The Text Stamper module 151 takes the height or width value received from the conditional binding 128, and superimposes it on the image received at 147. The height or width information becomes a separate object which is part of the overall image data. All of the objects of the image data-are supplied at 152 to a File Namer module 156. The module 156 associates with the image data a file name, under which the image data will eventually be stored. For this purpose, the File Namer module 156 has an input port coupled through the binding 137 to module 136. As discussed above, the module 136 generates a unique sequenced name as each respective image is processed. Accordingly, module 156 associates the unique name from binding 137 with the image currently passing through the module 156, and then forwards the image data and newly associated name at 157 to a Destination Folder module 161. Aside from associating a name with the image data, the file namer module 156 does not change the image data itself. The Destination Folder module 161 defines the name of a folder or subdirectory into which images processed by the main process 102 are to be deposited. In essence, the File Namer module 156 associates with the image data a file name, and the Destination Folder module 161 associates with the image data a path to a subdirectory. The module 161 does not change the image data itself. The image data with its associated information is supplied at 162 to a File Saver module 166. The File Saver module 166 is responsible for actually saving the data, and can also specify which of several common image formats the image data is to be saved in. The File Saver module 166 saves the image data in the folder or subdirectory specified by module 161, under the file name specified by module 156, and in the format specified by the File Saver module 166 itself. The File Saver module 166 is configured to save the data locally with respect to the computer which is executing the project definition 101, for example within the context of an intranet or LAN, but not to a remote location that can only be accessed through a non-local network such as the Internet. Returning to the File Size module 141, it was explained above that, depending on file size, certain images would be routed at 143 to the sub-process 103. In particular, these images will be routed to an input port of a Text Stamper module 168. The module 168 superimposes on each such image a non-changing text string, which it obtains through an input port from the output port 114 of the global portion 107. This superimposed text is added to the image data in the form of an additional object, which becomes a part of the image data. All of the objects of the image data are supplied at 169 to a File Namer module 171. The File Namer module 171 operates in the same manner as described above for the File Namer module 156, and then supplies the image data and associated information at 172 to a Destination Folder module 176. The module 172 operates in the same manner as the Destination Folder module 161, except that it uses a different name for the destination folder. The image data and associated information are then supplied at 177 to an FTP Save module 181. The FTP Save module 181 uses the File Transfer Protocol (FTP) to transfer the processed image data and associated information through a network to a specified destination, where it is saved in a folder having the name specified by the Destination Folder module 176, under a name specified by the File Namer 171, and in a format specified by the FTP Save module 181. The module 181 is capable of saving data to a remote location, for example through the Internet. Returning to the Interactive module 146, it was explained above that a user can selectively specify that a current image is to continue at 147 along the main process 102, or is to be routed at 148 to the sub-process 104. In the sub-process 104, this image is received at an input port of an External Action module 186. The module 186 is designed to cooperate with a separately and independently executing application program, which in the disclosed embodiments is an image processing program, such as the program that is commercially available under the tradename PHOTOSHOP from Adobe Systems Incorporated of San Jose, Calif. It is to be understood that this separate application program is operative only when accessed through an External Action module. Thus, for example, where this application program is an image processing program, it only performs image processing functions initiated through an External Action module. The image processing functions implemented by other modules are implemented by other software, as discussed in more detail later. The External Action module 186 includes a command which was specified by the person who created the project definition 101, and which is a command that the separate image processing program is capable of executing. The module 186 supplies the current image and also the command to the image processing program, which then executes the command while processing the image in the manner specified by the command. The image processing program then returns the processed image to the External Action module 186, which supplies the processed image at 187 to a File Namer module 191. The File Namer module 191 operates in the same manner as described above for the modules 156 and 171, and then outputs image data and an associated name at 192 to a Database Output module 196. The Database Output module 196 operates in a manner similar to the Database Access module 121, except that it saves data rather than reading data. The data is saved under the file name specified by module 191. FIG. 9 is a block diagram of a system 201 which implements the present invention. The configuration of the system 201 is exemplary, and a wide variety of changes could be made to this system while maintaining compatibility with implementation of the present invention. The system 201 includes an intranet 206, such as a local area network (LAN), which is coupled through a "Web" server 207 to a wide area network (WAN), such as the Internet 208. The intranet 206 is coupled to a workstation 211, a process server 212, a file server 216, an auxiliary server 217, and three imaging servers 221-223. The Internet 208 is coupled to a workstation 226, a database 227, a File Transfer Protocol (FTP) site 231, and an enterprise resource management (ERM) program 232. The ERM program provides support in areas such as human resources and financial matters. The ERM program 232 may, for example, be the program commercially available under the tradename PEOPLESOFT from PeopleSoft, Inc. of Pleasanton, Calif. It will be recognized that the devices coupled to the Internet 208 in FIG. 9 could alternatively be coupled to the intranet 206, and that the devices coupled to the intranet 206 could alternatively be coupled to the Internet 208. The computers and related hardware shown in FIG. 9 are all of a type known in the art. For purposes of explaining the present invention, the following discussion will focus on the manner in which these known hardware components are configured into a system , and the various software programs which are executed by the various computers of FIG. 9. The file server 216 can receive data files from portable media such as a standard floppy disk 236, or a standard compact disk 237, and can store this data at 238, for example in a hard disk drive. Conversely, some or all of the data stored at 238 can be offloaded onto a floppy disk 236 and/or a read/write compact disk 237. The data stored on the floppy disk 236 or the compact disk 237 will typically be in a compressed format, which conforms to an industry-standard compression technique. Consequently, the file server 216 has the capability to uncompress data that is read from the floppy disk 236 or the compact disk 237, before that data is stored at 238. Similarly, the file server 216 has the capability to compress data obtained from 238 before writing it to the floppy disk 236 or the compact disk 237. The imaging servers 221-223 are all effectively identical, and therefore only the imaging server 221 is illustrated and described here in detail. The imaging server 221 includes a processor 241 and a memory 242. The processor 241 runs an operating system 246, which in the disclosed embodiments is one of the versions of an operating system that is commercially available under the tradename WINDOWS from Microsoft Corporation of Redmond, Washington. However, it could be some other operating system. Running on the operating system 246 within the processor 241 is a program which is an imaging server module 247. The memory 242 stores two tasks 251 and 252, which each include a project definition 256, selected executables 257, and data 258. With respect to the imaging server 221, as well as other servers and workstations discussed later, it will be recognized that the dividing line between what is in the processor in FIG. 9 and what is in the memory has been drawn somewhat arbitrarily. For example, programs such as the operating system 246 and the imaging server module 247 are each depicted in the processor, but also use a certain amount of the memory 242. Conversely, the memory 242 is depicted as containing some executable code at 257, but the actual execution of this code will ultimately occur within the processor 241. Nevertheless, it is believed that those skilled in the art will readily comprehend these distinctions, and the breakdown shown in FIG. 9 has been selected to facilitate a clear understanding of the present invention. In the imaging server 221, the imaging server module 247 executes project definitions of the type discussed above with respect to FIGS. 1 and 6-8. In particular, it obtains data through the intranet 206 and/or the Internet 208, processes the data in the manner specified by the project definition, and then deposits the processed data to a data destination through the intranet 206 and/or the Internet 208. If the data arrives at the imaging server 221 in a compressed format, the imaging server can uncompress the data before processing it. Similarly, where appropriate, the imaging server 221 can compress data before saving it to a data destination. Transmission of data from data sources and to data destinations through the networks is effected according to an appropriate public communication protocol, such as the FTP protocol, the XML protocol, the HyperText Transport Protocol (HTTP), or some other suitable protocol. FIG. 9 shows several examples of devices that the imaging server module 247 can write data to and/or read data from. These include the FTP site 231, the database 227, the ERM 232, and the file server 216. In general, and as discussed later, the information contained in tasks 251 and 252 is a copy of information that is also present elsewhere in the system 201. The copy of this information is supplied to the memory 242 of the server 221 on a temporary basis, for purposes of permitting the server 221 to execute a project definition associated with each such task. In more detail, the project definition 256 in each of the tasks 251 and 252 is a respective project definition of the general type discussed above in association with FIGS. 1 and 6-8, and is stored in an XML format consistent with the example shown in TABLE 5. The data 258 represents temporary storage for data that is being processed by the associated project definition 256. One example of such data is images that have been obtained from a source such as the FTP site 231, and that will be returned to a destination such as the FTP site 231 after they have been processed. The selected executables 257 are selected object code files, which may or may not be present in a given task 251 or 252. Whether or not there are executables stored at 257 is a function of the above-mentioned capability for creating custom modules. In this regard, the imaging server module 247 knows how to execute definitions for standard modules, including those set forth in TABLEs 1-4. However, it cannot inherently know how to execute definitions for custom modules. Accordingly, if a given project definition 256 happens to include one or more custom modules, then object code files that are capable of implementing those custom modules are included at 257 in the task 251 or 251 for that project definition, so that the imaging server module 247 will have the additional intelligence that it needs to execute the custom modules in the project definition. Although the tasks 251 and 252 in the disclosed embodiments each include a project definition at 256 and selected executables at 257, it would alternatively be possible to use pointers rather than the actual data. That is, the tasks 251 and 252 could include at 256 a pointer to the pertinent project definition as stored in the process server 212, and could include at 257 one or more pointers to the selected executables as stored within the process server 212. The imaging server 221 could then use the pointers to download from the process server 212 only the information which it needed. Although FIG. 9 shows that the imaging server 221 has been supplied with two tasks 251 and 252, which each correspond to a respective project definition, the number of tasks being handled by the imaging server 221 at any given point in time could be higher or lower. In particular, the imaging server 221 might be handling only one task, or might be handling several tasks. In general, to the extent that the imaging server 221 has two or more task at any given point in time, it will be executing the tasks in parallel, for example by supplying slices of processor time to each task in a manner which keeps each task moving along as efficiently as possible. In this regard, if one of the tasks is processing image data obtained from the FTP site 231 through the Internet 208 and intranet 206, there are likely to be times when that task is essentially idle, because it is waiting for more image data, and thus the processor can be concentrating on execution of one or more other tasks. The same is true when any other task becomes idle for some reason, because the processor will concentrate on remaining tasks which are currently active. If the set of tasks assigned to a given processor are not cumulatively keeping the processor busy almost all of the time, still another task can be assigned to the processor, in a manner described later. In the embodiment of FIG. 9, a single instance of the imaging server module 247 is used in each of the imaging servers 221-223, and can execute multiple project definitions. However, it would alternatively be possible for each imaging server 221-223 to execute two or more instances of the project server module 247, where each such instance was responsible for executing a respective one of the project definitions. The auxiliary server 217 executes an operating system 271, which in the disclosed embodiments is a version of the operating system available under the trade name WINDOWS. Running on the operating system 271 within the auxiliary server 217 is an image processing application program 272, which in the disclosed embodiments is a program commercially available under the tradename PHOTOSHOP from Adobe Systems Incorporated of San Jose, Calif. However, some other image processing application program, or some other type of application program, could alternatively be used. Moreover, even though the embodiment of FIG. 9 has the application program 272 running on a computer 217 which is physically separate from other computers in the system 201, it would alternatively be possible for the application program 272 to run on one of the other computers in the system 201, such as the process server 212 or one of the imaging servers 221-223. If one of the imaging servers 221-223 is executing a project definition which includes an External Action module, then in order to execute that External Action module, the imaging server passes the current image and a specified command through the intranet 206 to the auxiliary server 217. The image processing application 272 in the auxiliary server 217 then executes the command so as to effect the specified processing of the image, and then returns the processed image through the intranet 206 to the imaging server. When the system 201 is operational, the auxiliary server 217 and the image processing application 272 normally run all of the time, and are thus typically ready and waiting when an image and associated command arrive through the intranet 206. As noted above, the application program 272 is effective only as to functions initiated through an External Action module, such as the External Action module shown at 186 in FIG. 8. Thus, where the application program 272 is an image processing program, it implements only image processing functions initiated by an External Action module. Image processing functions initiated by all other types of modules are implemented by other software, such as the imaging server program 247 that runs on each imaging server 221-223. The process server 212, which may alternatively be referred to as a load balancing server, is responsible for monitoring the imaging servers 221-223, and allocating tasks to the imaging servers 221-223 in dependence on factors such as their current level of efficiency, which reflects their availability to take on execution of additional project definitions. The manner in which this occurs is described below. The various software programs that run on the process server 212 may be referred to collectively as a process server framework. The process server 212 includes a processor 277 and a memory 278. The memory stores a number of sets of user data, which are each associated with a particular person. For the sake of example, four sets of such user data are shown at 281-284, but in practice the process server 212 will store a much larger number of sets of user data. Each set of user data includes one or more project definitions 286, and one or more custom definitions 287. It is possible for a user, for example at one of the workstations 211 or 226, to store a project definition in his or her portion 286 of the memory 278. This can also be referred to as "publishing" the project definition to the process server 212. Whenever a project definition is published to the process server 212, the object code for any custom modules used in that project definition will automatically and simultaneously be published with it, and in particular will be stored in that user's custom definition portion 287 of the memory 278. Further, when a project definition is published to the process server 212, the local copy of the project definition in the workstation 211 will be automatically deleted, unless the user specifically indicates that it should be saved. Although a user has access to his or her own project definitions 286 and any associated custom definitions 287, others will not have access to them, except to the extent that the user elects to give them access. In this regard, the user data 281-284 in FIG. 9 is organized into two groups 291 and 292, where the group 291 includes the user data 281 and 282, and the group 292 includes the user data 283 and 284. In this disclosed embodiment, the groups 291 and 292 each correspond to a respective different entity. For example, the group 291 may correspond to a first corporation, where the user data 291 and the user data 292 respectively correspond to two different employees of that corporation, and the group 292 may correspond to a second corporation, where the user data 293 and the user data 294 respectively correspond to two different employees of the second corporation. When a user publishes project definitions and any associated custom definitions to the process server 212, it is possible to do so in a manner so that other users within the same organization or entity can have access to specified project definitions and/or custom definitions. Thus, for example, the user associated with the data 282 may be given access to some or all of the project definitions at 281, which will automatically include access to any custom definitions used by those project definitions. Also, the user associated with data 282 may separately be given access to some or all of the custom definitions at 281, even if the user has not been given access to any of the project definitions at 281. The disclosed embodiment contemplates that this cross access to project definitions and custom definitions will be limited to users within a given entity, such as the entity 291 or the entity 292, and that users in one entity such as the entity 291 will not be able to have access to data of users in another entity such as the entity 292. However, in an alternative embodiment, cross access to user data could occur between users in two different entities. A user at one of the workstations 211 or 226 may upload to that workstation any project definition from the process server 212 to which that user has access. In doing so, the user may either make a copy of the project definition, such that the original in the imaging server remains available to anyone that has access to it. Alternatively, the user may upload a project definition through a "check out" procedure which makes the project definition in the process server unavailable to everyone until the user checks the copy back in (along with any changes that the user may have made to the copy). The memory 278 also stores a request queue 296. Execution of one of the project definitions 286 is initiated in response to receipt by the process server 212 of a request. Such a request may arrive through the intranet 206 and/or Internet 208, for example from a user at one of the workstations 211 and 226. When the request arrives, the request is temporarily placed in the queue 296, which implements a first-in, first-out stack. Typically, the request will identify one of the project definitions stored at 286 in one of the sets of user data 281-284. Alternatively, however, the request may be accompanied by a project definition and any custom definitions used by that project definition, which are then temporarily stored in the user data 281 for that user, until execution of that project definition has been completed. Requests for the queue 296 may also originate in some other manner. For example, assume that a given project definition stored in one of the portions 286 of the memory 278 processes data from the database 227. The database 227 may include a script or other intelligence which, in response to a change to the pertinent source data in the database 227, automatically generates and sends to the process server 212 a request for execution of the given project definition, so that the modified data will be automatically processed. According to a feature of the invention, each request sent from any source to the process server 212 is expressed in a public communication protocol, which in the disclosed embo | ||||||