Skip to content

Commit

Permalink
docs(adr-3): adr proposal regarding orchestrator
Browse files Browse the repository at this point in the history 
commit 0328c4bfc9ec57ecbcd7049a5526294925af664f
Author: Gerlicher, Tim  SZ/ZHZ-ZA <[email protected]>
Date:   Wed Aug 30 13:30:08 2023 +0200

    Update README.md

commit cf0c7db98add66ef698211815cfc00a3b5892eba
Merge: fcd91bd0 95106224
Author: gerlitmcoding <[email protected]>
Date:   Wed Aug 30 12:51:51 2023 +0200

    Merge pull request eclipse-tractusx#2 from catenax-ng/feat/arc/adr-3-ochestrator

    Docs(adr-3): ADR for orchestrator component

commit 951062248b0bfc44eec2ce868227f5b246ece131
Merge: dbd1f36a 6f8f9de
Author: Gerlicher, Tim  SZ/ZHZ-ZA <[email protected]>
Date:   Wed Aug 30 12:47:16 2023 +0200

    Merge branch 'main' of https://github.com/eclipse-tractusx/bpdm into feat/arc/adr-3-ochestrator

commit dbd1f36a29438e3e43607053f5bb7f34e722fc2e
Author: Gerlicher, Tim  SZ/ZHZ-ZA <[email protected]>
Date:   Wed Aug 30 11:14:00 2023 +0200

    docs(adr-3): add outlook

commit fefad61ac4f8d6df927a9ffbd975580b435fcf8e
Author: Gerlicher, Tim  SZ/ZHZ-ZA <[email protected]>
Date:   Wed Aug 30 10:34:05 2023 +0200

    docs(adr-3): typos

commit 5b7f49a4e03b95607701d5b1aa825234f026a592
Author: Gerlicher, Tim  SZ/ZHZ-ZA <[email protected]>
Date:   Wed Aug 30 10:29:10 2023 +0200

    docs(adr-3): typos

commit 7139ba4b7dd8bc67587321da06b2db4271784f18
Author: gerlitmcoding <[email protected]>
Date:   Wed Aug 30 10:24:49 2023 +0200

    docs(adr-3): typos - Apply suggestions from code review

    Co-authored-by: Sebastian Wurm <[email protected]>

commit 78ae852e756b774a2df80faed9ef599854225d8c
Author: gerlitmcoding <[email protected]>
Date:   Wed Aug 30 10:17:21 2023 +0200

    docs(adr-3): typos

    Co-authored-by: Sebastian Wurm <[email protected]>

commit 1e3830ae9fa4c9a972f196d7efbb5897aaf0e0a5
Author: gerlitmcoding <[email protected]>
Date:   Wed Aug 30 10:16:46 2023 +0200

    docs(adr-3): typos

    Co-authored-by: Sebastian Wurm <[email protected]>

commit 0c8d82fa99e41ba1d4d3570be41de28c396937e2
Author: gerlitmcoding <[email protected]>
Date:   Wed Aug 30 10:16:24 2023 +0200

    docs(adr-3): typos

    Co-authored-by: Sebastian Wurm <[email protected]>

commit 2047c2af6ac0a0ea088cc0222a5e4966780109f8
Author: gerlitmcoding <[email protected]>
Date:   Tue Aug 29 10:48:33 2023 +0200

    docs(adr-3): correct typos

    Co-authored-by: Sebastian Wurm <[email protected]>

commit 962bcb1d2b5e49d36faf421a7c9710f1724b1eae
Author: Gerlicher, Tim  SZ/ZHZ-ZA <[email protected]>
Date:   Mon Aug 28 15:59:11 2023 +0200

    docs(adr-3): spelling mistakes corrected

commit e5e7056eddc37d0078443632e04b58d08a2928bb
Author: Gerlicher, Tim  SZ/ZHZ-ZA <[email protected]>
Date:   Mon Aug 28 12:39:39 2023 +0200

    doc(adr-3): add more information including advantages and disadvantages of all Variants

commit f41add90882fa102211b10d4ebb29f907a6b3f43
Author: Gerlicher, Tim  SZ/ZHZ-ZA <[email protected]>
Date:   Fri Aug 25 16:22:11 2023 +0200

    doc(adr-3): initial adr-3

commit fcd91bd050d0293673679cfde493900c10022f17
Author: Gerlicher, Tim  SZ/ZHZ-ZA <[email protected]>
Date:   Wed Aug 23 13:57:16 2023 +0200

    test1

Co-Authored-By: nicoprow <[email protected]>
  • Loading branch information
@gerlitmcoding @nicoprow
gerlitmcoding and nicoprow committed Aug 30, 2023
1 parent 6f8f9de commit 23b4421
Showing 1 changed file with 124 additions and 0 deletions.
124 changes: 124 additions & 0 deletions docs/decision-records/003-orchestrator_serviceApi_vs_messagebus_approach.md
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,124 @@
<!-- Template based on: https://adr.github.io/madr/ -->

<!-- These are optional elements. Feel free to remove any of them. -->
<!-- * status: {proposed | rejected | accepted | deprecated | … | superseded by [ADR-0005](0005-example.md)} -->
* status: proposed
* date: 2023-08-29
* deciders:
<!-- * informed: {list everyone who is kept up-to-date on progress; and with whom there is a one-way communication} -->
---
<!-- we need to disable MD025, because we use the different heading "ADR Template" in the homepage (see above) than it is foreseen in the template -->
<!-- markdownlint-disable-next-line MD025 -->
# Using an API based service component approach for orchestration logic instead of a message bus approach

## Context and Problem Statement

Based on this [github issue](https://github.com/eclipse-tractusx/bpdm/issues/377) an orchestration logic is needed for the bpdm solution to manage communication between services and handles processing states of business partner records during the golden record process.

Orchestration logic can basically be realized via an API and service based approach or via a message bus approach. To keep on going with the development of BPDM solution a decision is needed which approach the team will follow to plan and implement the next tasks.

## Considered Options

1. Using an API based service communication with an orchestrator service to handle business logic
2. Using a messaging based service communication with a message bus to handle business logic
3. Using a combination of orchestrator service together with a message bus to handle business logic

## Decision Outcome

### Chosen option: "1. Using an API based service communication with an orchestrator service to handle business logic", because

* **Interoperability & Standardization**:
* Interoperability can be better realized and standardized via standardized APIs to grant third party services access and helps to prevent a vendor lock-in.
* Especially when thinking about BPDM as a reference implementation and there might be multiple operating environments in the future that offer BPDM solution. <p>

* **Flexibility**:
* Thinking about future requirements that might come up like decentralized Gates, encryption of data, not storing business partner data for long-term, this solution is more flexible to deal with new requirements. <p>

* **Anonymity**:
* Having a service that works as a proxy for the connection between Sharing Member data and cleaning services, can ensure that the uploaded data stay anonymous. <p>

* **Abstraction**:
* The API based service approach allows better abstraction (who can access which kind of data?). Based on API access and the modelling of input and output data object, we can easily configure/decide which service should be able to access which kind of data or only sub-models of the data
* Instead in a message bus and topic approach every subscriber would be able to easily see all data and can draw conclusions on ownership information and which sharing member was uploading which business partner data. <p>

* **Cost-effectiveness**:
* Building up on the existing infrastructure instead of setting up and operating an additional message bus system. <p>

* **Request/Response Model**
* Defined order via API, but not via messaging
* Defined input and output formats / data models for service interaction

### Decision against option 2. "Using a messaging based service communication with a message bus to handle business logic", because

* **Error handling**:
* Error handling, error detection and tracing might become very complex in an event-based message bus architecture
* Also race conditions might get problematic for event-based development <p>

* **Missing expertise**
* Missing expertise in Catena-X team in regards to event-based data exchange (RabbitMQ, AMQP)
* Missing expertise in operating and configuring securely a message bus system
* Higher Effort in research, because of new concepts and business-logic for data processing and service interaction <p>

* **Cross-cutting concerns**:
* Cross-cutting aspects should not depend on technology specific solutions like a message bus
* Also there are already existing standard solutions available in for example Kubernetes or Spring Boot Framework <p>


* **Difficulty in interoperability and integration**:
* Services in the chain need to 'play ball', they need to integrate into each other very well so well-defined payloads is important (Event Queue will just take any payload at first naturally)
* No Request/Response Feedback <p>

* **Data Security**:
* Cleaning requests in the queue are visible to every Gate. Even if business partners are anonymous in principle this could be a security issue.
* Separate queues can also be problematic as it makes it visible in a message bus which Gate shared what business partner. So conclusions can be drawn which Member interacts with which business partners. <p>

* **Higher Costs**:
* potential higher cost operating cluster<p>

* **Complexity**:
* More complexity due to the Gates having to integrate to a message bus as well as an additional service
* More complexity, because of bigger changes in business logic <p>

* **Less flexibility for maybe upcoming requirements**
* Hypothesis: We assume it will be easier to implement EDC with an API based service orchestrator solution than with a message bus system
* Not clear how message queuing based solution would work with EDC component/communication
* Not clear how a decentralized approach would look like with an message bus approach <p>

### **Decision against option 3. "Using a combination of orchestrator service together with a message bus to handle business logic", because**

* Please see the downsides above for option 2

### **Sum-up:**
> Arguments or advantages that comes with message bus, like a push mechanism, decoupling of services and asynchronous communication can also be realized via an API-based service interaction approach. Use cases for message bus are more focused on scenarios where you have to handle a lot of messages together with lots of message producers and consumers where most of them might be unknown in the network. But in our use case services are well-known and the number of producers and consumers are not that high. In addition, instead of communication via message bus, a callback approach for asynchronous communication might be more sufficient and could also be easier secured via EDC communication.

* **Push mechanism**: In regards to push mechanism, we do not have time critical requirements so polling is suitable for the moment. And in addition a push based solution can also be realized without a message bus in between the services.

* **Decoupling of services**: Making services more independent or decoupled is no good argument, because good API design also solves this issue and makes the services even more decoupled. In a message bus approach, every service depends on the input data and format which another service pushes inside

* **Asynchronous communication**: Asynchronous communication can be done via message bus as well as with API based communication

> **To sum up the benefits that brings a message bus approach, cannot be fully leveraged in our use case, so that the downsides outweigh the possible advantages.**
## Alternatives in more detail
### Using an API based service communication with an orchestrator service to handle business logic

[Here](https://github.com/eclipse-tractusx/bpdm/issues/377#issuecomment-1683880275) you can find a description of the first Variant.<p>
**❗Disclaimer**: Keep in mind that the shown interaction diagram is only a rough idea and the business logic and process flow must still be iterated and adjusted!

### Using a messaging based service communication with a message bus to handle business logic

[Here](https://github.com/eclipse-tractusx/bpdm/issues/377#issuecomment-1683924791) you can find a description of the second Variant. <p>
**❗Disclaimer**: Keep in mind that the shown interaction diagram is only a rough idea and the business logic and process flow must still be iterated and adjusted!

### Using a combination of orchestrator service together with a message bus to handle business logic

[Here](https://github.com/eclipse-tractusx/bpdm/issues/377#issuecomment-1683942552) you can find a description of the third Variant. <p>
**❗Disclaimer**: Keep in mind that the shown interaction diagram is only a rough idea and the business logic and process flow must still be iterated and adjusted!

<!-- This is an optional element. Feel free to remove. -->
## More Information / Outlook

(Further/Next Steps to be discussed)

Having in mind that a pushing mechanism might become required for a more efficient process orchestration or some other cases, it is not excluded to introduce an event queuing technology. We are open minded to this. But from current perspective we don't see hard requirements for this, so we want to focus on a minimal viable solution focusing on simplicity based on the KISS principle.

0 comments on commit 23b4421

Please sign in to comment.