Skip to Content

Reading standard specifications or white papers regarding electronic business collaboration, it leaps to the eyes that the terms ‘message’ and ‘business document’ are generally used quite arbitrarily, which is a pitty. It’s a pitty, because we could use these terms to differentiate better between the data that is sent between business partners within a business process and the data that is necessary to accomplish the sending.

First, I propose a definition of a document and then specialize its meaning to the business context. Afterwards I look at how these definitions help to describe our current world of electronic communication.

General Electronic Documents

I will start with the following definition: An electronic document is a string of characters, which is created to document a state transition of a system in a way that it can be sent to an intended recipient system so that this recipient is able to process or read it. With this definition a document

  1. is a self contained entity
  2.  

  3. can be transported without being changed
  4.  

  5. is created from structured data with two purposes in mind: to document a state transition of the creating system and to be comprehensible to the intended reading system

Being a self contained entity also means that the document type description is self contained and not part of some other type entity.   To be created in a form that it can be transported without being changed, implies that electronic documents have to be composed of characters, because only characters can be sent over the wire.

With this definition it becomes clear that these requirements stem from a state transition process model, where two processes interact by indicating each other their state transitions. Obviously, the interaction between these processes requires some sort of communication or document transport, which leads to the message notion. The document transport is provided by some channel function. To work properly, this function needs to add some structured character data, the transport data or envelop. Together, the total character data is named message.

  

Because of the documents’ character structure, it can be signed and encrypted. The signature refers to the sender, since the private key of the sender has to be used. Encryption referes to the receiver, since his public key has to be used. It is therefore unproblematic to delegate encryption into the already receiver specific channel function, thereby creating a secure communication channel.  The architectural consequences of also delegating signature or even serialization will be described in a later blog.

Signing such a document makes sense because of two issues:

  1. Since it is created for an intended recipient and purpose, it can be created with the necessary content and structure without any need for later changes.
  2. Sending a document away means loosing control. Hence, sending the document away is an important contribution for making the own transition irreversible towards the outside.

Business Documents

Classical paper documents play a very important role in traditional business processes. A classical purchase order indicates that a customer has decided to buy something, i.e. changed his state from “I don’t care” to “I want to have this product” without being controlled by the potential vendor. Because the order was issued and signed by the customer himself, it can be used by the vendor to non-repudiably prove this intent even before court. A classical receipt indicates that a customer has paid the invoice, i.e. has changed his state from “still has to pay” to “don’t has to pay anymore”. Again, since it is issued and signed by the vendor himself, it can be used by the customer to provide credible evidence for this transition before court.

Business process semantics remains invariant and does not depend on whether classical paper or modern electronic documents are used. We therefore have to pose the question, whether the defined electronic entities I named “documents” rightly carry this name in the sense that they do fulfill all the requirements posed by business process contexts, which are essentially that business documents have to

  1. be entities of their own, useful in different process contexts for different purposes.
  2. non-repudiably indicate business relevant transitions, which become irrevocable, once they leave control of their creator.
  3. are created in a form that they  
    1. can be transported without being changed
    2.  

    3. can be processed by the recipient without being changed.
    4.  

    5. can be attributed to a given party.   

The function of electronic signature is to enforce the attribution to a given party (authentication) and makes it necessary that all further process steps leave the document invariant.

From the fact that documents are created by some party A in accordance to the information need of some other recipient party B, it follows that there cannot be such things as a once and for all indication of business state transitions. E.g. patients are admitted to hospitals the same way for the last 50 years. However, since the necessary data, required by all processes, which may be started or modified because of this transition, have changed considerably in this period of time, the documents indicating patient admittance had to change accordingly.

The World of Communication

Most B2B standards, I am aware of, do follow this model. E.g. all that use the RosettaNet RNIF transport protocol (RosettaNet, CIDX, ..) separate transport functionality and document definition, although they call what I have defined as ‘document’ a ‘message’. Most B2B standards also incorporate extension techniques, to accommodate the need of the different business processes.

In a webservice context, a SOAP-message as defined by the WS-binding specification with its SOAP-header and -body could be viewed as such a document. According to WS Basic Profile 1.0, one way operations could be interpreted as sending these documents per HTTP to an HTTP recipient.  However, more often request response operations are used, using SOAP-messages to represent transport data in the header and functional I/O parameters in the body. Then their semantics differ from documents in the above sense that they do not represent state transition information as a self contained entity, but prescribe a functional interpretation to the transported data from a function consumer’s perspective.

The property of being self contained and not being part of some other entity becomes important in business processes where the computer act only as a representative of the actual business user. In such business processes, there may be certain steps that handle directly with business documents, e.g. viewing them for review and signing them afterwards, before releasing them for transport.

The property of not representing a functional input type from the perspective of the sender becomes important, if the receiver is supposed to make his own decisions about the document content processing, creating non determinism in his reaction to the sender, which is at the core of real business processes.

To report this post you need to login first.

1 Comment

You must be Logged on to comment or reply to a post.

  1. Tobias Trapp
    This was really interesting. I think your theses and paradigms are very helpful to understand modern interoperability standards and useful especially if you have to create specifications especially for data exchange. I would like to read more about it.

    Regards,
    Tobias

    (0) 

Leave a Reply