Re: [xml-dev] Here's what I've learned over the last several monthsabout

[Frank Manola <fmanola@acm.org>]

Roger--

"Separating management from applications" has an important advantage  
that you didn't mention, namely that management frequently doesn't  
have a clue as to what the applications are doing, so the more  
separation there is between management and the applications, the more  
likely it is that management won't muck around with them, and the  
overall system will continue to function........Oh you mean *workflow*  
management   :-)

More seriously, how do you draw the line between "application" and  
"workflow" (or process)?  The Kay article you cited seems to talk  
about applications with workflow as a part of their implementation  
("workflow applications"), not about a complete separation of the  
two.  Also, your description that

>  Applications no longer require any management
>   functionality, and hence are simpler and
>   completely independent of their context or
>   place in the business process. This makes it
>   possible to rearrange the business process
>   at a later stage

makes it sound like, in your definition, an application is what we  
used to call a "subroutine".  Alternatively, if you thought of an old- 
fashioned flowchart, your "applications" seem to be everything that is  
in square (and possibly some other funny-shaped) boxes, and the lines  
and the diamond-shaped boxes are "workflow".  If these are reasonable  
analogies, could you describe again what's new?  That we're passing  
documents between the boxes rather than relying only on shared  
memory / parameter passing?  Remember that in the older style coding  
the "subroutines" had their own (internal) control flow, and so would  
the "applications" in this workflow-oriented approach.

--Frank


On Apr 28, 2009, at 9:43 AM, Costello, Roger L. wrote:

>
> Hi Folks,
>
> Over the last several months I've pored over these extraordinary  
> articles, technology, and book:
>
>   [Article] Building Workflow Applications by Michael Kay
>
>   [Article] Business artifacts: An approach to operational  
> specification
>   by A. Nigam and N.S. Caswell
>
>   [Technology] XProc (XML Pipeline Language)
>
>   [Book] Workflow Management by Wil van der Aalst and Kees van Hee
>
>
> Here's what I've learned:
>
> 1. For years I've heard "Separate the data from the application" and  
> "Separate the User Interface (UI) from the application." I've now  
> learned of the importance of separating process management from  
> applications. Check out this graphic:
>
>   http://www.xfront.com/separate-process-management-from-applications.gif
>
> Here's what a workflow management system does:
>
>   The management system ... ensures that no
>   steps [in a process] are skipped, that they
>   are carried out in the correct order, that
>   tasks can be performed in parallel where
>   possible, that the correct applications are
>   called in to support a task, and so on.
>
> Separating management from applications has a number of important  
> advantages, including:
>
>   Applications no longer require any management
>   functionality, and hence are simpler and
>   completely independent of their context or
>   place in the business process. This makes it
>   possible to rearrange the business process
>   at a later stage.
>
> (See p. 147-148 of van der Aalst's book for a complete list of  
> advantages)
>
>
> 2. Process is important. It can make or break a system.
>
>
> 3. Recently it dawned on me that NVDL is a micro workflow management  
> system. How so? Here's my (short) explanation:
>
>   http://lists.dsdl.org/dsdl-comment/2009-04/0005.html
>
>
> 4. XProc is very cool: you create a .xpl file which defines a  
> process (pipeline), hand it off to an XProc processor (such as Norm  
> Walsh's Calabash) and the processor takes care of managing the  
> pipeline. XProc can be used to manage interactions with Web  
> services. Here's an example of an XProc pipeline interacting with  
> multiple RSS feeds:
>
>   http://lists.w3.org/Archives/Public/xproc-dev/2009Apr/0104.html
>
>
> 5. A workflow management system invokes a task, providing it with  
> the appropriate information and resources. The task may be activated  
> either by:
>
>   - invoking an API, or
>   - sending it a document
>
> "By API" means that you focus on creating a standard interface, i.e.  
> specify a subroutine's name, parameters, and return value. Thus, you  
> create an Interface Control Document (ICD).
>
> "By document" means that you focus on creating a standard XML  
> vocabulary. Thus, you create a Data Specification.
>
>
> 6. There are benefits to having a workflow management system manage  
> the flow of documents rather than managing API calls. The benefits  
> particularly accrue when the documents are based on key business  
> documents, i.e. the documents used in the actual running of a  
> business. One benefit is that you have an operationally centered  
> view of the business: the process definition mirrors the business  
> process and the documents mirror the key business documents. This  
> produces a model that is a rich representation for analyzing and  
> managing the business.
>
> (See the Nigam/Caswell and Kay articles for further elaboration on  
> the benefits)
>
>
> Based on what I've learned, here's my brief sketch of how to create  
> systems:
>
>   Step 1: Identify the process
>
>   Step 2: Identify the key business documents needed by the process
>
>   Step 3: Identify the data used by the workflow
>           management system to route the business
>           documents through the process (van der Aalst
>           calls this "case attributes")
>
>   Step 4: Create a data specification for the business
>           documents, i.e. write prose that describes the
>           data at an operational level
>
>   Step 5: Derive implementations from the data specification,
>           i.e. create an XML Schema, Schematron schema, and
>           so forth
>
>   Step 6: Create a process definition, e.g. create an
>           XProc file and/or a BPEL file
>
>   Step 7: Create your User Interfaces and databases
>
>   Step 8: Deploy your workflow management system
>
>
> That's a snapshot of what I've learned. I hope that you've found it  
> useful. I welcome your additional insights.
>
> /Roger
>
> [1] Michael Kay: http://www.stylusstudio.com/whitepapers/xml_workflow.pdf
>
> [2] Business Artifacts: http://findarticles.com/p/articles/mi_m0ISJ/is_3_42/ai_108049865/
>
> [3] XProc Tutorial: http://www.xfront.com/xproc/
>
> [4] Workflow Management: http://www.amazon.com/Workflow-Management-Methods-Cooperative-Information/dp/0262720469/ref=sr_1_1?ie=UTF8&s=books&qid=1239573871&sr=8-1
>
> [5] NVDL tutorial: http://www.xfront.com/nvdl/
> _______________________________________________________________________
>
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
>
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> subscribe: xml-dev-subscribe@lists.xml.org
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>