All time specifications are Central European Time (UTC+1).📘Final Workshop Proceedings
Prof. Dr. Olaf Zimmermann
University of Applied Sciences of Eastern Switzerland, Rapperswil
API stands for application programming interface, but might as well mean access to services via protocol for integration. Message-based APIs and the services they expose must be carefully designed to achieve qualities such as composability, efficiency, and evolvability; project context and application domain challenges drive the architectural decisions required regarding communication, coordination and consistency.
This talk introduces a stepwise, incremental and iterative design practice that leverages proven principles and patterns to jumpstart greenfield API design and service engineering. For brownfield scenarios, it proposes an interface refactoring catalog to resolve design smells frequently occurring in practice. Common design tradeoffs in these scenarios are discussed in the form of reusable Architectural Decision Records (ADRs).
Camunda GmbH, Germany
The era of monolithic information systems is long gone. Instead, many systems are distributed. Gone are central databases. Gone are central transaction managers. Services are now connected by middleware, such as an event streaming platform or a process orchestrator. Again, architects must decide whether to include a transaction mechanism with ACID properties or to go transactionless. Both have advantages and disadvantages that affect the system design.
This talk discusses how to move from monolithic process applications to distributed ones without a transaction manager. We discuss how this move affects the application design and the process models (business logic). Distributed applications have many advantages, i.e., polyglotism, horizontal scaling, and fault tolerance, but they need to deal with communication overhead, the absence of a central database, and the risk of potential inconsistencies.