The typical IT environment is a federation of systems. The term “federation” in the IT world is applied to collections of applications from multiple vendors that work together to support business processes. A federation may include separate applications for material management, order processing, supply chain management, etc.

Even when a company has selected a primary ERP vendor, there is often a federation of legacy systems supporting unique business processes. Federated systems are expensive and integration efforts are often a major portion of IT budgets. An increasingly common method to reduce integration costs is an enterprise service bus (ESB) sometimes called an enterprise integration bus (EIB). These are not electronic buses in the sense of an electrical backplane bus, but special applications that run on redundant servers and act as concentrators and distributors of data. Manufacturing systems that must exchange data with business systems will probably need to connect to the company's ESB.

Enterprise service buses are an architectural concept that includes open standards, message-based communications, message routing capabilities, and service discovery mechanisms. There is no single definition of an ESB product, but a working rule is that it is a system that provides a single source of shared information, a single location for discovering application services, and a single destination for using services.

Several vendors are providing ESBs, but a few manufacturing companies also have built their ESB systems on open standards and focused on their unique integration problems. Once a company has selected an ESB system, then the IT department will attempt to have all applications that exchange data (including manufacturing applications) use the ESB instead of implementing point-to-point connections. Unfortunately, there is little interoperability among ESB systems, so each application interface must be customized for the chosen ESB.

Five main ESB elements are important in connecting applications to an ESB: a transport layer, a discovery layer, a transform layer, a protocol layer, and a payload layer. All layers are based on XML technologies, and newer ESBs are based on Web services.

The transport layer handles moving XML messages from one application to another through the common server. This eliminates point-to-point interfaces and provides a central mechanism to manage and view inter-application communication. HTTP messages and JMS (Java Message Services) are common open-source implementations of the transport layer. OPC-UA (www.opcfoundation.org) may become the standard transport layer mechanism for manufacturing system integration.

The discovery layer allows applications to discover the services and data provided by the ESB. This is typically handled by UDDI services (www.uddi.org) in the IT environment. The transform layer provides methods that convert data from the sender's format to the receiver's format through a set of application specific transform rules, using some form of XML transformation, such as XSLT scripts.

The protocol layer implements the formal definition of allowable message transactions and is often based on standards such as OAGIS (www.openapplications.org), RosettaNet (www.rosettanet.org), and the ISA 95 Business to Manufacturing Transaction standard.

The payload layer defines the data that makes up the body of the message. For manufacturing area, ISA 95 Enterprise/Control Integration standard with the associated WBF B2MML schemas (www.wbf.org) and the OAGIS BOD (Business Object Documents) are most common.

If your company has not yet selected an ESB, then ensure the manufacturing IT group is involved in selection. If applications are not compatible with the ESB selected, custom interfaces will need to be developed, increasing your cost to ride the enterprise system bus.