AU2005247025B2 - Just-in-time Workflow - Google Patents

Description

S&F Ref: 743380 AUSTRALIA PATENTS ACT 1990 COMPLETE SPECIFICATION FOR A STANDARD PATENT Name and Address Canon Kabushiki Kaisha, of 30-2, Shimomaruko 3-chome, of Applicant: Ohta-ku, Tokyo, 146, Japan Actual Inventor(s): Rawinder Kaur Khera Singh John Charles Brook Address for Service: Spruson & Ferguson St Martins Tower Level 35 31 Market Street Sydney NSW 2000 (CCN 3710000177) Invention Title: Just-in-time Workflow The following statement is a full description of this invention, including the best method of performing it known to me/us:- -1 JUST-IN-TIME WORKFLOW COPYRIGHT NOTICE This patent specification contains material that is subject to copyright protection. The copyright owner has no objection to the reproduction of this patent specification or related materials from associated patent office files for the purposes of review, but 5 otherwise reserves all copyright whatsoever. FIELD OF THE INVENTION The current invention relates to the field of business workflow, and particularly relating to document workflow in an office, corporate, commercial, or print-process environment utilising network communications. 10 BACKGROUND Workflow is the operational aspect of a work procedure, namely how tasks are structured, who performs them, what their relative order is, how they are synchronized, how information flows to support the tasks and how tasks are being tracked. As the dimension of time is considered in Workflow, Workflow considers "throughput" as a 15 distinct measure. Alternately workflow can be considered to be the automation of a business process, in whole or part, during which documents, information or tasks are passed from one participant (being a resource, human or machine) to another for action, according to a set of procedural rules. State-of-the-art workflow systems suffer from a number of problems that make 20 them inflexible, inadequate or prone to failure when deployed into real business or commercial environments. Two such problematic features of workflow systems are their static definition of workflow processes and their centralisation. 221205 743380 -2 Current business & print workflow systems are inflexible and static once deployed. The typical approaches to definition and deployment of business and print workflow systems involve these steps: a study of the current business environment and possible definition of new, or improved workflows; selection of a workflow management 5 product or products; transcription of the study results and any commissioned workflow process improvements into hard-coded workflow templates for utilisation by the selected product(s); customisation of workflow product features and interfacing of the product(s) and features into existing business systems; training at many levels; and deployment and switch-over to the new workflow system. At this point, a workflow process has been 10 defined, customised and deployed and it should be adequate for the scope of tasks and contingencies recognised at the time of the defining study. Business workflow requirements rarely remain static. There are numerous dynamic pressures on a business, including, for example, its own growth, that require a business to react appropriately and in new ways, and often in ways not anticipated in the 15 original workflow study and definition steps. These dynamic pressures each have their own characteristics, including repetition frequencies and rates of change. Some state of the art workflow products attempt to ameliorate these dynamic pressures, which often comprise combination-problems of change, obsolescence and contingency, by providing easier and faster methods of designing workflow templates. 20 There exist workflow template authoring tools that may be used by the workflow product distributor, consultant or the target customer business, to customise or update workflow processes. However, these tools are offline tools, or setup tools and are intended for one off or low frequency use and they do not significantly improve the essentially static nature of current workflow solutions. 221205 743380 -3 Some workflow authoring tools provide a friendly user interface to increase the capability of understanding of a user defining a workflow template, therefore allowing the workflow authoring to be undertaken by a less-qualified person, such as a target customer employee. This kind of tool might also allow or encourage more frequent updating of the 5 target customer's workflow template. The tools would also typically provide a (re )deployment means for an updated or created workflow template. However, each redeployed, updated template remains static in its behaviour. Furthermore, the updating and redeployment cycle causes a need for re-training or re-documenting of workflow processes, with a large cost downstream of the update step. 10 A static, templated workflow process is unable to accommodate high-rate dynamic changes in a target business's activities (e.g. monthly, weekly, daily, hourly change rates or zero-notice changes). The many possible pressures for change on a business workflow can be categorised, with some examples being: internal role and resource changes; internal policy changes; external market pressures demanding internal 15 business strategy changes (e.g. requiring a strategic redesign of prioritisation of workflow process steps, acceleration of some workflow processes, differing profiling of business processes per market or customer, etc); capital investment and internal deployment of new equipment or tools or software; business structural changes; new or modified legislation; customer or supplier business operational changes; equipment failure; internal and 20 external financial pressures; travel or relocation of elements inside or outside a business; and so on. Even quite minor changes in workflow processes cannot typically be accommodated by typical workflow systems. For example, a casual employee might temporarily replace a person having a role in a workflow process. In some workflow 221205 743380 -4 systems the insertion of this casual employee into the appropriate workflow system databases could be restrictively expensive or time-consuming, often incurring a high latency. However, this kind of change is more likely to be supported by more recent workflow systems, which may exhibit a flexibility for minor change up to a threshold, -5 above which the workflow systems become extremely inflexible or brittle in response to change. Other kinds of minor changes can include 'convenience cases' where users or customers of a workflow system desire or require some flexibility to cope with arbitrary decisions or situations. For example, if a user of a workflow process within a business 10 wishes to or is required to execute a workflow step at a different location or device or using a different service from normal, at zero notice to the system or its administrator or manager, then this might often be impossible for a system to accommodate. Where deployed systems utilise identical computing equipment in all locations, and if a business' security & access control policies allow, a user might be able to execute his/her workflow 15 step at any location or device. However, this homogeneity is not general, and particularly not where heterogeneous devices and services are interconnected with a workflow system or process. Homogeneity can also be expensive or constricting to a business because it can be an inefficient way to distribute and locate services. A further example of minor changes imposed on a business workflow system is 20 the need to invoke contingencies to cope with equipment or communications or other technology failures, again, at zero notice. There exist many business processes that cannot be usefully described by current workflow processes or that cannot be adequately supported by current workflow systems 221205 743380 -5 because of their requirements for flexibility, convenience, etc. In short, the dynamic pressures on these businesses cannot be accommodated by current workflow methods. The traditional approach to workflow is to execute workflow state machines or directed graphs (mathematical equivalents) on a central workflow engine, typically a 5 single engine in a fixed physical and network location. The workflow engine, or server, is linked to or integrated with one or more databases containing workflow process templates, access & security information, client device & user details and possibly data materials such as documents. The centralisation of workflow systems creates several disadvantages including, a central zone of failure including the workflow engine and its 10 subsidiary parts and core network facilities; difficulty in accommodating greater demand for computing time, memory and network bandwidths at the workflow engine, resulting in latency in workflow processing and requiring a costly machinery upgrade path; wastage of processing ability in client, subsidiary and other network computing resources, which are typically much more capable than required by the client-side tasks running on them; etc. 15 Some attempts have been made to reduce the workload of workflow engines or to distribute them across business boundaries or similar, or to reduce their memory needs. These methods are severely limited in their abilities and applicability and retain many of the disadvantages of a single workflow engine. Agent-based workflow systems include many definitions of the meaning of 20 'agent' and consequently exhibit a variety of properties. There has been a successful deployment of agents within telecommunications industries, typically for automating service contract fee negotiations or billing services across commercial boundaries. Some recent agent deployments involve management, monitoring or billing for content provision services. These agent applications typically involve instantiating and executing 221205 743380 -6 an agent per service-instance upon one or more predetermined workflow computing nodes. That is, an agent workflow engine instance executes on one of a specially designated group of service management machines. Some hypothesized agent-based workflow implementations allow further 5 decentralisation of workflow execution by spawning a network-mobile workflow engine agent per workflow instance. A network-mobile workflow engine agent might travel between nodes of a network in the execution of its workflow process. This behaviour would allow partial or entire decentralisation of the workflow engine computing and memory resource demands, thus reducing some of the aforementioned problems 10 associated with centralised workflow engines. A cost of such a network-mobile agent approach is again one of homogeneity in which all network nodes (often clients of the workflow process) would be required to support the same minimum system requirements such as including a Java@ Virtual Machine, and adequate memory, cpu power, etc. SUMMARY 15 It is an object of the present invention to substantially overcome, or at least ameliorate, one or more disadvantages of existing arrangements. Disclosed are arrangements, referred to as just-in-time workflow (JITW) arrangements, which seek to address the above problems. JITW arrangements enable decentralised assembly and disassembly of instances of a Workflow Process Engine 20 (WPE) for performing a sequence of tasks. Different sequences of tasks may require correspondingly different WPEs. The assembly of a WPE (alternately referred to as a WPE instance) is triggered by the advent of the sequence of tasks. The entire WPE may be assembled before a first of the sequence of tasks is processed. Alternately, the WPE 221205 743380 -7 may be progressively assembled as successive tasks in the sequence are processed; hence the use of the term "just-in-time workflow". The WPE can be disassembled after all the tasks in the sequence have been processed. Alternately, the WPE may be maintained for further instances of the same type 5 of sequence of tasks. Alternately, the WPE can be progressively disassembled as tasks in the sequence are processed. From a terminology perspective, the WPE "executes" an associated Workflow Process (WP) in order to perform the sequence of tasks. A part of the WPE (ie a partial WPE) "executes" a corresponding part of the associated Workflow Process (WP) (ie a corresponding partial WP) in order to perform one or more 10 corresponding tasks in the sequence of tasks. The WPE comprises a number of network services (which may also be network devices) typically drawn from a pool of network services that are connectable over a communications network. In assembling a WPE, network services successively identify subsequent network services on the basis of the suitability of the subsequent network services to communicate over the network and to 1.5 perform their associated tasks. According to a first aspect of the present invention, there is provided a method of performing a sequence of tasks using a system comprising a plurality of network services that can communicate over a network, the method comprising the steps of: processing a current task in the sequence by a current network service; 20 selecting, by the current network service, a subsequent network service dependent upon (i) the capability of the subsequent network service to communicate with the current network service over the network and (ii) the capability of the subsequent network service to perform a subsequent task in the sequence; 221205 743380 -8 communicating, by the current network service over the network, an attribute of the current task to the subsequent network service; designating the subsequent network service to be the current network service; defining the subsequent task in the sequence to be the current task; and 5 repeating the processing step. According to another aspect of the present invention, there is provided a system for performing a sequence of tasks using a plurality of network services that can communicate over a network, the system comprising: a plurality of network devices that can communicate over said network, each 10 network device supporting at least one of said network services, each said network device comprising: a memory for storing a program; and a processor for executing the program said program comprising; code for processing a current task in the sequence by a current 15 network service; code for selecting, by the current network service, a subsequent network service dependent upon (i) the capability of the subsequent network service to communicate with the current network service over the network and (ii) the capability of the subsequent network service to perform a subsequent task in the sequence; 20 code for communicating, by the current network service over the network, an attribute of the current task to the subsequent network service; code for designating the subsequent network service to be the current network service; 221205 743380 -9 code for defining the subsequent task in the sequence to be the current task; and code for repeating the processing step. According to another aspect of the present invention, there is provided a 5 computer program product including a computer readable medium having recorded thereon a computer program for directing a processor to execute a method for performing a sequence of tasks using a system comprising a plurality of network services that can communicate over a network, the program comprising: code for processing a current task in the sequence by a current network service; 10 code for selecting, by the current network service, a subsequent network service dependent upon (i) the capability of the subsequent network service to communicate with the current network service over the network and (ii) the capability of the subsequent network service to perform a subsequent task in the sequence; code for communicating, by the current network service over the network, an 15 attribute of the current task to the subsequent network service; code for designating the subsequent network service to be the current network service; code for defining the subsequent task in the sequence to be the current task; and code for repeating the processing step. 20 Other aspects of the invention are also disclosed. BRIEF DESCRIPTION OF THE DRAWINGS One or more embodiments of the present invention will now be described with reference to the following drawings and Appendices, in which: 743380/ 153265v3 110309 -10 Fig. 1 is a functional block diagram of an interconnected computer system upon which described methods for JITW can be practiced; Fig. 2A is a flow diagram showing a first embodiment workflow process assembly method of the disclosed JITW arrangements; 5 Fig. 2B is a flow diagram showing a first embodiment workflow process execution method of the disclosed JITW arrangements. Fig. 2C is a flow diagram showing a first embodiment workflow process disassembly method of the disclosed JITW arrangements. 10 THE NEXT PAGE IS PAGE NO. 12 743380 / 153265v3 110309 -12 Fig. 3 shows an exemplary workflow process chain of services. Fig. 4 shows an exemplary network pool of devices and services. Fig. 5A is a flow diagram showing a second embodiment workflow process assembly and execution method of the disclosed JITW arrangements. 5 Fig. 5B is a flow diagram showing a third embodiment workflow process assembly, execution and disassembly method of the disclosed JITW arrangements. Fig. 6 shows an exemplary use-case of a staff purchase workflow process for the disclosed JITW arrangements. Fig. 7A is a flow diagram showing a fourth embodiment workflow process 10 assembly and execution method involving two-level constraint testing. Fig. 7B is a flow diagram showing a fifth embodiment workflow process assembly and execution method involving service self-selection to a workflow process instantiation. Fig. 8 shows a sixth embodiment workflow process 'pull' assembly-execution 15 document search example use-case; and Fig. 9 is a flow diagram for a device participating in a workflow process of the disclosed JITW arrangements. Appendix A shows an exemplary XML workflow process template fragment for a PDA device permitted to be involved in a staff purchase workflow and a document 20 search workflow. Appendix B shows an exemplary XML workflow process template fragment for a scanner device permitted to be involved in a staff purchase workflow. Appendix C shows an exemplary XML workflow process template fragment for a printer device permitted to be involved in a staff purchase workflow. 221205 743380 -13 DETAILED DESCRIPTION INCLUDING BEST MODE Where reference is made in any one or more of the accompanying drawings to steps and/or features, which have the same reference numerals, those steps and/or features have for the purposes of this description the same function(s) or operation(s), unless the 5 contrary intention appears. The disclosed JITW arrangements relate to the field of business workflow, and particularly relate to document workflow in an office, corporate, commercial, or print process environment utilising network communications. The purpose of the disclosed JITW arrangements is to enable and construct a workflow process that is specially capable 10 of functioning in real-world conditions, under imposition of zero-notice or arbitrary constraints. A templated workflow process is one, similar to the prior art, that is partially or wholly pre-defined in a template in terms of the workflow process' sequence of processing, or its end-to-end transformation of data, or its event-based behaviour or its parameters, or its security and access control parameters or any of these and more details 15 of execution. The disclosed JITW arrangements provides for creation and execution of a workflow process that is adapted in its construction to, or by, real-world conditions or constraints to perform the required, templated workflow process, thereby enabling a Just in-Time Workflow Process. Fig. 1 is a functional block diagram of an interconnected computer system upon 20 which described methods for JITW can be practiced. The JITW method lends itself to implementation on a system of interconnected computer systems 1000, such as that shown in Fig. 1 wherein the JITW processes of Figs. 2A-2C, 5A-5B, 7A-7B, and 9 can be implemented as software, such as distributed JITW software applications executing within the various interconnected computer modules in the computer systems 1000. In 221205 743380 -14 particular, the steps of the JITW method are effected by instructions in the software that are carried out by the computer(s). The instructions can be formed as one or more code modules, each for performing one or more particular tasks. Each software module, running on one of the 5 interconnected computer modules in the computer system 1000, can also be divided into two separate parts, in which a first part performs the JITW methods, and a second part manages a user interface between- the first part and the user on the particular computer module in question. The software can be stored in a computer readable medium, including the storage 10 devices described below, for example. The software is loaded into each of the computer modules from the computer readable medium, and then executed by the respective computer modules. A computer readable medium having such software or computer program recorded on it is a computer program product. The use of the computer program product in the computer preferably effects an advantageous apparatus for performing the 15 JITW approach. The computer system 1000 is formed by a number of computer modules 301, 310, 320 and so on. See Fig. 4 for more detail. Although Fig. 4 makes specific reference to different network devices including a workstation 301, a copier 310, a server 320 and so on, it is apparent that each of these network devices incorporates a computer module, 20 and it is to these computer modules that the computer system 1000 primarily relates. Each of the network devices in question typically has a processor, memory and other computer modules such as communication modules, and the presence of these modules will be assumed without further explicit mention. The following description is directed to 221205 743380 -15 the computer module 301, however it also applies, with appropriate modifications, to the other computer modules in the system 1000. The system 1000 also includes, in relation to the computer module 301, input devices such as a keyboard 1002 and mouse 1003, output devices including a 5 printer 1015, a display device 1014 and loudspeakers 1017. A Modulator-Demodulator (Modem) transceiver device 1016 is used by the computer module 301 for communicating to and from a communications network 390, for example. connectable via a telephone line 1021 or other functional medium. The modem 1016 can be used to obtain access to the other network devices 310, 320 across the Internet, and other network systems, such as 10 a Local Area Network (LAN) or a Wide Area Network (WAN), all these networks being represented in Fig. 1 by the network 390, and can be incorporated into the computer module 301 in some implementations. The computer module 301 typically includes at least one processor unit 1005, and a memory unit 1006, for example formed from semiconductor random access memory 15 (RAM) and read only memory (ROM). The module 301 also includes an number of input/output (1/0) interfaces including an audio-video interface 1007 that couples to the video display 1014 and loudspeakers 1017, an I/O interface 1013 for the keyboard 1002 and mouse 1003 and optionally a joystick (not illustrated), and an interface 1008 for the modem 1016 and printer 1015. In some implementations, the modem 1016 can be 20 incorporated within the computer module 301, for example within the interface 1008. A storage device 1009 is provided and typically includes a hard disk drive 1010 and a floppy disk drive 1011. A magnetic tape drive (not illustrated) can also be used. A CD-ROM drive 1012 is typically provided as a non-volatile source of data. The components 1005 to 1013 of the computer module 301, typically communicate via an 221205 743380 -16 interconnected bus 1004 and in a manner which results in a conventional mode of operation of the computer system 1000 known to those in the relevant art. Examples of computers on which the described arrangements can be practised include IBM-PC's and compatibles, Sun Sparcstations or alike computer systems evolved therefrom. 5 Typically, the JITW application program is resident, in regard to the computer module 301, on the hard disk drive 1010 and read and controlled in its execution by the processor 1005. Similar JITW software applications are similarly resident on the other network devices 310, 320 and so on. Intermediate storage of the program and any data fetched from the network 390 can be accomplished using the semiconductor 10 memory 1006, possibly in concert with the hard disk drive 1010. In some instances, the JITW application program can be supplied to the user encoded on a CD-ROM or floppy disk and read via the corresponding drive 1012 or 1011, or alternatively can be read by the user from the network 390 via the modem device 1016. Still further, the software can also be loaded into the computer system 1000 from other 15 computer readable media. The term "computer readable medium" as used herein refers to any storage or transmission medium that participates in providing instructions and/or data to the computer system 1000 for execution and/or processing. Examples of storage media include floppy disks, magnetic tape, CD-ROM, a hard disk drive, a ROM or integrated circuit, a magneto-optical disk, or a computer readable card such as a PCMCIA card and 20 the like, whether or not such devices are internal or external of the computer module 301. Examples of transmission media include radio or infra-red transmission channels as well as a network connection to another computer or networked device, and the Internet or Intranets including e-mail transmissions and information recorded on Websites and the like. 221205 743380 -17 First embodiment. A first process, this capable of implementation as an application software program, for performing an example of the JITW approach is shown in Fig. 2A. The method, 100, assembles a workflow process from a sequence of network services, 5 according to a set of constraints. The term "network service" is taken to mean either a network service or a network device such as a printer. The aforementioned "assembly of a workflow process" refers to a method for putting in place a set of network services and/or network'devices that are suitable for performing a desired sequence of tasks. These tasks can comprise, in a particular 10 example, making a purchase request on the workstation 301 using, for example, a web form service. The web form service selects the copier 310 as being suitable to perform the next step in the workflow, and hands control of the workflow over to the copier 310 when the purchase request has been completely filled in. See Fig. 6 for a more detailed description in this regard. 15 The process 100 starts at 101, from which process building is initiated at step 103. The step 103 can typically involve some triggering event, including a device-based or software-based event or a user-based event (e.g. a user clicking on a PDA launch icon) that causes a workflow process launcher to execute. Such a launcher might involve any standard operating system or multi-tasking scheduler initiation of a process or task, as is 20 well-known in the art. In particular, the workflow process launcher activates the JITW software modules in some or all of the network devices and services in the system 1000 (see Fig. 1). Alternatively, step 103 can involve the execution of a specially designed launcher for launching a unique workflow process or for launching any workflow process. Step 103 would typically involve input, provision or detection of a identifier, event type 221205 743380 -18 or other data or metadata that could be passed out by 103 into 105 to identify an appropriate workflow process template. A workflow process template can itself be provided to or by step 103 instead of the aforementioned identifier. At 105, the desired workflow process is initiated by identifying and instantiating 5 the next (in this case, the first) service of the workflow process. As mentioned, the identification is by means of or leads to the selection of an appropriate workflow process template. This template provides a set of constraints on the workflow assembly method 100. There are other constraints (hereby named 'external constraints') that will typically affect method 100 and these would typically come from real-world sources such as user 10 choices of devices, or user-entered parameters, or from network sources such as the availability of certain devices or services, or from a device's internal capabilities or various constraints, and from other sources that will be explained or exemplified later. The selection of the first service of the workflow process assembly at 105 can typically depend on the selected template. The first service would typically be some input 15 service or event-wait service, such as, respectively, input of a user parameter or a wait for a document to be updated in a database. The first service might also involve both an input and an event-wait together such as a wait for a completed web form. At step 107, the next service is redesignated as the current service. Step 107 involves a test to see if the workflow building process is completed. This test is 20 performed by testing the constraints known to the building process to see if completion criteria are met. The test, 107 is typically performed by, or in association with the last service appended to the workflow process under construction. A preferred implementation of the method 100 would involve each appended service (at 105 and 111) 221205 743380 -19 performing the completion test 107 during or after the service's appension to the end of the workflow process. The service assembly at 105 and 111 preferably involves instantiation of a service, or some equivalent context-based operation, in a device. 5 The constraints that are checked at 107 can be template or external constraints. A preferred operation method for 100 would be that the template would list constraints and values that would control completion of the workflow process assembly. Such constraints might include a list of the types of services and their order of assembly, or merely identification of the last service type of a workflow process (e.g. a printer 10 device/service). The template can also identify or reference some external constraints that provide control of the completion condition tested at 107 for the workflow process assembly. An example of this kind of template-referenced external constraint might be that a service completion event message has been received. External constraints can also control the completion test at 107 without being explicitly identified in the workflow 15 process template. An example is that a service or device can have an inherent event wait constraint that the service or device itself identifies, implicitly, as an assembly completion condition. Such an event could be, for example, a print complete event, or a database save completion event. If the test at step 107 is false, execution proceeds to step 109 at which the 20 instantiated service checks template and external constraints to identify which should be the next service type to append to the workflow process. This identified next service is then instantiated and appended to the workflow process at step 111. Execution then proceeds to step 107 again. 221205 743380 -20 As can be understood by consulting Fig. 2A, method 100, the workflow process comprises a sequence of instantiated services (the term 'service' hereby includes the meaning of 'device' unless otherwise indicated). Each service type is available in a pool of services scattered around a network. Services can be virtual, or real (such as in device 5 based). Services can execute at a fixed physical location that can be inherent and explicit (such as a networked photocopier) or that can be merely implied (e.g. a software service executing on a server on a network, wherein the physical location, although fixed, is irrelevant). Services can also have no fixed location, such as agents or floating software services that can execute on any number of physical network nodes depending on the 10 constraints during their instantiation. The workflow process assembly method 100 involves each last-instantiated service being responsible for executing steps 107, 109, 111 until a service obtains a positive answer to the completion test in 107. That aforementioned service is the last service of the workflow process and the workflow process is now instantiated. As may be 15 realised, there need not be any specific location at which this workflow process instance is actually executing. In general, the execution occurs in a distributed form across a network. Preferably, the execution would occur at network nodes or devices as is decided by the constraints. Therefore, the constraints define the characteristics of the assembled and instantiated workflow process. In fact, the external constraints would often include 20 real-world and dynamic information and the method 100 is therefore capable of assembling a workflow process that is specifically adapted to the dynamic, real-world, zero-notice constraints typical of the human workflow environment. Furthermore, method 100 does not centralise the execution of the instantiated workflow process onto one of a restricted number of high-speed, expensive workflow engines. The method of 221205 743380 -21 100 naturally distributes the execution of the workflow process across any number of nodes of the network, as is governed by the constraints affecting 100. Therefore, there may be a reduced or eliminated need for installation of expensive high-speed workflow engines into a network. 5 Fig. 3 indicates a graphical representation 200 of an assembled and instantiated workflow process 210 comprising a sequence of services. Example 200 includes an initiator 201 which was launched at the step 103 (see Fig. 2A). The initiator 201 was provided information to enable selection of a process template 209 from a database 229 or other internal or external data source (not shown). By consulting the process template 10 209, the initiator 201 selected and instantiated the first service 203 at the step 105 in Fig. 2A. The initiator 201, having instantiated the first service 203, would handover assembly control to the first service 203. The first service 203 performs the completion test step 107, thereby testing process template and/or external constraints for an assembly 15 completion condition. Detecting a false value at the step 107, the first service 203 would check the constraints in the process template and/or the external constraints to identify the next process (205) to be selected from the network pool and appended and instantiated at 111 as second service 205. Similarly, the instantiated service 205 is handed control of the assembly by the 20 first service 203. The second service 205 executes the step 107 in a similar manner to the way in which the first service 203 executed the step 107. However, the second service 205 will perform its own selection of relevant constraints for testing from the process template and these may not be identical to the constraints selected and tested by the first service 203. Further, the second service 205 can also test at the step 107 external 221205 743380 -22 constraints that differ from those tested by the first service 203 when it executed the step 107. The second service 205 detects a false result from the step 107 and then performs the step 109, checking process template and external constraints to identify and select the 5 next service type to append to the workflow process. At the step 111, the second service 205 appends and instantiates the third service 207 and hands over control to the service 207. The third service 207 executes the step 107, as have previous instantiated services in this workflow process assembly method 100, however, this time, the third service 207 detects a true condition at the completion test step 107 and the third service 207 proceeds 10 to execute the step 121. The service instantiation steps 105 and 111 include passing of at least one parameter to the instantiated service, this parameter performing the primary task of connecting the instantiated services in the order in which they were appended to the workflow process. This parameter passing helps to append the newly instantiated service 15 to the growing workflow process. The previous service also retains the address of the next process that it caused to be instantiated. These actions thereby enable the workflow process self-assembly and inherent communication. There are many known methods for allowing services or software processes to communicate and many of these are potentially applicable. For example, if external storage such as the database 211 is available, then 20 only a reference or workflow process instantiation ID need be passed as a parameter to each next service, for instance an ID passed from the service 203 to the service 205 and thence to the service 207. That parameter can then be used by the service 205 to index the database 211 via a connection 225, as did the service 203 via 223 and as will the service 207 via 227, to establish context information and service URIs, etc to support the working 221205 743380 -23 of the instantiated workflow process 210. If the database 211 UJRI is not natively known to the instantiated services then that database URI will also need to be passed to each instantiated service at append time. Other forms of inter-service communication include passing larger volumes of data, such as files or streams between services, therefore not 5 requiring the external database 211 or similar. A significant function of the inter-service communication is to communicate the workflow process template that defines the workflow under construction and provides the template constraints information to each service. This is how the service executing at the steps 107 and 109 obtains the workflow process template and template constraints 10 information. It may also be how the workflow instantiator at the steps 103 & 105 knows which workflow process to start building and which is the first service to instantiate. It may be realised that variations of the method 100 are possible to achieve equivalent results. For example, the workflow instantiator may in fact be itself the first service of a workflow process as specified in a workflow template. In addition, the 15 constraint analysis and decision steps 107 & 109 might be merged or even swapped, with slight changes in behaviour but achieving a substantially equivalent result as the first embodiment method 100. It may also be realised that in Fig. 3, the initiator, 201 might itself be a first service of the instantiated workflow. Also, any service, such as 203, might be a 20 compound service, such as is 210, for example. Therefore, a single service need not provide all of the functionality required to self-assemble into a workflow. In fact a service might be 'docked' into a group service (such as 210 for example) and the communication & self-assembly facilities might be provided by other parts of the group service. .221205 743380 -24 It may also be realised that there are many less flexible methods of embodying the disclosed JITW arrangements with at least partially equivalent results to the method of 100 and the example 200. For example, the workflow process template, 209, might be hard-coded into one or more services, as a 'native' workflow. Such services would then 5 have less need for communication information or an external data repository such as 211. Another variation might be that the process workflow template explicitly defines the URIs for each service type (i.e. the location of the executable for a service type) and/or even instantiation IDs of each service, therefore providing each instantiated service with implicit communication and a fixed, or quasi-fixed workflow process result. These 10 alternative methods are approaching some of the state of the art inflexible methods involving predefined connectivity and workflow steps. Fig. 4, depicts an exemplary network 300 in which a group of network devices and network services are networked together so that they can communicate. The network, 390, can be a LAN, WAN or the internet. Devices and services can be local, such as on a 15 local corporate intranet, remote such as in a corporate WAN, remote as in an internet connected print business, or remote as in anywhere on the internet. The incorporation of remote devices or services typically requires the use of specific protocols and command formats such as HTTP protocol, XML, SOAP and XML RPC, for instance in order to penetrate firewalls and to be supported by generic network systems. In a corporate WAN, 20 it is possible that customised or proprietary protocols and command formats will be used. The network 300 in Fig. 4 exemplifies a pool of services and devices available to a Just-in-Time workflow process. The network is heterogeneous, as are many corporate offices, containing some equivalent or identical services. Workstations 301 and 315 each support service types A, 302, 316, and D, 304, 318. These services might include a 221205 743380 -25 document processing service such as layout, or a host rendering printer driver service, for example. These services may be identical in all respects except for their physical location and the hardware on which they will be executed. Printer 305 may be a basic laser printer with print service E, 306, that requires a 5 host renderer service such as service D, either 304 or 318. Printer 335 with service 336 is another example of the same but in a differing physical location. Photocopier 310 offers a scanning service B, 312 and a quality-colour printing service E, 314. Photocopier 330 also offers the same services B, 332 and E, 334. Also offering scanning or document creation services B, 352 and 357 are networked scanner 10 350 and workstation 355. Workstation 355 also offers a service type A, 356, as does PDA 345 offer service type A, 346 via wireless connection to router 380. A scanning or document creation service such as these examples of service B may be used as a service appended to a workflow process. Such a service allows input of an analogue-paper original document as an electronic document that can be manipulated by subsequent 15 services in the workflow process. Server computer 320 offers services C, 322 and D, 324. Database (server) 325 offers services F, 326 and A, 328. Database (server) 340 offers workflow process templates 341, 342, 343, 344 for guiding and constraining construction of differing workflow process types. 20 Returning to Fig. 2A, at step 121, after the last service is instantiated and appended, the last service signals the workflow process initiator such as 201, that the assembly process is completed. The last service can be aware of its status as the last service from the building instructions and constraints within the workflow process template. For example, previous services may have annotated the template to provide 221205 743380 -26 information of the previous services and the initiator in the workflow process. The initiator has been waiting for this signal, as shown by the method 130 in Fig. 2B. The workflow process assembly ends at 125. Fig. 2B, method 130 shows the execution phase of the Just-in-Time workflow 5 process. Method 130 starts at 132 at the initiator and typically starts after 105 in Fig. 2A. Method 130 loops at 134.until the assembly complete signal is received from 121 by the initiator. Once the assembly complete signal is received, the initiator (or the current service at subsequent iterations) at 136 sends the actual task (or job) information, data files and commands or their database references to the next service in-line in the 10 workflow process. The next service, at 138, becomes the current service. It receives the commands and data from the initiator and it executes its specific service on the task data according to any relevant constraints specified in the workflow process template and/or external constraints (this being referred to as "performing" the task). The result of performing the aforementioned specific service is referred to as an "outcome" of the task 15 that has been performed. Then at 140 the current service determines, typically from the workflow process template, if it is the last service in the workflow process. If it is not then the current service forwards its output data and commands onto the next service in line by executing 136, and so on until a current service determines, at 140, that it is the last service in the workflow process. At 142 the current service signals the initiator that 20 the execution phase has completed and thence the execution phase ends at 144. Any errors etc can also be reported to the initiator at this point. Typically the services involved in the execution phase will provide some incremental modification, processing or other benefit to the task data, thereby causing the workflow process to execute the desired behaviour as described in the workflow process template. The services can accumulate 221205 743380 -27 status and error information for the last service to forward to the initiator. However, it will be obvious to those skilled in the art that several alternative behaviours are possible for accumulating and reporting this kind of information. The end of execution phase signal sent to the initiator at 142 is accepted by the 5 initiator at 154 in Fig. 2C, method 150. The initiator can begin to execute the loop 152 & 154 after completing 136 from method 130 in the execution phase. Method 150 is the disassembly phase of the Just-in-Time workflow process. On detection of the signal from 142, looping at 154 ceases and the initiator executes 156. The initiator can optionally de instantiate itself at the end of executing 156. That matter is implementation dependent. 10 At 158 the next service (immediately in sequence after the initiator) becomes the current service and determines if it is the last service (typically by consulting its copy of the workflow process template). If the current service is not the last service then execution proceeds to 160 at which the current service sends a de-instantiate command to the next service. At 162 the current service de-instantiates itself. The cycle repeats from 15 158 as the workflow process disassembles itself until the last service is reached at which execution moves from 158 to 164 and the last service de-instantiates itself and the workflow process and disassembly method both end at 166. The combined methods of Figs. 2A, 2B and 2C comprise sequential and non interleaved methods of workflow process assembly, execution and disassembly. This first 20 embodiment is suitable for enabling, supporting and enhancing single-shot workflows in which human interaction tends to occur only at the beginning of the workflow. This suitability is because of the latency between the assembly process responding to an external constraint, such as user interaction, and the subsequent execution phase. Some 221205 743380 -28 example use-cases for this first embodiment include print runs, process-and-save workflows, or process-and-send workflows or similar. Second embodiment. A second embodiment of the disclosed JITW arrangements is shown in Fig. 5A, 5 method 400. Method 400 comprises an interleaved workflow process assembly and execution method. The disassembly method 150 of Fig. 2C is also applicable to the second embodiment. The method 400 begins at a step 401 where a workflow process initiator executes just as for the first embodiment. At a step 403 the initiator analyses the workflow process 10 template supplied to it or referenced to it and at a step 405 it selects and instantiates the next (first) service of the workflow process. At a step 415, the initiator (or the current service at subsequent iterations) applies the task data or event stimulus to the instantiated (next) service, thereby causing that next service to commence its execution phase. At a step 407 the next service becomes the current service (i.e. the current end of the workflow 15 process chain assembly) and tests the workflow process template and/or external constraints to determine if it should be the last service of the workflow process assembly. If the test returns false, execution continues to a step 409 and a subsequent step 411 at which functionality is the same as described for the step 109 and the step 111 in Fig. 2A. After the step 411, execution loops back to the step 415 and the current service passes its 20 output data and output stimulus to the next service and then it hands over control. Eventually, a current service determines at the step 407 that it is the last service in the completed workflow process and execution moves to the step 421 where the initiator is signalled that workflow process assembly and execution are completed and the method ends at a step 425. The initiator continues from the step 152 in the method 150 of Fig. 2C 221205 743380 -29 and initiates the workflow process disassembly as previously explained for the first embodiment. The second embodiment and the first embodiment allow a workflow process to be executed multiple times between assembly and disassembly. If the disassembly 5 method of Fig. 2C is delayed by the initiator then an assembled process might have a second execution phase initiated by the initiator. This behaviour may be convenient where multiple identical workflow processes are required with the same template constraints. Typically, the multiple execution phases would be independent, where the instantiated workflow process 'engine' would be re-used without the overhead of 10 disassembling and re-creating it. The second embodiment provides a workflow process behaviour such that a workflow process is assembled and its individual services execute their task-related processing in a follow-on method that chases the workflow assembly. This behaviour provides for better interactivity with users as will be shown later in relation to Fig. 6. 15 Third embodiment. A third embodiment is shown in Fig. 5B, method 450. This embodiment is very similar to the second embodiment with the addition of a step 467. The method 450 corresponds in most respects to the method 400, with steps 451, 453, 455, 465, 457, 459, 461 and 475 of the method 450 corresponding to the steps 401, 403, 405, 415, 407, 409, 20 411 and 425, respectively of the method 400. The step 467 is inserted into the method 450 after step 465, by contrast with the method 400, enabling a current service that has been appended and that has completed its own execution to de-instantiate itself prior to the next service executing and processing the task data and/or stimulus. This self de instantiation of services within the workflow process means that a separate de 221205 743380 -30 instantiation phase is not required and so there is no step in 450 analogous to 421 in 400. (Note that in the first iteration through the loop, step 467 is null as there is no "current service" yet defined.) The third embodiment provides a workflow process behaviour such that a 5 workflow process is assembled and its individual services execute their task-related processing and then de-instantiate in a follow-on method that chases the workflow assembly. This behaviour, in a similar manner to the second embodiment, provides for better interactivity with users. The third embodiment also reduces the need for the control feature of the 10 initiator and the need for signalling from the last service in the workflow process chain to the initiator. In fact, an initiator is not required in the third embodiment. The first service in a workflow process may itself be an initiator because it no longer has much special management responsibility compared to that required by initiators in the first and second embodiments. 15 This totally interleaved method 450 provides strong de-centralisation of the features of the workflow process chain, allowing a chain to continue processing a workflow even though most of the chain has disassembled, therefore not with-holding expensive network resources from other activities. For example, if a particular service had a high processing latency, or awaited an event stimulus that had not arrived, then only 20 the very local portion of the workflow process would be instantiated near that service. Preceding and succeeding services need not be instantiated any more, or yet (whichever is applicable) and therefore the network resources would be largely available for other execution of other tasks. In other words, while a network resource is not being used at all, it can be regarded as being fully available. While the resource is being used, it may be 221205 743380 -31 unavailable, or alternately, it may be partially available, ie less available than when not being used at all, but not unavailable. Thus, for example, a printer that uses a print queue to organise print jobs has reduced availability as the queue fills up, but does not become unavailable unless the queue is full. This is a significant advantage of the disclosed JITW 5 arrangements. Not only is the workflow engine de-centralised and distributed, it is using precisely only the resources that are required by a small portion (typically a single service) of any executing workflow process. It could be said that the workflow engine is a virtual entity. It has no discrete existence for all workflow processes, rather each workflow process assembles its own engine, uses it in an efficient manner and then disassembles it. 10 Fig. 6, 500 illustrates an example involving multiple user-interactivity points that is applicable to both the second and third embodiments of the disclosed JITW arrangements. If Fig. 6 represented a corporate workflow process such as a purchase request, then user 512 inputs details of the purchase request on a device 514, using, for example a web form service 510. The purchase request is an example of a sequence of 15 tasks, since a number of different tasks need to be performed in order to complete the purchase request. The service 510 can also perform as the workflow process initiator and it instantiates the next (ie subsequent) service(s), by selecting a subsequent network service if it is suitable (ie capable) of communicating with the current network service, and if it is suitable for performing the subsequent task. Service 510 then forwards 20 information (eg information describing the fact that the current task is a first step in the sequence of tasks associated with the purchase request) or references such as the workflow process template and the form input data (noting that the form input data is an outcome of the current task, since the form input data results from performance of, ie completion of the current task). As may be seen in Fig. 6, the service 510 is instructed by 221205 743380 -32 the workflow process template (not shown) to instantiate two services. So, returning to the method 450, the steps 455 and 465 would be applied by the service 510 to two parallel, subsequent services 520 and 530. Thence either of the subsequent services 520 and 530 would independently proceed to assemble the workflow process from the step 457, and so 5 on. An advantage of this workflow process bifurcation as shown in Fig. 6 is to allow real-time, zero-notice responses to external constraints. For example, the corporate purchase request workflow process template requires support for two alternative means of inputting supporting information, such as a supplier quotation. The workflow process 10 template intends that the supplier quotation information will be appended to the purchase request form data in some way and potentially processed with it. The second and third embodiments can support this emergent functionality of the Just-in-Time workflow process by passing execution control to both of the services 520, a copier scan service implemented within copier 522, and 530, an electronic document attachment service (ie., 15 a subsequent service) operating inside computer 532. At 570 workflow process execution effectively proceeds to the steps 520 or 530, but not both. In practice, service execution would likely commence at both the step 520 and 530 and then an event wait or similar external constraint wait (these being further constraints and further events) would ensue at both services. Then whichever service (ie., subsequent service) received its event 20 stimulus (this being an outcome of the current task or a characterising parameter of the current event) first, would reactivate the workflow process and allow workflow process execution to continue downstream via a junction 580, etc. The merge point at 580, Fig. 6 does not typically mean a data merge, but represents alternate return paths for execution of the workflow process. 221205 743380 -33 Now that the workflow process of Fig. 6 is suspended at 520 and 530, a user 534 may arbitrarily, and at zero-notice, decide which input method will be used for the required quotation document. The user may approach the copier 522 and enter the workflow process ID (as may have been indicated at 514 and later at most devices such as 5 522) and scan a hardcopy document using the copier facilities and thereby causing the event stimulus wait at 520 to be completed and allowing 520 to control the subsequent workflow process propagation. A workflow process ID can be merely a unique identifier that is common to all instantiated services in a workflow process, established through parameter passing at service instantiation. 10 Alternatively, the user 534, may, as shown, approach the computer 532 and cause the service 530 to execute, attaching an electronic quotation document to the workflow process, where-upon 530 takes control of propagating the workflow process via 580. It may be seen that a significant advantage of the disclosed JITW arrangements is to allow arbitrary decisions by human users (or by equivalent automatic processes) at 15 zero-time, within the constraints set by a workflow process template and the external constraints implicit to a particular service type. It may also be seen that another significant advantage of the disclosed JITW arrangements is to allow alternative input of differing document types, specifically electronic documents (at 532) or hardcopy paper documents (at 522). Thus, a Just-in 20 Time workflow enables a user to make an arbitrary or unplanned, zero-notice decision about a parameter or data portion of a workflow process. It may also be seen that another significant advantage of the disclosed JITW arrangements is to allow location-dependent execution of a workflow process. In Fig. 6, service 530 could be a similar but alternate document scanning service to that of 520, and 221205 743380 -34 being provided by another physical duplicate (not shown) of copier 522, but in a differing physical location. Thus, a user may select whichever service they wish to use by parameters such as physical location, or input document type (electronic or hardcopy) and so on. 5 It may also be seen that another advantage of the disclosed JITW arrangements is to accommodate the failure or absence of arbitrary services or devices in a network. As a workflow process self-assembles, the failed services will be avoided. Furthermore, a similar method can be used to perform load-balancing of services within a network environment. One of the constraints imposed on the self assembly of a workflow process 10 could be a test of service or device workload. For example if a printer has a heavily loaded job queue then it might not be selected and appended to a workflow process because the preceding service could be instructed by the workflow process template to test the printer's workload status as a constraint. A more capable workload management method can alternatively be implemented 15 using the Just-in-Time Workflow method: a job might be apportioned between several similar devices (e.g. printers) according to external constraints such as speed, quality, other workloads on the devices and also cost of printing at each device. The capabilities depend on the level of detail of constraints that are included in a workflow process template or in a service's behaviour. It is easy to see that a workload management service 20 could be listed for assembly in a bulk printing-type workflow process template, thereby allowing complex control of printer workload by that specialist service. There is a trade off available to an implementor of a Just-in-Time workflow system: maintaining a high level of generality and simplicity to the Just-in-Time workflow services' interaction and communication capabilities is expected to be cost-effective and to support wide 221205 743380 -35 applicability, and is balanced by provision of specific services to provide more complex or specialist control; whereas, an alternative Just-in-Time workflow system could be made more specialised, being widely sensitive to many specialist external constraints and requiring a higher-level of interaction and communication capability for each service 5 comprising the system. Continuing the description of Fig. 6, the workflow process propagates from 520 or 530 via 580 through any further services (590) that were instructed by the workflow process template and thence into 540 a print service. Print service 540 sends its output data to printer 550, which prints the appropriate hardcopy document for the workflow. As 10 is shown, there is a second output from print service 540 that proceeds via 560 to potentially other services until the workflow process ends. This kind of workflow process bifurcation as shown at 540 may behave differently from that occurring at 570. A purpose of the bifurcation at or just after 540 is to allow the workflow process to execute divergent processes that are not expected to re-converge or merge at a subsequent node in the 15 workflow process. So, as shown in Fig. 6, 500, the workflow process causes a record of the purchase process workflow instance to be printed at 550. This step might represent many possible similar occurrences such as printing a purchase order, or logging the workflow or creating an audit trail, etc. The other branch of the workflow at 560 may continue with differing output from 540 to that sent to 550. For example, 540 may 20 perform a pass-through function to 560, passing the data output by previous services at 590 to 560 without affecting it. 560 may then proceed to propagate the workflow process to further services. Fourth Embodiment 221205 743380 -36 Fig. 7A shows a JIT Workflow method 600 that supports two-level constraint testing. This method provides a more efficient separation of constraints into two levels, such as static and dynamic constraints, or template constraints and external constraints. Method 600, for instance, permits the template author to avoid the need for anticipating 5 all external constraints of significance when authoring a particular workflow process template. Method 600 steps 601, 603, 605, 615, 617, 607 and 625 are substantially the same as the corresponding method steps of the method 450 in Fig, 5B, namely the steps 451, 453, 455, 465, 467, 407 and 475, respectively. 10 When the method 600 execution reaches a step 609, the current service checks the process template constraints and selects a potential subset of next services from the available pool of networked services. These potential services are informed (ie notified) at 609 that they are potential next services of the workflow (involving passing of a specific workflow ID, for instance and the URI of the current service communicating with 15 them). At 623 the current service checks to see if the subset of potential next services is empty. If it is empty then the workflow process throws an exception condition at 619. There are various possible actions that can be taken from this point (none shown), including a wait and retry for suitable services to appear on the network and possibly 20 involving posting of the intermediate process data to a database for a temporary period, or self-disassembly of the workflow process (being the current service de-instantiating since all preceding services have already de-instantiated), or an exception message might be thrown to or logged by a higher authority such as an administrator's machine or similar 221205 743380 -37 thereby indicating that the networked service domain might not have the capability or flexibility to support the workflow process template in all cases. If the test at 623 returns a non-empty subset of potential next services then method 600 continues to 625 where the current service makes a selection from the subset 5 of the service or device that it prefers to make into the next service of the workflow process. This step 625 may involve further analysis of constraints such as cost, quality, etc that might have been preset in a template or by user input data. At step 627 the current service enquires if the next service considers itself available to be appended to the workflow process. If the selected service replies in the 10 negative to the current service then method 600 returns via 621 where the selected service is removed from the subset by the current service and thence to 623 again. The selected service decides whether it is available based, typically on dynamic external constraints such as whether it has sufficient processing capability (given other tasks that might be underway), whether it has sufficient consumables (if a printer for example), and so on. 15 This level of detail, and particularly this private detail can be analysed by the potential next service rather than being broadcast to the current service for analysis, thereby simplifying the JIT Workflow system implementation. When a selected next service decides that it is available or even suitable for the requesting workflow process, it replies in the affirmative to the current service at 627 and 20 the current service instantiates it and appends it to the workflow process at 611 and method 600 loops back to 615 where the current service provides data, etc to the next service as previously described for other embodiments. This method 600, as has been discussed, has several advantages over earlier methods. It allows partitioning of constraints such that communication of significant 221205 743380 -38 information between services is not required, nor is a service required to be capable of analysing unfamiliar constraint information The method 600's steps 609, 623, 625, 627 would typically require some activation of the selected next services even before those services have indicated their 5 availability and been appended to the workflow process. There are several methods of performing this interaction and some are more economical than others. For instance, in general, it will not be necessary to fully instantiate any or all of the subset of next services between 609 and 625 in order for them to respond at.627. For example, a light-weight service manager might exist in each physical node or device that can respond on behalf of 10 all services within these. This light-weight service manager could respond to enquiries such as those made at 609 by the current service as to which services are suitable as required by the template constraints. Then at 625 when the current service selects a preferred next service, the service manager might also respond with information that it knows about the dynamic availability of the preferred next service, again without 15 instantiating that next service. Thus, the service manager, operating as an assembly helper, is not explicitly recognised by the current service or by the self-assembling workflow process. This implementation reduces the need for significant numbers of potential next services to be instantiated and then de-instantiated, thus avoiding the wasting of resources. 20 There are alternative operating modes for the method 600, including incorporation of the service manager as a support module into all services, thus having services briefly instantiated to perform this management & communication process and then de-instantiate themselves if they will not form part of the workflow process. Another alternative implementation could involve the service manager instantiating the preferred 221205 743380 -39 next service earlier in the method 60, at or about 615 or 617 so that the next service can make its own detailed decision about its dynamic availability based on external constraints. If the next service subsequently decides that it is not available then it will de instantiate itself at 627 or 621 after informing the current service, perhaps via the service 5 manager, of its unavailability. Fifth Embodiment Fig. 7B, shows a JIT Workflow method, 650 that also supports two-level constraint testing and also self-selection of the next service in the workflow process. This method also provides a more efficient separation of constraints into two levels, such as 10 static and dynamic constraints, or template constraints and external constraints. It also efficiently supports the use-case example in Fig. 6 by allowing potential next services to make their own decision about their availability for a workflow process and to self-append themselves to the workflow process requesting them. Method 650 steps 651, 653, 655, 665, 667, 657 and 675 are substantially the 15 same as method 450's steps 451, 453, 455, 465, 467, 407 and 475, respectively. Method 650 steps 659, 663 and 669 are substantially equivalent to method 600 steps 609, 623 and 619, respectively. When the method 650 execution reaches the 'no' condition for the empty subset test at 663, the current service goes idle awaiting a response from one of the selected next 20 services. In this method 650, the next services or their service managers wait for external constraints to be satisfied before they respond that they are available. For example, in the use-case of Fig. 6, the potential (in subset) next services 520 and 530 (where 510 is the current service) both await their external constraints being met. Whichever service's external constraints are met first, that service, say 520, for example, informs the current 221205 743380 -40 service, at 661 that it is to be the next service and therefore the next service effectively appends itself to the workflow process. Any other potential next services such as 530, must be informed that they are no longer required or will timeout and de-instantiate. There are many method of informing these redundant next services that they are not 5 required. Explicit communication of this fact may be sent by the current service at 665 once it has received a response from the self-selected next service at 661. Or, alternatively, the self-selected next service might implicitly inform the other next services of their need to de-instantiate by broadcasting openly that it is the selected next service for the JIT workflow process ID for which it was selected. Any other potential next services 10 recognising that JIT workflow process ID in the broadcast would then de-instantiate themselves. Following a next service's self-selection, method 650 loops back to 665 where the current service provides data, etc to the next service as previously described for other embodiments. 15 This method 650, has similar advantages to that of method 600. Once again, as for method 600, a service manager module or process might be useful for managing the communications for potential next services. Sixth Embodiment A sixth embodiment can be explained in relation to Fig. 8 which shows an 20 example use-case of a 'pull' assembly-execution mode of a just-in-time workflow process. The term 'pull' in this context means that the workflow process execution path involving the task data path and processing order is the opposite of the workflow process assembly or command path. The previous embodiments 1 through 5 were all examples of 221205 743380 -41 the 'push' assembly-execution mode in which assembly commands and execution process-data travelled in the same direction. The use-case example of Fig. 8, 700, shows a distributed, hierarchical network search in which user 701 inputs a search pattern to network device 703 which initiates a 5 JIT workflow process comprising services 705, 707, 709 and 711. Service 705 typically manages the distribution of the search and the cognation or other merging method of the results returned from other services 707 and 709. Lines 720, 722, 724 and 726 show the assembly control flow and possible parameter or search task information passing in the workflow process assembly phase. Service 705 identifies appropriate network master 10 index search services 707 and 709 based on template and external constraints (e.g. search criteria entered by the user, user access rights to database servers, etc). Note that service 711 is internal to the device presenting service 709 to the network. In fact, service 711 is not visible to the network and service 705. Service 709, when requested to assemble into the workflow process by 705, offloads some of the search task requested of it to sub 15 service 711. Service 705 also requests a search by service 707, the latter performs the search of its database master index and returns failed or not found or no matches status via 734 to service 705. Service 709 was successful with its master index search, however, rather than immediately communicating its results to 705, it, as mentioned, offloads a more detailed 20 search to service 711 via 726. Service 711 returns its detailed search results (successful in this example) via 730 to service 709, which may cognate those results with any of its own and forwards this data set via 732 to service 705 which then cognates the results with those of other search services (if applicable) and forwards the result via 736 to 703 and user 701. 221205 743380 -42 This use-case example shows how the assembly and execution phases need not follow identical directions in the assembled workflow process. This use-case shows an example of a 'pull' method in which the commands (typically usd for workflow process assembly) and the result data travel in differing directions. As can be seen in the use-case 5 example of Fig. 8, 700, the processing occurs at 709 before it does at 711, which is the same direction as the assembly phase, but the data returns from 711 through 709 to 705, etc, in the reverse direction to the assembly phase. This behaviour can be implemented using a modified version of method 400 of Fig. 5A, for instance. The previously explained behaviour of 400 remains with the exceptions that in 415, the search keywords 10 are passed down through the workflow assembly phase, but no process data is included as it has not been generated yet. At 407, the last service in each branch of the workflow process 707 & 711 detect that they are the final steps. At 421, each of the last services, instead of signalling the initiator, under the instruction of the workflow process template, checks its constraints, potentially executes its processing, and returns the results up the 15 workflow process chain to the preceding services in each case. These behaviours, as opposed to the original behaviour of 400, can be set out in the workflow process template and thus do not require any special modification of individual services, providing the benefit, one again, of generality in the network service pool. Subsequently, when the initiator, 703 via 705 receives the replies from one or more branches within the workflow 20 process chain, it can signal the branch of services to de-instantiate in the normal way 150 such as in Fig. 2C. Device behaviour A method 900 according to the disclosed JITW arrangements is explained in relation to Fig 98. The method 900 shows the execution flow on a device involved in the 221205 743380 -43 JIT workflow process. Each device (or service) in the network pool available for inclusion in a workflow process instantiation is expected to execute the method in 900 to manage the inclusion or chaining of the device and its specific contribution (functionality) to the workflow process or chain. The method 900 supports inter-communication 5 between devices such that workflow process assembly and execution can take place as an emergent property of the inter-communicating services. In one segment of this example, the job is pushed along the chain of devices (referred to as 'push' execution mode), so that as each device completes its sub-job, it transfers the job data and execution control to the next device in the chain. 10 In another segment of this example (referred. to as 'pull' execution mode) the job is transferred to the next device in the chain only when the next device requests that it be transferred. For example, a printer device may not have sufficient resources to store multiple jobs, and therefore would request each job from the workflow chains as it is ready to print another document. 15 Comparing the method 900 to the sixth embodiment illustrated in Fig. 7B, step 905 is substantially the same as step 653, step 915 is similar to step 663, and step 909 is the same as the second part of 657, which tests for an end of the workflow. Steps 911, 913, 915, 917, 919, 921, 923, 925, 927, 929, 931, 933, 935, 937 correspond to 661, a method of self-selection of the next service to attach. 20 The device performs start-up and initialisation steps, 901, then enters state 903, awaiting command stimulus. The command stimuli can include some device-based, software-based or user-based event. The device performs actions in response to different command stimuli. 221205 743380 -44 On receiving an 'External Job Start Stimulus', the device builds a new job and initialises the workflow chain at step 905, then in step 907 invokes a 'Chain Propagate" stimulus on the device. 'Chain Propagate' command stimulus initiates actions beginning with step 909, 5 which involves a test to see if the workflow building process is completed. As with method 100, this test is performed using the constraints known to the building process to see if completion criteria are met. If the test at step 909 is false, execution proceeds to step 911 at which point the instantiated device establishes accessible devices in the network pool that have the ability to form the complete chain. Note that this complete 10 chain is tentative, as each device in the chain will perform this step and can re-route the chain depending on environment current at the time the device is called upon to continue the chain. Each accessible device identified instep 911 is then queried in step 913 to test their own suitability by means of posting a "Suitability Enquiry" stimulus command to each accessible device. At step 915 the current device waits for the results of this request, 15 either at 917 posting an "Availability Indication" to a selected subset of devices that responded to the suitability enquiry with a suitability indication, or killing the workflow and returning to 903 to await further stimuli. Killing the workflow can involve reporting of exception or error condition. If an "Availability Indication" was posted in step 917, then the device waits at step 919 for one of the devices identified as suitable to post a 20 "Chain control request" stimulus. If no stimulus occurs, the workflow is killed. If a "Chain control request" stimulus does occur, step 921, posts a "Chain Propagate" stimulus for the device identified in Step 919. Step 923 then executes the sub-job on the current device via creating a "Sub-job Execution" stimulus. 221205 743380 -45 If the test at step 909 is true, that is, the current device is the final workflow device, execution proceeds directly to Step 923, bypassing the steps which propagate the chain to subsequent devices in the workflow. Step 925 is invoked on each 'next device' in response to a "Suitability Enquiry" 5 stimulus posted at step 913 by the current device. Each 'next device' negotiates static suitability of itself against a set of constraints imposed by the workflow process being built. If the test at Step 927 yields that the device is suitable then the device responds at 929 posting a 'device suitable indication" to the current device, indicating that it is suitable. Otherwise processing on the 'next device' is returned to the wait state in Step 10 903. Step 931 is invoked on the device in response to an "Availability Indication" stimulus posted at step 917. At Step 931 the device confirms its dynamic availability against a set of constraints and some trigger stimulus condition. If the test at Step 933 yields that the device is available, then the process waits for the internal or external 15 stimulus triggered in Step 931, otherwise processing on the 'next device' is returned to the wait state in Step 903. When a stimulus is detected at Step 935, the 'next device' then decodes and requests the control of workflow process chain, then returns to the wait state in Step 903. As previously mentioned, posting the "Chain control request" at step 937 is the condition upon which the current device is waiting in Step 919. 20 Receipt of a "Job Request" stimulus by the current device, from a next device indicates that the next device is ready to receive and process the job. The current device begins at step 939, which checks whether the workflow process is constrained to a 'push' or 'pull' execution mode. If the test yields that the workflow process is a 'push' execution system, the device is returned to the wait state in step 903, as the job has or will 221205 743380 -46 be sent when the sub-job finishes at the previous device (step 957). Otherwise the process is a 'pull' execution system and the device waits for completion of the sub-job at step 941 before posting the job to the next device at step 943. The invocation of the workflow process, via "Sub-job Execution" stimulus as 5 invoked on the current device by step 923, initiates the job request check at Step 945, where again the device checks whether the workflow process is constrained to a 'push' or 'pull' execution mode. If the check yields the 'pull' execution mode, step 946 checks whether this device is first in the chain. If it is, then it already has the job information so the device proceeds to step 951 to execute the sub-job. Otherwise, the device first posts a 10 "Job Request" stimulus in 947 to the previous device then waits for the job information at step 949. If it does not receive the job under certain conditions, the device can kill the wait and return to step 903 for further command stimuli. On the other hand, if the device does receive the job, it again executes the sub-job at 951. Alternatively, if the check at Step 945 yields the 'push' execution mode then the 15 workflow process sub-job task is executed at Step 953. Step 955 checks whether the current device has fulfilled the workflow process' requirements, that is, whether it is the final device in the workflow chain. If not, it sends the workflow process execution control to the 'next device' on the workflow process chain. The device then returned to the wait state in Step 903. 20 Workilow Process Template The previous embodiments one through six were described as utilising a workflow process template to describe constraints on the workflow assembly method. It is also possible to implement the disclosed JITW arrangements utilising a distributed 221205 743380 -47 workflow process template, i.e. where a particular workflow process is described by a group of documents or document parts. The method 900 uses a distributed workflow process template concept. Each device or service contains or references its own workflow process template fragment. 5 Examples of distributed workflow process template fragments are shown in Appendices A, B, and C for a portion of an exemplary purchase order workflow system similar to that shown in Fig. 6 and executed by a method such as 900 in Fig. 9. Appendix A shows an exemplary workflow process template fragment utilised by a PDA device belonging to a network pool of devices capable of being integrated into 10 one or more types of workflow processes. The template fragment is written in XML format following a suitable schema (not explicitly defined here). The template fragment for the PDA begins with line 3, tag <JITconfiguration> indicating that the following XML content is relevant to a Just-in-Time workflow system device. At line 5 the device type(s) is(are) declared for 15 which the template fragment is relevant. Between lines 7 and 12 the workflows to which the device can respond and become involved in are listed, between the workf lows tags. The two workflow examples shown are for a staff purchase, similar to that shown in Fig. 6 and a document search, similar to that shown in Fig. 8. Lines 8 & 9 describe the workflow name, 20 description and initial and final services for the staff purchase workflow. Similarly lines 10 & 11 describe the same features but for a document search workflow. The capabilities of the device within the specified workflows are described between lines 14 & 23 in the capabilities section. Lines 15 & 16 describe the 'User Input Form' capability of the PDA within the Staff Purchase workflow and bind this capability 221205 743380 -48 to a form found in a workflow database on the network. This capabilities description indicates to the PDA what function to execute (bind) when it is performing the User Input Form step in a Staff Purchase Workflow. Similarly, three other capabilities are described and bound, one more for the Staff Purchase, and two for the Document Search workflows. 5 The transform section of lines 25 to 34 indicates the next step of a workflow process subsequent to the current device's activity in a specified workflow. So, for example, if the PDA is performing the initial User Input Form step of the Staff Purchase workflow, then lines 26 & 27 describe to it that the next step it should request of the network pool of devices is an Attach Quote step. Therefore, a workflow process system 10 can be built incrementally by a pool of devices obeying the constraints in their workflow template fragments and using a method of execution and inter-communication such as is shown in Fig. 9, method 900. Appendix B shows a workflow process template fragment for a scanner device that may participate in a staff purchase workflow such as shown in Fig. 6. The details are 15 similar to those shown in Appendix A, with specific entries for the scanner device in the capabilities section, lines 12 through 15, which define the Attach Quote function that can be executed by the scanner and is bound to the scan.exe executable. Also, the transforms section, lines 17 through 20 shows that the next step after Attach Quote is the Print Order step. It may be seen that both the PDA device type and the scanner device type may 20 execute an Attach Quote capability leading to a Print Order step in a Staff Purchase workflow, thereby enabling the alternative workflow routes shown in Fig. 6. Appendix C shows an exemplary workflow process template fragment for a printer that can participate in the staff purchase workflow process. The capabilities section, lines 12 through 15 shows that the printer can perform the Print Order step and is 221205 743380 -49 bound to the print.exe internal function. The transform section, lines 17 through 20 shows that the printer should end the workflow process after execution of its Print Order step. It can be seen that the contents of each of the workflow process template 5 fragments in Appendices A, B and C, being 'workflow', 'capabilities' and 'transforms', applicable to specific device or service types, provide the template constraints information described in various embodiments of this disclosed JITW arrangements. When taken together, for instance, the workflow process template fragments and the specified devices or services that they instruct, utilising the specified template constraints, cause the 10 formation of an emergent workflow process instantiation. The external constraints mentioned previously in various embodiments of the disclosed JITW arrangements are exemplified by events such as the 'submit' button implied within the html form that is bound to the PDA's User Input Form capability in the Staff Purchase workflow, and also exemplified by the scan event (user pressing scan 15 button) implied and expected within the scan.exe function bound to the scanner's Attach Quote capability in the Staff Purchase workflow. Thus, it can be seen how a workflow process template, in a single, centralised form or in a distributed, fragmented form, can control the assembly, execution and disassembly of a Just-in-Time workflow process system and can, in conjunction with a 20 method such as in Fig. 9 or other of the embodiments described herein, enable or support the features described for such a workflow process system, particularly including zero notice constraints, significant flexibility to support real-world requirements, and a distributed workflow engine. 221205 743380 -50 INDUSTRIAL APPLICABILITY It is apparent from the above that the arrangements described are applicable at least to administrative processes in the computer and data processing industries. The foregoing describes only some embodiments of the present invention, and 5 modifications and/or changes can be made thereto without departing from the scope and spirit of the invention, the embodiments being illustrative and not restrictive. In the context of this specification, the word "comprising" means "including principally but not necessarily solely" or "having" or "including", and not "consisting only of'. Variations of the word "comprising", such as "comprise" and "comprises" have 10 correspondingly varied meanings. 15 20 221205 743380 -51 Appendix A: Exemplary XML Workflow Process Template for PDA device <JITconfiguration> 5 <device type="PDA"/> <workflows> workfloww name="Staff Purchase" description="Staff Purchase" initial="User Input Form" destination="Print Order"/> 10 <workflow name="Document Search" description="Document Search" initial="User Search Keywords" destination="Display Result"/> </workflows> <capabilities> 15 <capability name="User Input Form" workflowname="Staff Purchase" description="none" bind ="http://workflowdatabase/forms/staff-purchase.htm"/> <capability name="Attach Quote" workflow name="Staff Purchase" description="none" bind="http://thisdevice/documentbrowse.exe"/> <capability name="User Search Keywords" workflow name="Document Search" 20 description ="none" bind="http://workflowdatabase/forms/usersearch_keywords.htm"/> <capability name="Display Result" workflowname="Document Search" description="none" bind="http://this-device/displaysearch_result.exe"/> </capabilities> 25 <transforms> <transform workflow="Staff Purchase" 221205 743380 -52 step="User Input Form" transform step="Attach Quote"/> <transform workflow="Staff Purchase" step="Attach Quote" transform_step="Print Order"/> <transform workflow="Document Search" 5 step="User Search Keywords" transformstep="Master Search"/> <transform workflow="Document Search" step="Display Result" transformstep="End"/> </transforms> 10 </JITconfiguration> 221205 743380 -53 Appendix B: Exemplary XML Workflow Process Template for scanner device <J ITconfiguration> 5 <device type="Scanner'/> <workflows> <workflow name="Staff Purchase" description="Staff Purchase" initial="User Input Form" destination="Print Order"/> 10 </workflows> <capabilities> <capability name="Attach Quote" workflow name="Staff Purchase" description="none" bind="http://thisdevice/scan.exe"/> 15 </capabilities> <transforms> <transform workflow="Staff Purchase" step="Attach Quote" transformstep="Print Order"/> 20 </transforms> </JITconfiguration> 221205 743380 -54 Appendix C: Exemplary XML Workflow Process Template for printer device <J ITconfiguration> 5 <device type="Printer"/> <workflows> <workflow name="Staff Purchase" description="Staff Purchase" initial="User Input Form" destination="Print Order"/> 10 </workflows> <capabilities> <capability name="Print Order" workflowname="Staff Purchase" description="none" bind="http://thisdevice/print.exe"/> 15 </capabilities> <transforms> <transform workflow="Staff Purchase" step="Print Order" transform step="End"/> 20 </transforms> </J ITconfiguration 221205 743380

Claims (15)

1. A method of performing a sequence of tasks using a system comprising a plurality of network services that can communicate over a computer communications 5 network, the method comprising the steps of: processing a current task in the sequence by a current network service; selecting, by the current network service, a subsequent network service dependent upon (i) the capability of the subsequent network service to communicate with the current network service over the network and (ii) the capability of the subsequent 10 network service to perform a subsequent task in the sequence; communicating, by the current network service over the network, information associated with the current task to the subsequent network service; designating the subsequent network service to be the current network service; defining the subsequent task in the sequence to be the current task; and 15 repeating the processing step.

2. A method according to claim 1, wherein one said network service is selected from a group comprising a network device and a network service. 20

3. A method according to claim 1, wherein: the processing step comprises performing the current task; and the communicating step comprises communicating the outcome of the processed current task to the subsequent network service. 743380 / 153265v3 110309 -56

4. A method according to claim 1, wherein: the processing step comprises extracting parameters characterising the current task; and the communicating step comprises communicating said extracted parameters to 5 the subsequent network service.

5. A method according to claim 1, wherein subsequent to the communicating step, the method comprises the further step of communicating, by the subsequent network service over the network, a readiness to perform the subsequent task in the sequence. 10

6. A method according to either one of claims 3 and 5, wherein subsequent to the communicating step the method comprises the further step of releasing the current network service, thereby making the current network service fully available for tasks other than the sequence of tasks. 15

7. A method according to claim 1, wherein the selecting step comprises the steps of: selecting the subsequent network service dependent upon a predefined set of rules associated with the sequence of tasks; and notifying the subsequent network service of the selection. 20

8. A method according to claim 7, wherein the selecting step further comprises selecting the subsequent network service dependent upon at least one of a further constraint and a further event. 743380/ 153265v3 110309 -57

9. A method according to claim 1, comprising further steps of: determining, after the repeated processing step, if the sequence of tasks has been completed; and if the sequence of tasks has not been completed repeating the selecting, 5 communicating, designating and defining steps.

10. A method according to claim 1, comprising further steps of: determining, after the repeated processing step, if the sequence of tasks has been completed; and 10 if the sequence of tasks has been completed making all network services currently selected for use with the sequence of tasks fully available for tasks other than the sequence of tasks.

11. A system for performing a sequence of tasks using a plurality of network services 15 that can communicate over a computer communications network, the system comprising: a plurality of network devices that can communicate over said network, each network device supporting at least one of said network services, each said network device comprising: a memory for storing a program; and 20 a processor for executing the program said program comprising; code for processing a current task in the sequence by a current network service; code for selecting, by the current network service, a subsequent network service dependent upon (i) the capability of the subsequent network service to 743380/ 153265v3 110309 -58 communicate with the current network service over the network and (ii) the capability of the subsequent network service to perform a subsequent task in the sequence; code for communicating, by the current network service over the network, an attribute of the current task to the subsequent network service; 5 code for designating the subsequent network service to be the current network service; code for defining the subsequent task in the sequence to be the current task; and code for repeating the processing step. 10

12. A computer program product including a computer readable medium having recorded thereon a computer program for directing a processor to execute a method for performing a sequence of tasks using a system comprising a plurality of network services that can communicate over a computer communications network, the program 15 comprising: code for processing a current task in the sequence by a current network service; code for selecting, by the current network service, a subsequent network service dependent upon (i) the capability of the subsequent network service to communicate with the current network service over the network and (ii) the capability of the subsequent 20 network service to perform a subsequent task in the sequence; code for communicating, by the current network service over the network, an attribute of the current task to the subsequent network service; code for designating the subsequent network service to be the current network service; 743380 / 153265v3 110309 -59 code for defining the subsequent task in the sequence to be the current task; and code for repeating the processing step.

13. A method of performing a sequence of tasks, substantially as described herein 5 with reference to any one of the embodiments, as that embodiment is depicted in the accompanying drawings.

14. A system for performing a sequence of tasks, substantially as described herein with reference to any one of the embodiments, as that embodiment is depicted in the 10 accompanying drawings.

15. A computer program product including a computer readable medium having recorded thereon a computer program for directing a processor to execute a method for performing a sequence of tasks, substantially as described herein with reference to any 15 one of the embodiments, as that embodiment is depicted in the accompanying drawings. DATED this 8th Day of April 2009 CANON KABUSHIKI KAISHA 20 Patent Attorneys for the Applicant SPRUSON&FERGUSON 743380/ 153265v3 110309