Веб-сервисы тогда и сейчас
SOA(P) Services
SOA появилась как парадигма распределенных вычислений, работы электронного бизнеса и корпоративной интеграции.
Выгоды SOA
- Динамичность (деление нагрузки по нескольким инстансам сервиса)
- Повторное использование (одни и те же сервисы могут повторно использоваться разными системами)
- Модульность (сложные сервисы состоят из более простых)
- Распределенная разработка (параллельная разработка сервисов по согласованным интерфейсам)
- Интеграция гетерогенных и легаси систем используя стандартные протоколы (SOAP)
Отдельно авторы выделяют использование стандартных языков (BPEL) для оркестрации сервисов в сложные композиции.
Далее авторы описывают причины частых провалов SOA:
- Хайп привел к тому, что внедряли там, где не нужно
- Отсутствие общепринятых стандартов привело к различиям в методах спецификации и реализации
Авторы дают отсылку к материалу «Managing Complexity of Information Systems - 2012 - Lemberger - Why Has SOA Failed So Often» и чтобы раскрыт тему глубже, приведу достаточно объемную цитату из этой статьи:
✏️«Many companies did things in the wrong order. Rather than building a robust and scalable architecture for their stable, core processes, they tried to achieve flexibility prematurely. In the most extreme cases, this led to the so-called alignment trap, namely the IT department spending most of their energy and money on maintaining an architecture that never had the time to become mature because of premature attempts to align IT with ever- changing business requirements (see section 3.3.3). It should be emphasized that an SOA architecture, if useful at all, should only be considered as a last step in any enterprise-architecture maturity model. Robustness considerations should come first.
Among companies that tried to implement SOA, many did not need it in the first place. Companies that do not benefit from flexible business processes have no reason to switch to a service approach, as this will incur heavy financial and organizational risks for an often unpredictable outcome.[...]
[...] It remains true, however, that, independently of any flexibility considerations, a service approach can still be partly motivated by reuse considerations, as an implementation of simplicity through reduction and simplicity through organization principles.»
Как своего рода альтернатива SOAP появился REST (simpler, lightweight, and cost-effective). Основными потребителями REST считались и считаются люди, а не компьютеры, появилась пользовательская композиция (mashups) и произошло отделение решений на базе семантики (планирование, формализация) от решений на базе workflow (mashup, bpel4rest).
Таким образом, большинство обозначенных ранее проблем были решены. И тут вдруг среда, в которой разрабатываются и выполняются сервисы, становится более открытой и динамичной, да еще и постоянно изменяется. И вместе с этими изменениями среды пришли проблемы гибкости и новые вызовы:
- self-configuring
- self-optimizing
- self-healing
- self-adapting
- IoT
- Prosumers
#msaevolutionwspub2 #msaevolutionwspub #перевод
SOA(P) Services
SOA появилась как парадигма распределенных вычислений, работы электронного бизнеса и корпоративной интеграции.
Выгоды SOA
- Динамичность (деление нагрузки по нескольким инстансам сервиса)
- Повторное использование (одни и те же сервисы могут повторно использоваться разными системами)
- Модульность (сложные сервисы состоят из более простых)
- Распределенная разработка (параллельная разработка сервисов по согласованным интерфейсам)
- Интеграция гетерогенных и легаси систем используя стандартные протоколы (SOAP)
Отдельно авторы выделяют использование стандартных языков (BPEL) для оркестрации сервисов в сложные композиции.
Далее авторы описывают причины частых провалов SOA:
- Хайп привел к тому, что внедряли там, где не нужно
- Отсутствие общепринятых стандартов привело к различиям в методах спецификации и реализации
Авторы дают отсылку к материалу «Managing Complexity of Information Systems - 2012 - Lemberger - Why Has SOA Failed So Often» и чтобы раскрыт тему глубже, приведу достаточно объемную цитату из этой статьи:
✏️«Many companies did things in the wrong order. Rather than building a robust and scalable architecture for their stable, core processes, they tried to achieve flexibility prematurely. In the most extreme cases, this led to the so-called alignment trap, namely the IT department spending most of their energy and money on maintaining an architecture that never had the time to become mature because of premature attempts to align IT with ever- changing business requirements (see section 3.3.3). It should be emphasized that an SOA architecture, if useful at all, should only be considered as a last step in any enterprise-architecture maturity model. Robustness considerations should come first.
Among companies that tried to implement SOA, many did not need it in the first place. Companies that do not benefit from flexible business processes have no reason to switch to a service approach, as this will incur heavy financial and organizational risks for an often unpredictable outcome.[...]
[...] It remains true, however, that, independently of any flexibility considerations, a service approach can still be partly motivated by reuse considerations, as an implementation of simplicity through reduction and simplicity through organization principles.»
Как своего рода альтернатива SOAP появился REST (simpler, lightweight, and cost-effective). Основными потребителями REST считались и считаются люди, а не компьютеры, появилась пользовательская композиция (mashups) и произошло отделение решений на базе семантики (планирование, формализация) от решений на базе workflow (mashup, bpel4rest).
Таким образом, большинство обозначенных ранее проблем были решены. И тут вдруг среда, в которой разрабатываются и выполняются сервисы, становится более открытой и динамичной, да еще и постоянно изменяется. И вместе с этими изменениями среды пришли проблемы гибкости и новые вызовы:
- self-configuring
- self-optimizing
- self-healing
- self-adapting
- IoT
- Prosumers
#msaevolutionwspub2 #msaevolutionwspub #перевод