-
Notifications
You must be signed in to change notification settings - Fork 4
BotWorks 102: Bot Ecosystem some defining characteristics
BotEvangelist edited this page Dec 3, 2018
·
2 revisions
There are some important concepts that distinguish the Bot Ecosystem from more traditional approaches
- Xtreme Decouplement: Each Bot at work in the ecosystem is a fully independent execution entity that interacts with other components in the ecosystem strictly through messages sent via a virtual message bus (currently the underlying implementation used is Kafka). There is no sequencing requirement to messages. It is expected that any messages that needs to be processed after the current message handled by the Bot will in fact be created by that Bot itself.
- Asynchronous: A Bot has no awareness of where a message comes from nor does it have any concern as to what Bot will process the message that is emitted after the atomic task is performed.
- Stateless Bot: Hoarding of information is not allowed in the Bot world. The execution of any single message cannot be influenced by any previous messages that the Bot has handled.
- Stateful message: When a message is output from a Bot, it may or may not contain information that was present in the incoming message. Any state that the ecosystem needs to have is contained in the tags section of the messages and/or in the data sections (rarer).
- Persistence: Since the state of the system is in the messages, the persistence needs to be provided by the message bus. In the current implementation this is Kafka, which is a very robust persistence platform.
- Fault Tolerance: Since each message is independent, message that fail because of some external condition can be replayed by sending them back through the message bus. This allows the system to not only be fault tolerlant, but to automatically resume at the point of failure without any external intervention.
- Distributed Scaling: All Bots in the ecosystem feed from the same Kafka Topic, making it very easy to scale up the capacity by dynamically adding whatever type of Bot might be in short supply and causing a bottleneck.
- Message based Workflow: Each message that is processed by a Bot contains inside the message a reference to the template for creating the message that will be output by the Bot. This allows for the creation of simple workflows by proper design of a set of messages and without the need for a conventional prescriptive workflow engine. More complex workflows may be orchestrated by connecting sets of simple message based workflows.
- Monitoring 101: Since the entire system is based on messages flowing in and out of the message bus, it is very simple for monitoring processes to subscribe to messages for monitoring purposes without impacting the rest of the system.
- Play it again Sam: One of the motivations of embedding the business logic in the messages is the side-effect that it provides Intrinsic Regression Testing for the Bots themselves. If you send the same message to a Bot, the message output from the Bot should be the same as it the message that was output the previous time the message was sent. Any change to the message - beyond simple timestamp elements will be easily detected by automated testing tools.
- Robust Error Handling: Every incoming Bot message is required to have a reference to a template that will be used construct an output message that reflects the error condition. This allows for a centralized monitoring and remediation of errors that occur in the ecosystem.