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 CT0013 This section raises some serious questions about the implementation. It is hard to critical when

they have one of the best and most complete implementations of SWAP around, but I wonder how

much of this approach came from the pragmatics of getting something working. We should

carefullly consider whether we want to code these into the standard. Many things are passed as

part of the URL. Remember that an HTTP exchange is a matter of sending a request, getting back a

response. Both the request and response are text. Both have a header, then an empty line, and then

the rest is the body. The header is composed of a first line with a method, a HTTP version, and a

path on the machine (the part of the URL that is after the machine name), a number of header lines

with a name and value. I looks something like this:

Method HTTP Path on machine (First line)

Name: Value

Name: Value

Name: Value

Name: Value

(Blank line)


The JCALS implementation suggest that many things should be coded into the path section. For

instance, they put the XML as a parameter on the URL. The XML should be the body of the

message. It is the payload. It enjoys the benefit of relatively few restrictions on size or format.

Since the XML is the payload this is where you would expect it to be. They suggest encoding

username and password in the URL. There are already header fields defined for carrying username

and password, with well defined error conditions. It would be better to use and existing standard

than invent a new one. It is correct to place the ComID, MethodName, and INSTANCE_ID in the

URL. These are values that are constant for that particular resource. They are opaque values: the

URL with these values encoded in them is given out (e.g. in the process instance list) for use later

in accessing those resources. We should never expect the user of an HTTP protocol to have to

construct an URL from the one given, because to do so requires the user to have an understanding

of how the URL was put together, which we specifically do not specify. While a particular

implementation might place the instance id in the URL, we can not count on being able to pull it

out of the URL of all implementations. The URL should be an opaque quantity. Some of the rest of

the proposed fields look like convenient things for debugging, but we should consider carefully

whether this belongs in a standard. Another statement in question: “The UserOid can be

obtained from the <KEY> tag returned with the XML response of several SWAP methods” Since

the construction of the URL is not part of the specification, and there is strong evidence that

specific implementations will need flexibility in this, it is improper to suggest that any

information can be pulled out of an URL. What would happen if I tried to access a SWAP server

that did not place such a useroid in the URL; how would I proceed. Furthermore, the <key> URL

should be a persistable universal locator that can be saved and used at any point in the future. If

some sort of session id is encoded into it, then it fails to be persistable. Keith Swenson SWAP

Update Page 5 of 6 SWAP Update.doc June 12, 1999 Page 5 of 6 The <WFOLDERFILEX> tag is

a little unusual. Normally, one creates a single tag <WFOLDERFILE> without the numbering. If

it appears twice, then the second one is the second one. This allows any number of files to be

attached, instead of being limited to 20 as the current implementation suggests.

CSC/JCALS RW0014 Agree. Will incorporate changes.

Issue 45
Session ID

Resolution: The SessionID has been removed from the specification for version 1.0. The optional transport section of

the message may contain this information for implementations that require it, but no formal specification is

made at this time.

Friday, June 09, 2000 Page 12 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