XML Modes

Mode: a substance, such as water, may be found in three modes - gas, liquid or solid.

For example, the H2O molecule has different uses, depending on "mode" - e.g., you can drink liquid water or skate on ice, but you cannot skate on liquid water.

In applying Web Services XML to given practical needs, chosing the appropriate mode or modes involves two major options

Timing and commitment: "do it now and I'll wait till you are done" describe what in more precise IT terms are "synchronous" processes, while "do it when you can and I won't wait for you to finish" is equivalent to "asynchronous." Synchronous processesmust commit (finish) before the overall process goes to the next step.

Push versus pull: are implemented in http post (and ftp) using the verbs "put" and "get." These commonsense terms - if you want someone else to know what you know or to do something you want done, you want to do a push and your process does a put, and the receiving party reacts. If you want to retrieve something, that is a "pull" which your system implements using the verb "get," and in everyday terms "pull" is roughly equivalent to "I'll call you when I need you."

Mode Matrix: There are four modes, based on the intersection of "push" versus "pull" and synchronous (do it now) versus asynchonous

Examples of mode choices:

People designing alarms systems should use "synchronous" and "push," because the alarm needs to be processed right now and in all likelihood it is necessary to have ironclad assurance that the receiver has processed it.

"Lookup" of actionable facts or status such as doing a price or inventory check should be implemented with synchronous pull. If a price changes frequently - as with many commodities - asynchrous pull is essential.

High performance processes based on coupled systems work best if all dialogs are synchronous, just as a team of fine horses work best if kept on the ame pace. This is also true if it is better to hold up a process in case of error than to permit the process to continue even though some transaction is stalled. The downside is that a synchronous call that is stalled in effect "locks" the process.

Asynchronous push can be and often is used for EDI style "store and forward" orders as well as other transactions that can follow a fairly leisurely pace. Asynchronous pull often makes sense for retrieving large reports or database extracts that necessarily take substantial amounts of time and that are given lower priority by the "called" system. However, in today's environment of high speed networks and powerful computers, asynchronous (or batch) processes are not necessarily slow because the queue never builds up except perhaps at a few peak times. Asynchonous is problematic if it is risky or costly for the process to continue even if a transaction is stalled.

Although in these cases and many others the appropriate choice of mode may be obvious, practical impediments, such as firewall restrictions and network topology may intrude. For example, many EDI transactions - even if updated to XML - are processed through intermediaries rather than going directly to the target system, so it becomes difficult to achieve synchronous handoff.

Too often designers are pushed (or drift) to a wrong choice when in fact what should be done is to eliminate the barriers to implementing the more appropriate model. Clearly, in today's environment there will be a trend to reduce the use of "do it when you get to it" asynchronous or batch processes - the basis of older eBusiness models - in favor of realtime or synchronous. See environment and its subsidiary page brute force computing for descriptions as to how today's technology breaks down hindrances.

Web Services

Stepping ahead from classic EDI, there is the model known as "web services." The Web services architecture is based on SOAP (simple Object Access Protocol) and supporting standards such as WSDL (Web Services Description Language). Choosing to use "web services" - a good choice - does not in itself answer the question as to what mode fits a given commercial situation, because web services can be used in all four modes.

Fundamental architectural choices:

Mode choices present senior management with larger, more complex choices and perhaps threats. If innovations such as the application of XML, high powered computing and networking, etc. reduce trans-enterprise integration setup delay and expense, is your company's mission enhanced? Degraded?

One strategic choice is the degree to which an entity needs to "internalize" and assimilate data and functionality from "outside" versus "calling" on external resources as needed. If you can rely on "realtime pull" from trusted sources offering a high quality service, it probably does not make sense to internalize externally-originated data and functionality. If you cannot rely on such a source, then you need to invest more heavily in the capability to internalize (getting the information or functionality "inside" your environment) and assimilating it (melding it into your overall business processes and infrastructure).

There is no universal right answer, because the total cost of ownership of the information and functionality has to be evaluated - e.g., if you would call an external source 500 times a year @ $5 per transaction, or spend $100,000 per year internalizing and assimilating that same information capability, it is a no brainer to rely on the external source, but if usage goes up the tradeoff "flips."
Broadly, the structure of your enterprise, its relationship with sales and supply channels, and perhaps the structure of your entire industry could be altered by shifts and tradeoffs in the "mode change" balance.

One of the great risks that comes with more powerful IT capabilities and new techniques such as use of XML is futile "internalization."

For example, during the .com era (and beyond), one of the major "money sinks" - both for ,com entities and end user companies - was the often fruitless effort to internalize and assimilate supplier catalog and product data based on batch "push" data transmission from suppliers. The "push" part looked and was easy, but for the receiver information internalization and assimilation has many pitfalls.

Today, it is getting progressively easier to package and ship data from system to system, but it is still difficult to assimilitate it and make it useful. If "you are what you eat," do not get carried away and try to eat too much.

Intersection with other IT innovations:

Wireless technology, handheld/mobile computing, and "grid" computing open opportunities to exploit previously impractical or costly "modes." In a mobile world backed by huge amounts of lowcost processing resources, "do it now" increasingly is within your grasp, often within the "Web Services" standards.