Soa в примерах

Предположим, вы хотите послушать музыку, записанную на компакт диске: берете диск, вставляете его в плейер, включаете, и слушаете. Тем самым CD-плейер предоставляет вам сервис «проигрывания CD-дисков». И если нужно, вы можете заменить этот плейер на другой, лучшего качества. Вы можете вставить тот же самый CD в портативный плейер или в мощную стереосистему. Все эти устройства будут предоставлять один и тот же сервис, но различного качества. Точно так же в SOA сервис предоставляют программные компоненты, которые могут быть заменены другими, если потребуется изменить качество.

Этот пример иллюстрирует принципиальное отличие SOA от объектно-ориентированной архитектуры, в которой данные и их обработка неразрывно связаны: каждый CD должен был бы поставляться со своим собственным плейером.

Одно из главных достоинств идеи SOA — реальная поддержка бизнес-процессов, а не отдельных взаимодействий между прикладными компонентами, и простота адаптации к изменениям в этих бизнес-процессах. Возьмем, к примеру, крупную организацию по продаже модной одежды, имеющую международную сеть розничных магазинов. Такая компания должна часто менять ассортимент, чтобы постоянно быть на острие моды. Для покупателя изменение ассортимента — это новые находки стиля или изменение цветовой гаммы. Но для продавца это может означать смену производителей тканей и фурнитуры. С точки зрения программного обеспечения, поддерживающего бизнес-процессы такой компании, переход к другому поставщику будет сопряжен с большими трудностями, если тот использует другое ПО, несовместимое с ПО продавца. Но предположим, что нам удалось выстроить в этой торговой сети, включая возможных поставщиков, программную систему на базе SOA. Тогда изменения на уровне ПО сведутся к настройкам WSDL-интерфейсов и определению новых соглашений об уровне обслуживания, а прикладные решения у каждого из участников бизнес-процесса не претерпят каких-либо изменений. SOA поддерживает «горизонтальные» изменения в бизнесе, когда основные бизнес-операции остаются неизменными — меняются внешние участники бизнес-процесса.

Еще один вариант — сугубо внутренние изменения в бизнесе. Например, дом моды принимает решение расширить свою розничную сеть с помощью бутиков по принципу «магазин в магазине». При этом основная часть бизнес-операций компании останется без изменений, но в ее собственной программной системе должны быть учтены новые условия соглашений об аренде. В данном случае серьезному пересмотру может подвергнуться внутренняя система компании, но, благодаря SOA, это никак не отразится на взаимодействии с поставщиками.

И, наконец, еще один возможный и наиболее серьезный тип изменений в бизнесе — вертикальные изменения. Например, компания отказывается от продаж собственного ассортимента одежды и переходит исключительно на аренду помещений. Это приведет к серьезной структурной перестройке, поскольку появляются новые взаимосвязи в бизнесе, новые процессы и ПО. Однако использование SOA-инфраструктуры, формируемой исходя из задач бизнес-процессов, а не программных приложений, позволяет на уровне архитектуры четко определить, какие компоненты должны быть добавлены, модифицированы или удалены, чтобы отразить изменения в ведении бизнеса компании.

Большинство изменений в SOA — задача не разработчиков, а архитекторов программных систем. В компетенции разработчиков остается создание функциональных модулей, которые будут определены в качестве сервисов, но задачи сопряжения этих сервисов в единое целое для реализации бизнес-процесса должны решаться на уровне моделирования.