Jaa

Stateless is to service as commandless is to data

  • Artikkeli

Abstract: This article provides a counterpoint to Pat Helland's most recent article by describing the concept of "commandless data documents," and how they are logically used in Service Oriented Architecture.

Introduction

I was re-reading Pat Helland's latest SOA article "Data on the Outside, Data on the Inside" recently.  It is a good step forward in the discussion of how data is managed in an SOA environment.  I believe that one aspect of the discussion is lost in this article and many of the others that I have read: Something I like to call "commandless" data.

In Mr. Helland's article, he states:

In service oriented architecture, the interaction across the services represents business functions. These are referred to as operators. The following are some examples of operators:

  • Please PLACE-ORDER
  • Please UPDATE-CUSTOMER-ADDRESS
  • Please TRANSFER-PAYMENT

I don't get a chance to disagree with his articles very often, but this time, I must.  The above statement is often incorrect because it assumes that the document represents a command, and not a statement of fact. 

To whit: When a purchase order passes from a buyer to a seller, I assert that the document is NOT a request. 

A statement of fact

The sending system has already entered the document as State information.  It is not, in all liklihood, waiting for a response before booking the purchase order as an outstanding obligation.  No, the purchase order is not a request to purchase... it is a statement that the buyer expects the seller to follow through a contractual arrangement that will result in the transfer of goods and funds.   This statement of fact is already on the balance sheet of the buyer.  It already affects financials, projections, and, in all liklihood, customer-facing statements about the availability of products further along in the supply chain. 

Viewing a purchase order as a request assumes that the sender knows what must be requested, which means that the sender is sending a command to the receiver.  Viewing the purchase order as a statement of fact means that the sender cannot know what must happen from a system standpoint on the receiver's end.

This is a minor shift in the point of view, but a very important one.

The fantasy of "Once and only once"

The first time the seller gets the document, the seller may (or may not) be surprised by it.  "Look, ma, someone wants to buy something!"  However, the behavior of the receiving systems is not "add" the purchase order!  On the contrary, it is "Does this order already exist?  If not, add it."  That is because the order may very well already exist.  In fact, how can the sending system know that it doesn't?

The systems of business have to allow for information to come from multiple sources.  There is no concept of "send it once and only once."  People use telephones, fax machines, e-mail, online ordering, snail-mail, calls to the customer service rep, and indirect purchases (e.g. from a dealer) to indicate that product needs to move from place to place.  I call this an "open channel" because the same message may arrive, in different formats from different sources with the same content.  The sending system cannot assume that the receiving system does not already know about the transaction, nor should it presume to dictate what the receiving system should do with it.

Never a command? C'mon...

That is not to say that documents must never contain a command, but they would be commands for information, not normally commands for functionality on the receiving end.  By this, I mean that some messages are, of and by themselves, useless without referencing an ongoing transaction.  For example, if I ask for the status of an order, I am referring to an order number for an order that already exists.  The receiving system would respond with information about the status of the order.  A list of response codes may include...

  • Already shipped
  • Shipment planned on schedule.  Expected ship date: 11/01/04
  • Shipment planned outside of expected schedule: Expected ship date: 12/01/04
  • Shipment accepted and vendor commits to fulfillment, but ship date not known.
  • No shipment planned.  No committment is made.
  • Problems detected in processing the order.  The order is on hold until manual resolution.
  • I've never heard of that order.

On the other hand, if I want to transfer payment from one account to another, my document does not contain a request for the transfer... it simply states that the sending system considers the transfer to be a fact, and would like the receiving system to confirm that it, too, believes the same to be true.

This way, if the same document is sent from the sending system to the receiving system 25 times, the transaction still occurs only once on the receiver.

Note: Acknowledgements are a special case. If I send a document to a system, and get an acknowledgement back, I do not expect to get back the entire submitted document. I would expect to get back my sending identifiers and the receiving systems unique identifier for the same document. I would want to ASSUME that the document that I referenced as "Contoso transaction 12" and which was acknowledged as "Contoso transaction 12" was not changed by the receiving system before being acknowledged. If this is not the case, then the protocol would need to handle these situations. 

I can respond to a question... how do I respond to a fact?

This ability to respond to a fact, rather than a request, is essential when creating a new system in the world of SOA.  This is because we need to be able to make statements that are detached FROM EACH OTHER.  Sure, some documents are going to cross reference (like my status request).  However, the system should function, and function well, without having to coordinate many of the incoming documents.

For this reason, if a purchase order arrives from a new buyer, the purchase order doesn't need to be preceded with a "add new customer" order.  The purchase order establishes the customer if he or she doesn't already exist. 

This is the concept of "commandless data."  This is as powerful a concept for integration as "stateless transactions" are for scalable web page requests.  With commandless data, we get simplified interactions, scalable messaging, and protocols that are reliable, even when our networks are not.

This is why I love this stuff.