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
 


Edna Murby CT0078 2.2--Page 6--It is undesirable to include all request information in the message response as a

method for correlation (Performance, for example, becomes an immediate concern.)--Proposed

Modification:We propose the inclusion of a message header, “<WfMessageHeader>”, which

which contains a correlation element, i.e. the UserContext element, which is provided on the

request message and automatically returned in corresponding response message. We also

recommend the use of an element called “ResponseRequired”, which provides flexiblity for the

requesting application to ensure a response is always provided, never provided or only provided

in the case of an error. We also recommend the use of an optional element “Mode”, which defines

the message type as a request or a response. SessionId and exception were moved to the header

and left optional. The correlation information stored in the UserContext will be defined by the

application intiating the request, since it is this applications responsibility to ensure receipt, and

correct correlation, of the reponse message. An example of the proposed header <?xml version

“1.0”?><WF_XML>

<WfMessageHeader>

<Mode>Request</Mode>

<SessionId> </SessionId>

<UserContext> Data returned.

</UserContext>

<ResponseRequired> No

</ResponseRequired>

<Exception> … </Exception>

</WfMessageHeader>

</WF_XML> etc.Where valid values for the elements (not attributes) may be: For element

UserContext: { User information for correlation. } --- For element ResponseRequired Enumerated

type: { No | IfError | Yes } For element Mode:{ Request | Response } Rational for

mofification: Include a message header which can encapsulate correlation information and

additional information about the message (message type, response requirements, etc.) An example

of the DTD modifications:





<!-- ~~~~~~~~~~~~~~~~~~~~~ Element Declarations ~~~~~~~~~~~~~~~~~~~ -->



<!ELEMENT Wflow (WfMessageHeader, (%interfaces;) )>



<!ELEMENT WfMessageHeader (Mode?, SessionId?, UserContext?, ResponseRequired?,

Exception?)>



<!—Opaque -->

<!ELEMENT UserContext (#PCDATA) >



<!—Enumerated type -->

<!ELEMENT ResponseRequired (#PCDATA)>

<!-- Expected values: {No,IfError,Yes} -->



<!—Enumerated type -->

<!ELEMENT Mode (#PCDATA)>

<!-- Expected values: {Request,Response} -->



<!ELEMENT sessionid (CDATA)>

<!ELEMENT item (name, (value | type))+>

Edna Murby CT0080 2.2.1--Page 7--(Referring to the note) Although returning the entire request message may be the

simplest way, it does not seem to be the most efficient.

With respect to message size, which is mentioned in the note, it says ‘potential size of the

messages isn’t a problem’ Proposed Modification: We would like to propose the use of a single

item (“UserContext”) in the message header area for correlation, instead of including the full

request message in the response message. We would like to propose no limit on the message size.

Ratioal: There is a possibility for large messages and this could cause performance and efficiency

problems.

(What other identifier based schemes have been discussed and why were they rejected?)

CSC/JCALS RW0005 Agree. RequestID will be used.

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