content_image/998017.jpg
<img src='content_image/998017.jpg'>

## 6.7 Create event stream from messaging 

Now you have a working authentication URL in the DataPower. 

APIs have emerged as the simplest way to make data and functions accessible from back-end systems, and their role will remain fundamental to integration for some time to come. However, most modern applications have a need to respond to events as they happen, in real time. 

An API is a "pull" pattern whereby the consumer knows only the state of the back-end system when they choose to pull state from it via the API. As such, it may be some time before a consumer becomes aware a change has occurred. We could of course "poll" the API at intervals to check the state of the back-end system. But the more regularly we poll, the less efficient from a resource point of view this pattern becomes. 

Imagine the mobile banking applications of all customers regularly polling the bank to check the balance in order to check whether the customer has gone into overdraft. It would obviously be better to simply be only notified each time the balance changed, or better still only when an overdraft occurred. Therefore, we also need a mechanism to "push" notifications from the back-end systems up to the consumer applications. 

These real time notifications of events are just one example of where a "push" model is a common requirement. We consider another example later in 6.10, “Implement event sourced APIs” on page 366. 

Clearly, passing messages asynchronously isn’t in any way new. IBM MQ was invented for this very purpose over 25 years ago, and indeed we could easily use IBM MQ for this purpose. Indeed, we demonstrate IBM MQ as a source of events to a cloud integration in 6.8, “Perform event-driven SaaS integration ” on page 327. However, modern applications come with a subtly different set of requirements. Their requirements might be better suited to an alternative form of asynchronous communication known as "event streams", and typified by Apache Kafka, on which IBM Event Streams is built. 

We have already discussed in detail the differences between traditional messaging such as IBM MQ, and event streaming technologies such as Kafka in 3.3, “C apability perspective: Messaging and event streams” on page 68 so we need not repeat that here. Suffice to say there is definitely a place for both in a solution, and indeed they can often be used alongside one another in a complementary fashion. 

There are many different ways to create an event stream from a back-end system. In this section we are going to take advantage of the fact that in many organizations, a substantial IBM MQ infrastructure is already in place. For them, the simplest way to create an event 

