RE:RE: Comments to the SWAP document (7 August

Hello Keith and the other SWAP participants,
Thank you for your quick reply.

You clarified several of my issues
(accordign to some of your answers the specification needs
to be changed a little bit), and I am completeley satisfied
with your answers to my issues 2.8, 3.1, 3.3, 3.5, 3.6,. 3.10 - 3.12,
3.20, 4.2, 4.5.

I still have some comments and questions to your answers of
the issues 1.1, 2.1, 2.5, 2.5, 2.7, 2.9, 3.8, 4.3 (see below).

I did not yet receive comments on 1.2, 1.3, 2.3 - 2.4, 2.6,
3.2, 3.4, 3.7, 3.9, 3.13 - 3.19, 3.21, 4.1, 4.4, 4.6 - 4.13.

Best regards
Rainer Weber
SAP AG

----------------------------------------------


>- Message by Keith Swenson
>Hi everyone,
>lots of good comments and questions below.  I responded to many.  I
>omitted things that I did not have a response to which does not mean
>that they were ignored.
>-Keith

>> -----Original Message-----
>> From: rainer.weber@sap-ag.de [mailto:rainer.weber@sap-ag.de]
>> 1. Very High Priority:
>> ----------------------
>>
>> 1.1 Section 5.1 (for example), but also more general:
>> This section says "The ProcessInstance interface must be implemented
>> by all resources that represent the execution of a long term
>> asynchronous service". To me, this seems to be too restrictive.
>> I think it need only be implemented for those processes that
>> are started using SWAP. This might only be a subset of the
>> available process definitions.

>This is correct, but I think it is obvious that the document only
>talks about things that can be manipulated with SWAP.  Or at least
>it should be clear that such an interface is not required if you
>are not going to manipulate it with SWAP. Correct me if I misunderstood
>what you meant here.

For some things it may be clear, for others it is not clear to
me. For example, I could list the process instances of some
process definition using the LISTINSTANCES of the ProcessDefinition
Interface, even if I did not create or start these process instances
using SWAP. I could then also list the properties of these instances
using PROPFIND of the ProcessInstance Interface.
On the other side, I might not want to expose information about
processes that were not started using SWAP to the outside.
I am not sure whether this can cause some practical problem.
You might answer "Expose the information to the outside which you
want to expose".
A similar example is the PROPFIND of the ProcessInstance Interface.
It includes containees, i.e. also URLs of active activities.
If there are some active activities waiting, but they are not
controlled via SWAP, should I return an empty list of containees?
This could also indicate that currently there are no active activities.
Or should I return also URLs for these activities, enable the
PROPFIND of these activity observes, but disable the PROPSWITCH
and COMPLETE methods for them? (Is it viable for some resource to
implement only part of an interface?)

If I read the specification literally, it seems that all processes
and activities should be SWAP-enabled, so my problems are not
addressed in the specification.

>> I see a similar problem in the PROPFIND method of the ProcessInstance
>> interface: For the parameter "activities" there is an URI of
>> the active ActivityOberserver for each open activity.
>> The ActivityObserver Interface includes methods PROPPATCH and
>> COMPLETE; these methods can be used to control an open activity
>> which is listed as an URI. However, again I think that only some
>> of the steps of a process instance should be controllable using
>> SWAP; e.g. background steps are just handled autonomously by the
>> workflow system.

>Indeed, there will be many elements of the workflow system which do
>not "show through" to the SWAP interface.  For instance most Wf systems
>have an "automated activity" which in some systems looks like an
>activity,
>but such a node would not have to have an URL and would essentially
>not appear nor be manipulable via SWAP.  What you state is correct,
>ad if it is not clear in the documentation we need to make it so.

see my comment above

>> 2. High Priority
>> ----------------
>>
>> 2.1 Section 3.0, 1st paragraph: May a resource support more than
>> one interface? (The initial specification said "yes"). If yes,
>> it may support several different (maybe also semantically slightly
>> different) PROPFIND methods. How do we eliminate this
>> overloading? Different PROPFIND methods may have different
>> parameters and result pages, they may also have different semantics.
>> Either we have to make sure that such a collision is not harmful,
>> e.g. by taking care that the different PROPFINDS are "compatible".
>>Or we make sure that by "context" it is always clear which PROPFIND it
>> is referred to.
>>To be on the safe side, we could prefix the method by the
>>interface, e.g.
>>    ObserverInterface:PROPFIND
>>This is what I suggest. (This approach is also taken in COM.)

> I don't think we should allow differing meanings of PROPFIND.  Please
>refer to the WebDAV document for the definition of PROPFIND. In SWAp we

>just refer to this definition.  If it is ambiguous there, it should be
>fixed
>there, but there certainly should be only one meaning of the PROPFIND
>method.

If it is the same PROPFIND every time, why is it not included in
just one interface? What is the semantics, if a resource supports
two interfaces, each with its own PROPFIND. Is the result then
the union of the result pages of each PROPFIND method?
(This is what I meant when I said that we take care that the
different PROPFINDS are "compatible".)

>> 2.7 Section 5.4, methods PROPPATCH and COMPLETE: For what reasons
>> do you need them? I think similar to moving forward in the
>> process instance as some activities are completed, the workflow
>> system also takes care that the activities are completed
>> and the properties are set after completion. This can be done
>> internally, and no methods are necessary to control this from
>> outside, e.g. using SWAP. Who is supposed to call PROPPATCH and
>> COMPLETE?

>PROPPATCH is a general mechanism for exchanging the name/value pairs
>known as process data.  If a process is a for FedEx to ship a box
>somewhere,
>PROPPATCH would be used to specify the address to send to.

I think you only need this if you want to transmit some data
even before the workitem is completed. (Because with the
completion also the end results are transferred using COMPLETE.)

>> 2.9 Section 5.6, 1st line: "Creating a workitem done by using
>> the standard createProcessInstance function." At least in our
>> workflow system this is different: Workitems are created by
>> running the process instance. In more detail, by running a
>> process instance according to its process definition, following
>> the control flow of the process definition, activities and work items
>> are created. So they are just there, no method (like createProcess
>> Instance of the worklist resource) needs to be called for that
>> purpose. Even if I take another view and see the createProcessInstanc
>> method of the worklist as just calling/getting the worklist
>> (i.e., returning the current list of work items of a user),
>> I would just call this method once, and not for each work item in
>> in the worklist.

>This came out of discussions on distributed, wide scale workflow.  Some
>of the assumptions made by smaller systems dont scale.  One is the
>"worklist".  I know this is confusing and not well documented, but
>something in this area is needed.  Let me explain.  Say that I work on
>system C which is a fully SWAP compliant workflow system (which might
>involve any number of servers).  My company, on the other hand, has
>ctually 20 different workflow system scattered across the company, but
>(luckily) they are all SWAP compliant.  It may be that the Facilities
>department has a workflow system D that I must use to order a new lamp
>for my office.  The legal department has a workflow system E that I mus
>use for getting legal approval for documents.  Without SWAP worklist
>support, I have 20 different worklists that I must check on a daily
>basis -- what a bother!
>
>The idea behind worklist support is that I as a user will register in
>the corporate directory that I get my worklist from system C.  So,
>system D must be able to use SWAP to let system C know that I have
>something that needs doing.  System D retrieves the URL from my user
>directory entry.  To that URL, it uses the CREATEPROCESSINSTANCE
>command, the resulting process instance does not actually do anything,
>it just appears on my worklist on system C!  In a way you can think of
>it as a really really dumb process on system C.  The only purpose of
>this process is to get the reference to the parent process, the
>observer, which is an URL to the process instance on system D.  Using
>that URL, I can interact with the process instance on D.
>
>So I hope you see that it is just fine that system D creates a workitem
>for me automatically, but I am never going to see it unless there is a
>protocol that it can use to get a "proxy" workitem on to workflow syste
>that I get m worklist from.

I understand the reasoning behind it. However, two things are not
currently clear to me:

Firstly, should we include worklist handling in release 1.0?
I see that still quite some effort would have to be spent here,
and you agree that it is not well documented yet. I also think
that if we include worklist handling, many more operations
are needed: execute a work item, forward a work item, etc.

Secondly, even with your explanation I do not yet understand the
operational behaviour sufficiently well. Must the CREATEPROCESSINSTANCE
method be invoked for each operation to be transferred from
system D to system C (in your example), i.e., for 200 work items
CREATEPROCESSINSTANCE is called 200 times?
What would help is a scenario-oriented description: Starting from some
work items in system D, which methods must be called that they appear
in system C, and which methods are invoked (indirectly by the user)
in system C such that the work items are handled (in particular
executed).

>> 3.8 Section 5.1, method PROPFIND, parameter "observer":
>> Why is this optional? Does this indicate that PROPFIND also applies
>> to process instances that were not started using SWAP?
>> Suggestion: Clarify, e.g. by referring to the model which is used
>> (see also my comment 1.1).

>Why not?

With "why not" you mean "Why should it be not optional"?
If a process has been started via SWAP, there exists some observer.
So the observer is obligatory, not optional.

>> 4.3 Section 3.3, 2nd paragraph: "A WorkItem, which is a
>> ProcessInstance": This sounds strange, having the Workflow
>> Management Coaltion terminology in mind.

>You are not the only one who has commented on this, but if you
>think about it for a while it makes sense.  Or does it?
>Comments welcome.

I agree. But maybe we could find some formulation which does
not confuse the reader when he has a first look at it
(even if the second or third look might clarify it).

> -Keith

Received on Monday, 28 September 1998 12:24:39 UTC