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

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

a few comments

>
> 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")

i personally would switch position of step 3 with 1 (and merge 2 and 3
together) ... data is the both the input and output of any process and
doing a first pass on this up front will inform one how to look at the
(probably imperfect) process. Also note that data tends to survive
much longer then the process (or code) that created it.


>   Step 4: Create a data specification for the business
>           documents, i.e. write prose that describes the
>           data at an operational level


the moment you create an artifact that describes something the problem
arises of maintaining that artifact ... I have tried long and hard to
be a literal and pragmatic with data definitions; oddly enough XML
seems to be a very good format to create meta data descriptions ...
can even help in migrating data schema/layer changes which is imho the
number one issue facing enterprise developers working on critical
systems.

>   Step 5: Derive implementations from the data specification,
>           i.e. create an XML Schema, Schematron schema, and
>           so forth

what data are you speaking about ? or is it the model ? in an 'all
xml' architecture this is fine.

>   Step 6: Create a process definition, e.g. create an
>           XProc file and/or a BPEL file

I am starting to get leary about this approach ... also I think you
are switching context a bit between 'business' tier workflows e.g.
people doing stuff perhaps with documents and 'business logic'
workflows which hide in a program somewhere.

BPEL is targeted at the former whereas the later, programmatic
workflows that you and I work with under the hood of any software
program XProc maybe used.

I have seen a lot of a/buse with Apache Ant where one can very quickly
prototype and deploy working code that takes the place of business
logic where we probably would have written code. This really works,
but I have always had a nagging feeling that its not correct. XProc is
good wherever you are working with XML and related technologies .. the
further away you go from that the more you will be shoehorning XProc
to do your bidding.

I think where XProc will be *very big* is with power users ... people
who are not necessarily programmers but want to edit programmatic
workflows.

>   Step 7: Create your User Interfaces and databases

and both UI and databases could be abstracted as an input/output in XProc ...

>   Step 8: Deploy your workflow management system

which is a big issue ... during XML Prague I mentioned the idea of the
need for XML to have its own application deployment approach ... my
analogy was 'CPAN for XML'.

Amazon, Salesforce, Google Apps, etc .... are all creating ecosystems
with coarse grained functionality ... successful dynamic languages
have robust archive and deployment mechanisms (Perl has CPAN, Ruby
gems, etc, java WAR/jar, etc)

I will be making some related announcements soon along the lines of an
equiv for XML (speaking with potential sponsors now) ... provisionally
calling it XML Archive & Deployment Network. Anyone interested give me
a shout off list.

cheers, Jim Fuller