MCPA MuleSoft Certified Platform Architect Level 1 – Event Driven Architecture Part 2

5. Event Driven Architecture vs API-led connectivity

Let us now compare event driven architecture and API Led connectivity. API Led connectivity defines three tires, as you already know. One is Experience API, one is Process API. And the last one is the System API. Right. So this is how the API connectivity encourages to operate the services. By defining three layers and assigning the APIs relevant to each layer and communicate as per rules. That okay, experience API should talk to Process APIs only, and Process APIs should talk to other System APIs and other process APIs only. And System API should only talk to the back end systems. Correct. But no such rules are applicable for the event driven architecture in general.

Okay? So there is no such restriction in general for the Ada. It’s like they can be operating with just any producer publishing the events and any consumer subscribing to the events via the messaging broker. And API connectivity restricts communication patterns according to these three tires, right? Like it should be from top to bottom and all. But whereas the application services or components that are exchanging the events via this messaging broker has no such rule. Like we just discussed, API implementations typically have well defined static dependencies on other APIs, okay? Or the back end systems. How? For example, in the design time itself, we know that this particular Experience API talks to this particular process API.

Similarly, this particular Process API talks to this XYZ Process AP and System API Same way we know which system API talks to which back end system at the design time. That is where these are static dependencies. Okay? But on the pro side, the event driven architecture says that all its dependencies are dynamic. Meaning they can happen at Runtime. Because why? Like we discussed in the previous lectures, in this particular EDA section, the producers keep publishing the events to the messaging broker or the router. And consumers on the right side can be dynamic in nature. There can be a consumer at the point of time today, and there can be not one tomorrow, and there can be more consumers added with time.

So it’s just that at that point of time when the message is published who are all active consumers or have their policies defined, they will be consuming it even, right? So they’re dynamic in nature. There are no direct dependencies from the publisher and the consumer side. Okay? So the only dependency that the EDA has is the event types that are defined as rules or the policies in the messaging broker telling which consumer is interested in which particular event. Okay? So the event types that are exchanged between producers and consumers are over the only static dependencies, but not the dynamic dependencies. That is why in EDA, the relationship can change dynamically. Okay, so the graph is not static. That if you draw for API connectivity, the graph is kind of static.

Someone can just go and draw any time that this is the dependency for the Apled connectivity. This process API calls the system API, et cetera, et cetera. But for EDA, such a diagram can be drawn, but it is dynamic. It may change tomorrow. Okay? It can be completely changed. The relationships change on the fly as per the need. And one more dependency is that the event driven architecture requires a messaging worker like you already know, which is an additional component in the architecture which is not ever present or needed for the API connectivity.

API Led connectivity, and in particular in the application networks, mostly revolve around the API centric assets, like the Exchange assets, AP interfaces, Ramls, et cetera. Right? Whereas the event driven architecture revolves around the assets like the destinations, publishers, even types, consumers, et cetera. Terminology wise. And the last one is that the API policy can be enforced on the APIs in the API manager, right for the NFR sandal, whereas the same is not applicable for the Ada. There is no such thing. Like we can apply the APA policies equivalent to the event driven architecture when it comes to the pros and cons. All right, let us move on to the next lecture in the course. Happy learning.

6. Using EDA in API-led connectivity

Let us now see how this EDA can be fit into the API Led connectivity to get the best out of both. Okay, as you already know, API Led connectivity has some architectural constraints that experience APA must only invoke process APIs, and process APIs must only invoke system APIs and other process APIs. And system APIs must only communicate with the backend systems. Correct? We discussed this so many times, but this constraints brings order and predictability to the communication patterns and application networks because it is crystal clear who calls what and what is expected from what layer, et cetera. When event driven architecture is applied in the context of the Apled connectivity, then the application components exchanging events are predominantly APA implementations, correct?

Otherwise, what is the need of bringing Et EDA into Apled connectivity? Meaning, we want to still develop APIs only, but leverage the benefits of even driven architecture in this API world so that we can achieve could be performance or some more benefits out of it. So this should somehow fit into the rules or the constraints of the April activity. So here, even though we want to make benefit of EDA, API should not be lenient. Here, EDA should be bit lenient, meaning it should only take some subset of the rules which EDA has and fit into the API connectivity. Okay, let us see. What are those? In general? Even driven architecture by itself is agnostic about the three layers, right? Because there is no such thing as the experience, process and system layer in EDA.

Okay? They are agnostic to these three layers of API connectivity. And it does not restrict like event exchanging between the AP implementations in different tiers. But breaking the communication patterns of API Led activity through some unrestricted event exchanges and all will risk the whole purpose of the API connectivity. That is why what we have to do is, even though it is not a general EDA rule, we have to apply some extra rules to this EDA with respect to the API connectivity so that it fits well. Importantly, the API connectivity is an APA first approach which does not rule out the exchange of events, but it views it as an addition to the APA invocations only. Okay? Meaning, like I said before, this EDA is only to make the APA lead more rich or more robust only. Okay? We are not bringing the complete aspect of EDA into this API activity. We don’t want full benefits. If you bring it, then what happens is the API connectivity rules will be broken unnecessarily.

So we have to make the correct things used from the EDA architecture. So it is therefore advisable to require API implementations that exchange the events to follow communication patterns in accordance with the Apollo connectivity. Okay, somehow, like how the Http communication is happening in three layers, et cetera. Same way, even for the Asynchronous event exchange also should happen in rules according to the Apex connectivity only how rule number one any APA implementation that publishes events should define its own destinations, meaning its own queues, topics, et cetera. Okay?

To send those events to. So that is just like how each layer has one API. A dedicated queue or topic will be assigned for the each Layer, Experience, Process and System API. All right, then the second rule is the destinations belonging logically to the same Apled Connectivity tire as the API implementation publishing given to them. This way, the destinations belong logically to same Apled Continuity tire as the AP implementation publishing events to them. Which means a System API publishes events to destinations that belong to System APA tire. Okay? So they can be referred as System Events. Just like how we call APIs and system. APIs? We can call these as system events. Similarly, a Process API publishes events to the destinations that are belonging to the Process API tire only, so they are called Process Events. Similarly, EA Experience API publishes events to its same Experience API Tire which is called as Experience events.

Okay? And any API implementation that consumes events must not do so from the destination that belongs to the higher tire than the consuming implementation itself. Okay? So just like how EXP can call only PRC and PRC can only call PRCR System. Same way when the events are published and all, they should only consume from the lower tires, not from the higher tires. Okay? So that the same kind of principle that we have in the Http communication will be followed in the Message exchange also. Otherwise, what happens? Experience can start consuming from the System layer. System can start consuming from the Experience layer. All the rules will be broken. So it should be just that they should be consuming from its previous tire only.

Only the Process API has exemption that it can consume events from System or Process. Just like how the Process API can call another Process API System API but remaining all should be interacting with just the tires which are adjacent to it. Okay? System should only with the backend system queues and the Process AP and Process should only do with the Experience layer. Okay? System cannot directly go and talk to the Experience layer queues and all. It cannot put message there, consume message from there. Okay, so this is what I try to depict on the diagram which you are seeing in front of you. How the messages can be exchanged between the layers and which layer can talk to what layer.

Okay? This is what is the architecture or design, how it looks when the Apled Connectivity is used with addition of the EDA. So EDA once again, remember that we are not leveraging full properties or benefits. It’s not a fully even driven architecture. We are taking subset of some rules from the EDA, putting or fitting it inside the apolled Connectivity and applying API Led to connectivity rules on the EDA to make it robust or effective without breaking the rules of the Apollo connectivity. All right, let us move on to the next lecture in the course.

7. Anypoint MQ

As now you have seen how EDA fits in the API Led connectivity. What tools from the Mule Soft can enable this? Okay, there are third party as well. You can use the messaging brokers which are non Mule Soft like say Labit MQ or Active MQ. Are there many popular JMS based Asynchronous messaging brokers? But the one that comes from the mule soft is the any point MQ? Okay? It’s a messaging queue which helps you to design these kind of architectures with EDA fitting into the April. Okay? So let us see what benefits we get or what the MQ offers from the mule software, which is Any Point MQ. First of all, Any Point MQ is an Any Point platforms multitenant cloud based messaging service. Okay? Remember that this is a multitenant one.

You won’t get like a private VPC based MQ for your own purpose. This is a multitenant cloud based only no on premises. And this is only available in the mule. Soft hosted any point platform. Because you know, right, there are many deployment models. We have seen Mule Soft hosted Any Point platform, customer hosted Any Point Platform and the combination of customer hosted and Mule Soft hosted runtime plane and control planes, right? This one will be helpful only in the Mule Soft hosted endpoint platform. Okay? You can’t have it on the customer hosted ones purely cloud based messaging queue. And what it offers, it offers role based access control in line with the rest of the enemy platform. Just like how you can control access or things with respect to the user roles which we have seen in some of the very previous lectures in this course. Same kind of role based access control can be done on the Any Point MQ.

Also, who can access we can see who can do things on the Any Point Time Queue. It also provides token based client access control. Like client credentials can be there and someone can using those client credentials access the Any Point Time Queue like putting messages into that, get a consuming message into that, et cetera. It implements an Async messaging model using queues and message exchanges and the bindings between them. These must reside in one of the AWS regions supported for the repentance. Okay, this is something like you have to choose, okay, you are from which region? Like Asia Pacific? If you are Pacific, which region? Sydney region or Singapore reason or US. Region. So you have to select the reasons and the queue will reside there.

So ideally it is preferable that you choose the reason. Closure are same as your runtime manager reasons wherever your runtime apps run. So choose the same reason so that the latency issues won’t come. Okay? It supports point to point pub sub, first in, first out queues, payload encryptions, persistent and durable messages, dead letter queues, and the time to leave on the messages. All these features, these are general features given by most of the messaging brokers. The same features come with the Any Point MQ as well. It also exposes Rest API and an Any Point connector for the mule runtime. Okay? On top of that, this means that message producers and consumers can be located anywhere as long as they can make AP invocations to the mule stuff MQ. Correct? Right? Because if it is Any Point Connector, okay, only mule applications who are implementing or making use of this Any Point MQ can leverage the Any Point connector because they have Rest API as well.

Any non mule applications who can write in Java, dot netsh or whatever language it is, they can using this Rest API put myself or consume myself from the Any Point MQ. So it is agnostic to the tool stack on which the implementation is being done. Okay? It also has a web based management console just like how you can manage run time Manager Components API manager components on the Any Point cloud hub platform. Same way it has a web based management console in the Any Point platform web UI. OK? In Any Point MQ, messages can be sent to queues or message exchanges and consumed only from the queues. Okay? So therefore message exchanges must be configured to distribute the messages sent to them to one or more queues in order for those messages to be consumable. Okay? So if you are very familiar with the JMS world then this message exchanges is not a new term. It is nothing but similar to the topic, okay? Message exchanges broadcast whereas the queues are point to point kind of thing. Okay? But what the Any Point MQ design is telling is if you use message exchange, which is a topic kind of behavior, publisher can just publish to the message exchange. But for the consumer to take it, you have to configure two at all queues that message exchange to be forwarded so that from those queues the consumers will consume. So it’s like one queue is one consumer here. Okay? So this is how you have to implement your Any Point of queue based design and architecture in the APA delearning.