Making your e-business work  

Home

Standards
    Conformance
    Reference Model
    Public Documents
    XPDL_2.0
    Wf-XML 2.0



About WfMC

Events

Information and
Publications


Free downloads

Membership Information

Press Room

Excellence Awards

Marvin L Manheim Award

Workflow Handbook
   2001
   2002
   2003

   2004
   2005
   2006 NEW!


Associated sites:
AIIM
WARIA

e-workflow.org

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

Workflow and BPM Research

BPM Community Forum
 


Keith Swenson CT0018 XML tags are grouped into two groups. The first group is tags that need to be present in a request

or a response. These tags will be nested within <WfRequest> or <WfResponse> tags. The second

group is tags which are required to get the request and the response to the appropriate resource

reliably. These tags are always within <WfMessage> tags. Note that <WfRequest> and

<WfResponse> tags are nested within the <WfMessage> tags. Using SMTP protocol, one must

include the entire <WfMessage> block (which includes the request or response). Using HTTP,

only the request or reponse needs to be transmitted, because the HTTP header contains sufficient

amount of the session level information.

? In this use “Application Level Data” is defined as that data to be communicated from one

workflow engine to another. “Session Level Data” is defined as that additional data that must be

communicated to support a session (virtual connection) upon some protocols. For HTTP, no

Session level data is needed in the XML because each request involves a direct socket connection

between the two servers. For SMTP and other store-and-forward mechanisms, there is a need for

some extra session level information.

? Some elements of this same design approach are touched upon by Edna Murby from IBM where a

proposal is made for a “Header” which contains sessionlevel data values.

? It is a fact that HTTP and SMTP are very different things, and to say that WF_XML can be

communicated over any protocol is a gross oversimplificationof the issue invovled. There are two

contradictory desires:

1. there is a large desire to see XML encoded data to be communicated over email.

2. There is a desire to see this implementation run efficiently over HTTP

? Meeting this requirement with a layered approach is the right thing, because:

1. Separation of email issues from the main mail issues allows separate groups to work on it.

Smaller problems generally yeild better results when committees are involved.

2. Other transport mechanisms could be considered, simply provied the session level data

structure.

3. Better fit with current layered approaches. By being layered, a “reliable email layer” could be

implemented, which would suffice for multiple uses. This reliable layer would pass its

applicationdata on to the higher layers without having to interpret it.

? [rw] In order to run that protocol, we also need to determine the communication channel

(Protocol = communication + data). The XML description are not sufficient (but I agree that they

can be treated independently from the communication channel). Proposal: Add a section that tells

how you run this via http (the most important one currently). Appendix C is not sufficient.

? [ks] If we split the session level data from the other, we will be able to more easily describe how

this information is carried by HTTP.

Rainer Weber CT0025 2.1 Communication channel.

In order to run that protocol, we also need to determine the communication channel (Protocol =

communication + data). The XML description are not sufficient (but I agree that they can be

treated independently from the communication channel). Proposal: Add a section that tells how

you run this via http (the most important one currently). Appendix C is not sufficient.

Issue 22
ProcessDefinition.PropFind

Resolution: Leave ProcessDefinition. Propfind out of the specification.

Rainer Weber CT0029 I consider this unnecessary. If somebody knows the ID of a process definition and wants to start a

process of that process definition, he also knows what the process does and which parameters he

has to pass to it.

Proposal: Leave it out.

Richard Heim RW0020 I disagree! I use this! Since context data fields may vary by workflow engine, and possibly even

by process definition, a given user may not know enough about the fields required to start a

particular instance until a PROPFIND is requested.

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

Wf-XML 2.0
 

Information Services
Info Services
Awards
Books
Workflow Handbook

Membership
How to join
Application
Country Chapters
List of members
Officers
Fellows


NEW!

Workflow Handbook 2006
NOW SHIPPING!



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. http://www.wfmc.org.

horizontal rule