[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Here's what I've learned over the last several months abou
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|