(Please first read my Introduction to these comments on your papers.)
What is needed is a way for the process creation environment to inquire, in an ad-hoc format, about key publicly accessible attributes (as determined by the business objects) of other business objects without breaking encapsulation. In other words, the process creation environment needs to be semantically interoperable with business objects, just as the business objects themselves are with each other.
Yes! (And cleanly-controlled access to public attributes - as in Metaset - doesn’t break encapsulation and is easy to apply safely.)
Work items and lists are outdated. In the world of business objects, the desktop is the interface. As Oliver Sims preaches, OO document centric GUIs are how business objects will present themselves to their users. And they won't be shy. They won't disguise themselves because there is no need to. Users will recognize them as entities in their business domain, and they'll understand (in most cases, intuitively) what it means to do typical OO GUI operations on them.
Yes! The business objects aren’t seen as metaphor or picture. The relevant UI objects, in the user’s eyes, are the real objects. We are creating part of user reality. In many cases the UI objects will be more real than the "real" entities, for the latter often aren’t visible at all, and even when they are visible they aren’t as manipulable and controllable with all their implications as they are known in the information system.
Such loosening of bonds with apparent physical reality has its frightening aspects. It cries out for "realworld control". But that is what the MACK "RE" or Realworld Equivalent empirical concepts are all about.
Your first sentence just quoted - about work items and lists being outdated - I quote with approval in my comments on Wolfgang Schulze’s paper. On that subject you then go on to say:
Nebulous 'work item' concepts don't fit. They aren't objects. Work is a consequence of what happens when business objects play together on desktop GUIs as directed by users.
I would argue that a constructed dialog with associated processing may for certain purposes be regarded as an object and - yes, more nebulously - as a work item. However, that last sentence is spot-on, and does not contradict the work-as-object notion. After all, a dialog has conditions and outputs and many quantifiable aspects that we associate with work-like things. But, yes, your main point is correct: traditional work items are too nebulous (You have chosen an excellent word there!) to become driving objects, and work must rather be constructed as a function of the complex business model. The rest (the definitions and quantifications of the resulting work) is thus derivative rather than primary. And that is precisely the MACK approach too.
As previously stated, the process creation environments of workflow tools will need to be able to interface with a business meta object repository to allow the developer access to the publicly exported attributes (or indeed any other meta object information) of the business objects.
How do you see that feature-set evolving out of the OMG’s OMA? (Again, cf. my comments à propos Wolfgang Schulze’s paper re that time mismatch.)
Roaming agents, autonomous carriers of process knowledge, should be considered by the workflow vendors as candidates for a flexible, scaleable workflow architecture. "The Essential Distributed Objects Survival Guide" (Orfali, Harkey, Edwards; Wiley, 1996) points out that the combination of roaming agents, a standard object bus, and a distributed document facility (something that almost all vendors, not just workflow vendors, should be aiming to use) can provide for some very powerful constructs.
Control of process instances (such as termination, suspension, resumption) should be considered as an administrative task, perhaps to be managed by the workflow facilities. It would require the locating, and notifying, of agents in the system.
Process execution also involves the monitoring of process states across the system. It will be part of an agent's responsibilities to report on its state (and therefore the process state) as required, presumably to some configurable amount of detail.
I agree (mutatis mutandis): Metaset manages the work in an analogous way. BTW, I enjoyed your colleague Ron Resnick’s position paper Distributed Objects on the WWW. His demand for a more ‘"solid" Universal Front End’ will be very well met by Metaset.
To stand back a little, though: I would say that you and Ron have your noses a bit too close to the grindstone of existing and working technology. (Okay, maybe mine is too far!) See the references to "time" and "linear text" in my paper and faq. See also [Wolfgang, Ralph, Jeff]. The implications there are that www+Java+OpenDoc+CORBA collectively - and even individually - have inappropriate foundations. (Quite apart from being one helluva mish-mash of technologies which would surely be far more difficult to use and develop with than Metaset!)
You are obviously a Java enthusiast, and I agree, Java must seem like a programmer’s dream compared with the alternatives. But from an OO point of view it is a kludge (Multiple Inheritance is central to the relativity that is central to MACK and should be central to any sufficiently comprehensive architecture), while for an application designer like me it is a management nightmare (Where is the distributed repository that autonomous participants need?). Despite all the eager-beaver and doubtless excellent programmers and carpenters like you and Ron, I can’t see it evolving cleanly into a simple architecture.
Yes, I’m afraid that is rather disparaging, but there is a compliment hidden in it too: Scylla always takes "the best" of the crew! I expect that its evolution will get progressively slower and more ineffective from all the divergent tugs. Eventually the various more successful Java growth directions will be seen to be merely yet more limbs of the evolutionary tree (and, because of their degrees of success even in the face of complexity, problematic branches of the Charybdian figtree too!).
Maybe on the other hand it will be me who - at best - is left trying to put a brave face on his own smug perch on his little Charybdian figtree branch, or - at worst - is quickly munched by one of Scylla’s heads! But I doubt it, for all the reasons I have given, especially in [3].