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
  • This could take the form of a shop front web site selling the company wares or a full market place seller either way a stream of information is required in both directions.
  • Business Partners
  • When a company needs to start messaging other business point to point there is a whole load of complexity added. This is mainly because there is a tangled web of point to point transactions happening. For more detail see this article ( A Tangled Web )
  • Cloud based Applications
  • More and more companies are outsourcing some of their functions to cloud based application and these will need a stream of data in the same way internal systems do.
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
  • Data has to arrive and leave the system in someway and there unlimited paths that data can take. Controlling this is the job of Rules and Processing and what we describe as the engine.
  • System configuration, Control and Monitoring
  • These Rules have to be configured and monitored. The will allow for notifications, history, auditing and potentially billing.
  • Provide Tooling, Data Transformation, User and Partner control
  • Some of the processing will require external tools and some are unique to the product. Either way the application of this tooling may need to be applied, changed, version controlled, active/inactive etc. User profiles are also required to be able to change and use the system with a set of profiles and permissions.
  • Storage and History
  • B2Bi is strong on processing history also there is a store and forward system called mailbox service where partners can deliver and collect date independent of processing time.
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
  • As the name suggests the service is given a set of parameters and returns another set. “Typically” you only need one of these as each call will create a new instance or reuse an existing instance automatically to do your task.
  • Connection Adapters
  • These adapters are triggered by a set of parameters, connect in some way to a remote system and return data back to the engine.
  • This connection may be maintained between adapter calls
  • this can either create a number of steps in a session for example a connection to a server with multiple command before closing it.
  • or by means of a shared pool connection like a database connection where a session is maintained over long periods and used by many processes.
  • Listening Adapters
  • These adapters are started and remain up, Stateful. This allows for remote systems to connect and interact with the hub.
  • Bootstrap Adapters
  • These adapters run periodically and check for the existence of something. These no nothing else repeatedly until something is found and then trigger a process.
  • Bulking and Debulking.
  • This is a special group of services that are given the task of batching, grouping, labelling, encrypting, enveloping, signing (etc.) documents into a single form on the one hand and similarly identifying, splitting, exploding, decrypting, de￾enveloping (etc.) on the other.
  • Security
  • Keys, certificates, ciphers are required by almost all connections in modern systems so are added by the use of all in one connection Adapters or Security services.

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.

Related Topics

B2Bi

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

Read More

Author Chris Thorpe

Technical Director

Let's get started

Book a consultation

Contact Us

Coliance © 2023 All rights reserved