MESA recommends using the Open O&M ws-ISBM to allow applications to send and receive messages independent of the message exchange mechanisms that are in place. WS-ISBM was developed and is maintained by MIMOSA (www.mimosa.org) as an Open O&M collaboration between MIMOSA, ISA95 and MESA. As an implementation of the ISA-95 Part 6 Messaging Service Model standard ws-ISBM can be used with B2MML, BatchML and KPI-ML in IT architectures that use Enterprise Service Buses (ESBs) and other messaging exchange models.
The ws-ISBM specification is available from Open O&M: http://www.openoandm.org/ws-isbm/1.0/ws-isbm.html
Background information on ws-ISBM is available from MIMOSA at http://www.mimosa.org/openom-ws-isbm and below.
The OpenO&M Web Service Information Service Bus Model (ws-ISBM) is an open standard that provides a vendor-neutral interface to an Enterprise Service Bus (ESB) by defining standard on-ramp and off-ramp SOA services that hide the specific ESB implementation. It is an open, supplier-neutral standard that can be used in any industry, as it allows the transmission of any information model, including MIMOSA CCOM, ISO 15926, MESA B2MML and OAGIS.
The ws-ISBM specification is available on the OpenO&M website. All releases of the ws-ISBM can also be downloaded directly from the MIMOSA ws-ISBM repository. MMOSA also has a GitHub repository https://github.com/mimosa-org/ws-isbm where ws-ISBM is available. All feedback is welcome.
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 engineering, operations, maintenance, material management, order processing, supply chain management, customer relations, and production scheduling. Even when a company has selected a primary Enterprise Resource Planning (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). These are not electronic busses in the sense of an electrical backplane bus. Instead, they are specialized applications that run on redundant servers and act as concentrators and distributors of data. Manufacturing systems that shall exchange data with business systems need to connect to the company's ESB.
Enterprise Service Buses are an architectural concept that includes proprietary web service standards, message based communications, message routing capabilities, and service discovery mechanisms. All of the ESB elements are normally based on XML technologies and web services. The data transfer element handles transporting XML messages from one application to another through the common server. This eliminates point-to-point interfaces and provides a centralized mechanism to manage and view inter-application communication.
Many enterprise IT suppliers offer ESBs; however, a few companies have also built their own ESB systems focused on their unique integration problems. Once a company has selected an ESB system, 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 between different ESB systems, so each application interface shall be customized for the chosen ESB.
In order to further interoperability and allow software suppliers to build in such capability into their products, the OpenO&M ws-ISBM provides a standard interface or an abstract layer to any ESB as seen in the following diagram:
The OpenO&M ISBM specification was jointly developed by ISA and MIMOSA under the MIMOSA Technical Committee, rotating between member organizations to host conference calls. The specification was refined through practical use in the OGI Pilot, where both provider/consumer and service provider implementations were undertaken by multiple software suppliers across different product classes. The ISBM specification was then extracted into two specifications: an abstract model that was published as ISA-95 Part 6 and an implementation specification based on SOAP Web Services that was published as OpenO&M ws-ISBM. This process was undertaken in order to provide a pathway to international standardization of the abstract model via IEC, as well as allowing multiple implementation specifications using different technologies (e.g. SOAP Web Services vs JSON/REST) but based on a common abstract model.
For access to more MESA content, head to our resource library.