When evaluating the technology of the software vendors it helps to separate the software stack into some standard components, which are: Architecture, Integrated Design/Development/Deployment Environment (IDE), System Support Facilities, Intelligent Adapters, Transport, Routing/Message Broker, Reformatting, Transformation, Business Process Support as described below.

Architecture If the functional architecture cannot be described in a block diagram, using hierarchies to organize and simplify, you are going to have lots of scalability and performance problems, not to mention maintenance and ease of use. Additionally, your system is not going to scale functionally if its architecture isn't uniform: That means integration will eventually become a costly headache. A uniform, distributed architecture permits all components to be used together seamlessly. Architectures have evolved from simplistic point-to-point, hub, multi-hub, and finally, peer-to-peer or service-oriented, descriptive of the routing that is taken by messages between interconnected software systems in an attempt to improve scalability and performance.

Integrated Design/Development/Deployment Environment (IDE) If you might think the IDE has little to do with scalability and performance, you're wrong. When user-written extensions and product extensions are developed with the same tools, that great bane of scalability and performance - known as impedance mismatch - can be minimized.

System Support Facilities A great way to add overhead to a system is to develop functionally redundant and variant support facilities, almost a certain outcome if standard system support facilities are not supplied. Such redundancy adds unnecessary code that must be supported and increases the likelihood of context switches. It almost certainly will decrease Application Program Interface (API) uniformity, an essential element of good scalability and high performance. With every additional interface conversion or wrapper, we increase the execution path length for business functions.

Intelligent Adapters Adapters (or Connectors) are rapidly becoming the primary and most powerful component in integration suites. Early adapters did little more than provide data and message formatting. Today, these components are instrumented at many levels, providing system management and monitoring, meta-data interfaces, error recovery and logging, encryption, and much more. Because functionality varies so much, spend some time comparing adapters: they are not a checklist item. The wrong adapter can mean lots of development and high support costs. Good adapters can do a great deal to minimize message volume and message overhead. If the adapter is an intelligent agent, it can be interrogated and remotely, dynamically configured to work the most appropriate way. A more or less autonomous adapter enables availability and higher performance. Tasks like message reformatting and data transformation might be done locally, with the output routed directly to the next business.

Transport Each of the major products offer some form of native transport, a method of communicating messages. It may be synchronous or asynchronous, with subcategories, with subcategories such as RPC, request/reply, fire and forget (datagram), or publish/subscribe. If asynchronous, queue management is required. An implementation may very well use multiple transports, requiring adapters between the product's native transport and some pre-existing one. Offering a native transport avoids the potential cost of third-party product, and need for additional selection, deployment, support and compatibility. Not every method of communicating messages is appropriate for every instance of application-to-application communication. While asynchronous messaging (and, in particular, publish/subscribe) is very flexible, it is not very helpful when transactional integrity requires synchronization among distributed business functions. Flexible, configurable choice in the transport can make the difference between timely and slow unreliable integration.

Routing/Message Broker If you happen to need one, the throughput capabilities of your broker forms a floor on system performance. Try to make certain it will scale linearly, either with multiple brokers or, preferably, through peer-to-peer distribution of the brokering function. Message overhead shouldn't depend on routing complexity. Each of the major products offers a mechanism for flexibly routing messages. Most now provides request/reply and publish/subscribe routing, as well as both content-based and logical address routing. Content-based routing introduces a conditional element, which can be based on anything that can be incorporated as part of the content of the message. Pre-defined routing can be extremely efficient where it is applicable.

Reformatting Because aspects of the message that do not pertain to the content may need to be altered between source and destination, each of the major products offers some means of altering message format (reformatting). Note that this is distinct from content transformation. Often reformatting is done within the adapter, although some products perform such functions within a central broker. It's even better if formats are remotely configurable and have low overhead.

Transformation Altering message content between source and destination requires a transformation engine, perhaps as simple as inline translation. Transformation rules can be extremely complex, using content interpretation, meta-data (such as a record header or trailer), remote function calls, or simply field position, type, and length. Transformation engines may be hub-based, but the trend is toward adapter-based, providing multi-source to multi-destination transformation and multi-record to single record transformation without programming. All reformatting and transformation rules need to be maintained in an open, distributed repository. Distributed transformation is more efficient and scalable than hub-based transformation. This is true even if state-dependent fan-in or fan-out is required or the transformation rules change frequently, but a local "transformation engine" may be required. Watch out for XML overhead. Pay attention to rules repository efficiency: Both storage and access can be bottlenecks.

Business Process Support Business processes represent sequences of business events and activities, each of which may be implemented under the control of either personnel or software. Support ranges from simple workflow management to complex business process automation. A workflow or process definition controls routing of messages, and drives destination-based transformation. Unlike the point-to-point routing of a message broker, business process support introduces a higher level of routing control end-to-end. Sophisticated business process support will include hierarchies, simulation, analysis, optimization, transaction, recovery, graphical design, and both forward and reverse engineering at the click of a mouse. A high-performance process definition and instance status repository is required. A business process engine must support high-performance process definition, redefinition, and process state update and interrogation. Like other components, process management is most scalable if distributed. Process definitions can be replicated from a central repository, thereby enabling local and efficient lookups for each process instance. A slow process engine will become a serious bottleneck and impede scalability.

/\ TOP of Page