Author Chris Thorpe | Technical Director

Unlocking the Power of B2Bi Middleware in a Hyper-Connected Business World

In today’s hyper-connected business landscape, the effective exchange of data and information between organisations has become paramount. Business-to-Business Integration (B2Bi) plays a pivotal role in facilitating this seamless data flow between disparate systems, allowing businesses to operate efficiently and collaborate effectively. As organizations increasingly rely on digital ecosystems to drive their operations, the role of B2Bi as middleware has never been more crucial.

However, as technology evolves, so do the requirements of the systems it connects. In this blog, we’ll delve into the world of B2Bi as middleware, exploring its significance, the evolving needs of the systems it sits between, and how tools like IBM B2Bi, services, adapters, and system frameworks must adapt to stay relevant in this ever-changing landscape.

B2Bi as middleware overview

B2Bi is ofter described as a middleware application. However as we will find this is a very broad description. So what is middleware? A dictionary definition…

computer software that has an intermediary function between the various applications of a computer and its operating system

This was probably correct in the 1980’s but we can expand that and say middleware sits between any type of different systems and offers an interface between them. As we will see middleware constantly needs to evolve to meet the needs of the systems it sits in between.

So what makes up an interface then? Typically any system will offer up a generic input and output mechanism. It will be comprehensive enough to do the job but flexible enough to meet all the needs. Those needs will vary. They may need to interface with everything from Barcode scanners to automated robots, from banks to testing labs.

When you break down interfaces it is all about getting data from one place to another. So all of the following are examples of Interfaces

Message or Transaction Based Integration (Typically Containing Facts)
Data Access (Request and Response typically serviced by a database)
Application or Device Framework (Close Product Integration using tools such as an API)
Control and Optimised Data Processing (Robotics and Games engines)

While trying to categorise these interfaces I found that they all started to blend into one another. That is because they have to evolve to meet the needs of the systems that they talk to regularly.

In summary middleware evolves to meet the needs of the systems it interfaces on a regular basis.

A Typical Business Environment

A typical business will have a number of these internal components within their business that they deal with day to day.

Legacy applications. As a rule we see these less and less but sometimes this software maybe critical to the running of a unique business. There may have been a massive investment which has yet to be recouped. Whatever the reason the interfaces may be especially unique.
Packaged Applications. Off the shelf packages often have well established, well documented interfaces. Sometimes they incorporate API or Database technologies but there maybe tooling to make connectivity easier.
API Enabled. There are many types and variations of AP (Application Programming Interface) but in all cases they provide close integration to the systems.
File / Message / Event. There is often confusion between file based systems, messag based systems and more recently event based systems.

A file can be anything data in a single unit that requires moving from one place to another. It can contain anything and really be of any size.
A message is typically but not always a discreet piece of information. It is often but not always contained in a file and is expected to be relatively small. It normally has a known function and form.
An event is a discreet piece of data, time stamped typically small in size about something that placed it there. Analysing these events over time can show change of state showing history.

Typically file is described as transfer and messages and events are processed in queues.

Externally a company will need to talk to their Market Place, collaborate with their Business Partners and more recently access cloud based applications securely and reliably. All the internal methods could apply but as it is external additional security measures, tighter size restrictions for example are needed.

Market Places

Business Partners

Cloud based Applications

IBM B2Bi Tooling

Before tackling the interfaces themselves a framework is required to maintain integrity and data flow as will any middleware system. A set of tools exist and these can be described as the following

Rules and Processing

System configuration, Control and Monitoring

Provide Tooling, Data Transformation, User and Partner control

Storage and History

Services and Adapters

Each service and adapter does a unique function but they all work in a similar way.

They are all provided with a set of parameters from the engine (called message to service) and
respond with a set of parameters to the engine (called message from service)
Processing Services

Connection Adapters

Listening Adapters

Bootstrap Adapters

Bulking and Debulking.

Security

A special mention to the role of the perimeter server which is a proxy server allowing any of the external facing adapters inbound and outbound to communicate through a single outbound connection to the DMZ. This makes for, in many cases, a simple one off firewall configuration change which will allow many different connections to be configured.

System Framework

A middleware tool needs to fit into any environment and be comfortable processing 5000 files a day or 5000 files a minute. To meet these needs a flexible architecture is required that is able to process these demands.

Unlimited file size. The file size is only limited by the bandwidth of the system and the amount of storage needed to hold the file.
Processing throughput

When a file transfer is completed then it is stored. However the trigger to process and the trigger to complete the handover is done at exactly the same time and is done regardless of the transfer mechanism. This means the file will never be processed twice or zero times in any complete transaction.
Every process is considered to be independent unless configured otherwise (FIFO) and concurrency is built in to the heart of the B2Bi engine. Allowing massive throughput potential.
In a FIFO situation transactions can be built and committed in a single transaction allowing for an all or nothing approach if required.
Single nodes or clusters of 2 or more parallel running systems can be built allowing for scaling, fault tolerance and load balancing to be seamlessly achieved.

Global Mail-boxing and Federated systems can be built to allow for cross data centre and global distribution.

Conclusion with a CTA

B2Bi as middleware is a crucial enabler of modern business operations. Its ability to adapt and bridge the gap between disparate systems ensures the seamless exchange of data, powering businesses to thrive in an interconnected world. As technology continues to advance, B2Bi will remain at the forefront of innovation, serving as the vital link that propels businesses forward in their digital transformation journeys. If you’re eager to harness the full potential of B2Bi solutions and unlock the benefits they offer in today’s ever-evolving business landscape, reach out to Coliance.