We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Service oriented architectures (Hardcore separation of concerns)

Formale Metadaten

Titel
Service oriented architectures (Hardcore separation of concerns)
Serientitel
Anzahl der Teile
150
Autor
Lizenz
CC-Namensnennung - keine kommerzielle Nutzung - Weitergabe unter gleichen Bedingungen 3.0 Unported:
Sie dürfen das Werk bzw. den Inhalt zu jedem legalen und nicht-kommerziellen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen und das Werk bzw. diesen Inhalt auch in veränderter Form nur unter den Bedingungen dieser Lizenz weitergeben
Identifikatoren
Herausgeber
Erscheinungsjahr
Sprache

Inhaltliche Metadaten

Fachgebiet
Genre
Abstract
In other words: what would win, a monolithic empire death star, or a flexible modular reble fleet? I've recently built two systems that were highly service oriented. Instead of one large applications, they were split into many small parts. Two layers of APIs, message queues (ZeroMQ) for the trnasport layer, business specific services (such as integration with external SMS system, and integration with external invoicing system), and a set of business logic specific web applications that the users of the system actually interact with. This talk would be about the benefits and tradeoffs related to un-monolithic and service oriented architectures. And also about using the architecture itself to solve essential complexity instead of solving it by implementing "artificial" restrictinos in a monolithic system. If you split up your system in the right places, a lot of problems solve themselves, at the cost of requiring architectural changes for some types of future change in demands of your system.