Christopher Spottiswoode comments from a Metaset/MACK point of view
(on Wolfgang Schulze, Markus Böhm, Klaus Meyer-Wegener, Services of Workflow Objects and Workflow Meta-Objects in OMG-compliant Environments):

(Please first read my Introduction to these comments on your papers.)

Firstly, I liked your demand for tight integration of business entity objects and workflow objects. (See also [Paul] on the "Business Process / Business Object" distinction.) In MACK, of course, both are merely typologies, though perhaps I should add that the process typologies are, naturally, a much more integral part of the management of that ubiquitous "time component of data", as well as being intimately concerned with that likewise ubiquitous coherence-and-consistency imperative that is also central to MACK.

Now your 8 Statements:

1. Workflow Objects are fractal structures

Certainly! But only up to a point, which in the realtime dimension is that of the finest realtime granularity that is ever meaningful to humans during any UI activity.

2. Workflow Objects are (CORBA) objects with specific services

This sentence from your opening is certainly true: While business entity objects represent more static concepts, workflows have a more dynamic character because they represent the flow of work through the business. But from there on, I’m afraid I must diverge!

Wolfgang, the bad news for me is that it must seem that I am picking on such a friendly person as our e-mail correspondence has shown you to be ... but you will surely have seen from my paper and faq that this particular point of yours is one that will stimulate me to many words! Your thesis, after all, if tenable, would be a good counter-example of my own under the "innocent questions" heading in my paper. In [1] I recalled them and also drew attention in greater detail to the time issue as compounding the "challenge" to OMA-supporters. So the stakes are high for me!

The good news for me, on the other hand, is that I can look forward to a rational and enjoyable discussion, even though the discussion of such large and often rather abstract-aesthetic issues do after a while tend to become "theological", with all the non-communication that such a character usually implies!

I shall now try to be very careful about my use of words, because I know from recurrent past experience that I seem to be coming from somewhere very different from the usual positions, hence that I too readily use a word in a very different way from what the usual reader understands.

So, please! Do not hesitate to ask for the clarification - especially of specific words as I seem to use them - that will surely often be required...

A general comment on what now follows is that - considering that I am not allowing myself to describe the detail of MACK yet - all I can hope to achieve is a realization that a radical and already extensively-pursued alternative might exist, rather than that it does so.

In effect I have strongly asserted this interlocking set of - for me - key observations:

(Please excuse that blanket assertion, but it is CORBA we are discussing now. However, let me remind that the context of the problem was that of complex collaborations between objects, where, even when one object makes a CORBA-style request on another object (and not on yet another one instead), the requester has implicit expectations on the nature of the resulting behaviour beyond what is explicit in the request itself. That is even more of a breaking of encapsulation than MACK has! With MACK, a user implicitly makes a request on the entire model, and it is Metaset as the MACK-realization that finds out what other objects are to be involved. That is, of course, in the spirit of the OMG’s original generalized object model. So when, as above, I say that MACK has implementation inheritance, the implementation that is inherited is state+metadata only, since the actual realtime behaviour is determined by the system from that information, while the basic "operation" is a rather different concept.)

I shall now try to illustrate those points in my answers to your more specific statements:

States of Workflow Objects

First a general comment again: I approve of your "state-based" approach to workflow!

However, your state-transition-diagram is, I think, rather too based on conventional computer processes to have the highest degree of abstraction. For example, a "failure" event can strike during any one of the transition states, whereas conventional computer process management is typically as undiscriminating as your diagram (though I appreciate that your diagram is merely illustrative rather than final).

The MACK process or operation, on the other hand, is qualitatively different, as is its correspondence with human activity-items. (It also permits a great simplification of the whole concept of workflow, thanks to enabling that much-vaunted reflectivity on processing too. See "MACK workflow" below.)

Service availability

My initial reaction here is that that set and classification of services is both too simple and too complex.

On the one hand, operations such as transfer and delegation, for example, are too simple - just plain like that - to support the delicate diplomacy and distribution of responsibilities that might be required. True, you provide for any one operation to be a nested workflow in itself, but a nested structure does not permit a more intricate mixing of operations from different levels for more complex needs. Here we are back at that complex collaboration problem where I started.

Thus extension via type-specific functionality cannot be general-purpose enough. (That argument is a virtual repeat of the second bulleted point under 2 above.)

On the other hand, as a whole the picture is unduly complicated by having to cater for that particular set of states. For example, aborts might be managed by an outer layer.

Again, as you say, your exposition is merely illustrative, but I think I have raised some structural problems that aren’t so easily provided for within any framework such as you have described.

Or am I barking up the wrong tree somewhere? Please correct me if so!

Your last paragraph asserts: To sum up, all of the mentioned services should be offered and realized by the workflow object itself and not by some other infrastructural element. In contrast, Metaset has its (infrastructural?) kernel functionality in control, but, while driven by attached users, it is guided totally by application objects in the form of typologies (many of which might also be in code-generated form hence nicely "part" of the kernel from an execution point of view).

Such locally-central control is part of what is meant by Metaset’s being an "application operating system". That also puts the finger on another function of operating systems, namely, to manage resource contention. An added advantage of a MACK-realization’s integrated workflow management is then that resource management is closely part of the picture too, which is easily seen to offer many opportunities for optimization of end-user convenience as well as efficiency.

But it also easily seems that it will horribly complicate design! After all, there is usually a sharp dividing-line between such functions, which more-or-less coincide with the lower two tiers of the common 3-tier architecture. From a MACK viewpoint, that division is an oversimplification, and while its removal might seem an unmanageable complexification, the easiest way for me to respond now is merely to note that Metaset was designed to help people simplify complexity, in the CASE domain as in many others! More to the practical point, we might note that in a MACK-compliant world smooth version migration will eliminate many of the reasons for a division between the two functions of database management and workflow management taking business rules into account (cf. the old "program-data independence" justification for DBMS, that, incidentally, is virtually contradicted by the very idea of OODB). That division, I allege, is one of the artificial complications in the present that is best cut out.

You then go on to note: The workflow object gains a life of its own and is visible as an entity throughout a software system. In Metaset, actual workflow processes play that role in an integrated way.

3. Workflow Meta-Objects are first-class objects

(where by a Workflow Meta-Object you understand a set of procedural rules or a workflow script in some formal language.) How do you respond to Mark Baker’s flat statement in his paper that "Work items and lists are outdated."? (I would agree with him strongly!)

I am very happy to see this sentence: When actor-selection is done by some specific algorithm (e.g. based on some trading-approach), it is very hard to capture this policy in the workflow description. It underlines the importance in a MACK-compliant world of its integrated market picture!

4. Workflow Meta-Objects are the key to workflow reuse

You open with this sentence: Growing exploitation of workflow technology within an organization may quickly lead to the introduction of a vast number of different workflow types. Would you say that that accords at least partly with this statement in my paper: "But either such an object [one single workflow object for any one business object in all environments] would again be unmanageably complicated or there would in real life be an explosion of such larger granules in an attempt to compartmentalize the complexity." ?

Anyway, you then go on to say: In order to keep the set of workflow types manageable (minimal and structured), it is necessary to reuse existing workflow types. Reuse here means the possibility to build new workflow types by composition of existing ones. But you seem to mean manual composition, even though repository-assisted. Is that so? Surely not!

5. The Workflow Facility can be built using existing CORBAservices

This is, of course, where my problems with Workflow-through-CORBA really start boiling over!

Firstly, simplistic ACID transaction management is not suited to every real-life workflow expectation that users have gained from everyday manual practices!

For example, the "Isolation" part of ACID is in general incompatible with "long transactions" and the resulting inacceptability of the pessimistic or consistency approach to resource reservation. The thereby-sought serializability oversimplifies for mere technical convenience [Ralph].

Together, such considerations help explain why there is all that work going on in Germany on "advanced transaction management" [Stefan].

Secondly, trying to embed the general procedure- or interface-defined object’s behaviour within your realtime meta-objects places intolerable constraints - in general - on the algorithm-time-granularity of object definition [1, Jeff(Marímba), Ralph].

Thirdly, considering the emphasis in MACK on what I called relativistic realtime, as distinct from the naïve variety, I must repeat this statement from my paper: ‘Conventional objects make the clearest sense in the "naïve realtime" of implicitly synchronous views of data as pioneered by "on-line realtime" mainframes in a database world of "short transactions".’ The misconception represented by the naïve form then ties in well with the ACID restriction!

I could go on and on but I will spare you all... The point is clearly not that there isn’t any difficulty that needs addressing. It is rather that there are many artificial complications out there that can be cut away if one starts with an appropriate conceptual foundation. I can’t yet show you in detail that MACK is that foundation, but I have tried to indicate some fundamental reasons why the present OMA - and indeed all interface-inheritance-based object models - are inappropriate in ways that MACK is not.

6. A Workflow Facility should be lightweight

Any discussion of workflow engines is irrelevant to MACK, considering its integrated workflow management discussed more fully towards the end of my comments under your 2 above.

7. The Workflow Facility shall integrate with Business Objects

100% right, in MACK too! For the above reasons, however, I would say that it is wishful thinking to believe that the OMG is on the way to that architectural target.

8. The Definition of a Workflow Facility is of high priority

100% right yet again!

Your final sentence, Introducing a standard may hopefully prevent proprietary solutions from becoming established. while right, of course, also presupposes the appropriate standard. All I can comment there is this: "But the emperor only has some old underclothes!"

Finally, on your Conclusion, good luck with your prototype, but bear in mind the possible limitations I have noted! (Limitations to workflow flexibility using nested workflows is the easiest to test. The mismatch between the interface inheritance approach and workflow realtime is the real challenge, and, remember, it will come out most strongly in a situation of extensive collaboration, especially when there are multiple levels of refinement in inheritance hierarchies, and various run-time environments are catered for.)

I’d be most grateful to be kept up to date on your efforts, Wolfgang, for your chosen field is crucial to the future of integrated and pervasive computing!

Workflow within MACK

Having criticized your work so, I can’t leave myself totally beyond criticism! Here are a few dense paragraphs on the quickly-materializing Metaset approach to our chosen problem-area.

I start with my comment in my paper (under the "innocent questions" heading, challenging the OMA’s classical object model) about the large orthogonality between workflow-endproduct-intrinsic aspects and environmental aspects which should be an opportunity - not a problem - for workflow design. It invites a general-purpose approach to workflow design, as for example the CPM (Critical Path Methods) people might easily agree.

Consistent with its overall style, Metaset is pursuing a fully-general line. Starting with a definition of the workflow endproduct (e.g. a customer order), and inviting help where necessary - during design-time and/or run-time - from application designers, domain experts and/or operators, even Metaset’s initial (and of course typology-driven) facilities will illustrate how to deduce and manage any workflow in terms of environmental aspects such as production resource specifications, organization structure and responsibilities, floor plans, control points, etc.

Where such factors are not sufficiently known or modelled yet, Metaset will invite their modelling in terms of virtual resources representing abstract states of the full realworld situation (That technique was much exercised in "IDIOM" [3(firstly)]).

That whole process may seem unduly difficult, but MACK enables its resolution through a combination of several factors: the inherent non-procedurality of typologies (cf. declaratively-specified constraints), the peculiar MACK definition of operations and RE-methods, the MVC-like management of the interface between the abstract model and the user’s real world, and - of course - reflectivity in the form of appropriate typologies benefiting from that orthogonality.

Fancy O/R-based optimization can be fitted in where desired, but Metaset will at least initially offer no such facilities. I am even confident that the need for them will be much reduced in the MACK-boosted and more demand-driven market. Just think, for example, of the well-known contrast between simple realtime-IT-enabled and archetypically demand-driven JIT (Just-In-Time) on the one hand, and, on the other hand, complex batch-mode MRP (Material Requirements Planning) which inevitably entails some supply-drivenness despite its best demand-forecast-based intentions. That having been said, it is also sure that the market will in due course lead to a great diversification of useful O/R-based approaches.

P.S. Since writing the above paragraphs I have encountered the article Iterative Improvement Methods for Knowledge-Based Scheduling, by Jürgen Dorn in AI Communications, Vol. 8 No. 1 (March 1995), which opens with the following sentence:

"For large industrial applications the constraint-based formulation of scheduling problems fits better than mathematical representations from Operations Research, because the constraint approach is more flexible and can be adapted more easily to organizational changes in the production."

In their terms Metaset workflow-planning is clearly constraint-based. The author goes on to discuss the difficulties of reaching optimality (which is well known to be an intractable problem for scheduling in general) and how the iterative approach offers great practical flexibility, before commenting:

"These problem-solving methods have several benefits for realistic industrial applications. Since they can start with any preliminary schedule and can be interrupted anytime, they can be applied easily to reactive and cooperative scheduling. Further, they produce often better solutions in less time than other methods as was shown in several experiments."

That accords fully with my own experience in industry, in the automated scheduling and control of information systems, and with Metaset. (End of P.S.)

What about the difficult matters that I have already thrown - here and in [Ralph, Stefan, Jeff] - at all conventional technology, such as undo’s and transaction design? All I will allow myself to say at this stage is that Metaset’s approach here very closely resembles that of the most natural manual methods! In retrospect, it even seems strange that IT has taken such a roundabout route to Metaset’s simple approach ... though the reasons for every turn can also be seen as having been convincing under their respective circumstances.