Making your e-business work  


    Reference Model
    Public Documents
    Wf-XML 2.0

About WfMC


Information and

Free downloads

Membership Information

Press Room

Excellence Awards

Marvin L Manheim Award

Workflow Handbook

   2006 NEW!

Associated sites:

Got a question?
Join our Discussion Forums
 Discussion Forum for Workgroups (WfMC-specific)

Workflow and BPM Research

BPM Community Forum

Keith Swenson CT0005 I have nothing against the session ID concept, but if it is present, then we must specify how you

generate or discover the session ID, how long it lasts, and what errors you can expect to receive. I

am not trying to make things difficult, but imagine that I have a SWAP client, and I hear that Dell

computer has implemented a SWAP interface to their order processing process. I try to attach. If

they require a session ID, then I will fail to attach. One thing that clearly came out of the SWAP

meeting, particularly from Larry Masinter from PARC, was emphatically that the security should

be handled by a lower level protocol layer. For example, in HTTP, the HTTP header include name

and password elements. When you attempt to connect to a HTTP server that requires

authentication, and these elements are missing, then the request is denied with a well known error

code before the body of the message is ever examined. (In a browser, it receives this well known

error message, prompts you for a name and password, and then resubmits the HTTP request.) In the

case of SSL, you must provide a public key based authentication of your self, before the

connection can be established. All of these authentications and security mechanisms are build

into the connection. By leaving the authentication at that level, we remain able to run the XML

requests over a variety of protocols. One concern may have been that such protection is not built

into email transports. In this case, the XML message must be wrapped in an email session

transport. What I mean here is that there must be a short email exchange to set up the session ID

and authenticate both ends. This transport wrapper should also handle the difficulties with delay,

retry, and duplicates. The wrapper clearly should follow what has already been specified in the

WfMC interface 4 SMTP binding. Done this way, the SWAP/XML payload will be the same.

Rainer Weber CT0027 The use of the session ID does not become clear to me. It is optional, I know. But in which case

does it make sense? Proposal: Explain when it makes sense. Otherwise: Leave it out.

Issue 46

Resolution: See Issue 5.

Ed Staub CT0054 Are you aware of any efforts to standardize use of Wf-XML over particular protocols? In the draft

spec Appendix D, you mention transport over HTTP, but there's no firm binding to it. I realize that

the XML representation should be kept separate from the binding to particular transport

protocols, but I think it would greatly hasten adoption if there were a simultaneous effort to bind

onto HTTP at a minimum.

Thanks for a great effort.

CSC/JCALS RW0006 Session ID was optional. It will be taken out of the specs and then amplified in the

interoperability contract section of the specs.

Issue 47

Resolution: Version 1.0 of the specification describes two different states for abnormal completion of a process:

terminated and aborted. Terminated is used to indicate that all further subprocesses and activities are to

be terminated as well. Aborted is used to indicate that thee are no requirements placed on subprocesses

and activities.

Keith Swenson CT0007 Can we nail this one? It always comes up. I belive that terminated means that the requesting

resource decided it did not need the service to be performed any more, and communicated to it that

it should be terminated. This is “top-down” termination. Does aborted mean that the thing doing

the activity failed to do it? This would be a sort of “bottom-up” halting of the execution of the

process. Should be consistent with the OMG/WfMC spec

Friday, June 09, 2000 Page 13 of 18
First Previous Next Last
Published Docs
Reference Model
XPDL support

Wf-XML 2.0

Information Services
Info Services
Workflow Handbook

How to join
Country Chapters
List of members


Workflow Handbook 2006

CDROM Companion to the Workflow Handbook 2005


horizontal rule

home | membership | standards | info | events | members only

All brand names and product names mentioned in this website are trademarks or service marks of their respective companies. Any omission or misuse should not be regarded as intent to infringe on the property of others. The WfMC recognizes and respects all marks used by companies, manufacturers and developers as a means to distinguish their products. The “WfMC” logo and “Workflow Management Coalition” are service marks of the Workflow Management Coalition.

horizontal rule