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

[James Fuller <james.fuller.2007@gmail.com>]

On Wed, Apr 29, 2009 at 11:07 AM, nico <ndebeiss@gmail.com> wrote:
> Hello
> I do not think it is possible to XMLize everything as it means that all
> possibly needed data treatments and data sources have been identified and
> standardized in order to be triggered in a declarative way.
> What about somebody who wants to use another data language like JSON in
> order to interact with its Ajax GUI ?
> I think XProc should let the door open to a java written step, providing a
> class we could extend in order to write a special transformation step.
>

the door is wide open in the form of an extension step ... suggest
over at www.exprog.org.

cheers, Jim Fuller

> Regards
> Nico
>
> 2009/4/28 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
>>>
>>
>>
>> _______________________________________________________________________
>>
>> 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
>>
>
>