Пожалуйста, оставьте ваши данные
Менеджер свяжется с вами, как только получит вашу заявку
Классическое введение в COА
Перевод статьи Дэна Норта - "A Classic Introduction to SOA"
Эта статья впервые была опубликована в 2007 году в майском номере журнала Better Software.
За последние несколько лет сервис-ориентированная архитектура (СОА) стала основным подходом к проектированию и разработке корпоративного программного обеспечения. Как и большинством новых технологий, внедрением СОА заведуют поставщики программного обеспечения и делают они это, используя свои специфические инструменты и преследуя свои же корыстные интересы. А в интересах производителей что? – Естественно, подчеркнуть сложность СОА и затем обеспечить своевременное и выгодное решение. Это приводит к тому, что многие системные архитекторы фокусируют свое внимание именно на технологической составляющей СОА, когда в действительности самый важный критерий для сервис-ориентированного архитектора — прежде чем с усердием браться за технологии — хорошее понимание бизнеса.
В этой статье представлен простой, независимый от технологий подход для проектирования и развития СОА. Вы не увидите такие акронимы, как WSDL, SOAP или REST, и я обещаю не использовать технические термины вроде «оркестрация», «реализация» и «управление». Благодаря этому, вы сможете проектировать и внедрять сервис-ориентированные архитектуры, которые действительно будут служить вашему бизнесу.
Опишем сценарий с точки зрения бизнеса
Представьте, что вы хотите внедрить службу бронирования отпусков и сделать ее частью корпоративной системы. Первым делом убираем все упоминания о компьютерах или современных технологиях. Это позволит вам сосредоточиться на бизнес-целях, не отвлекаясь на технологические аспекты. Другими словами, это позволяет отделить «что» от «как».
Простой способ сделать так – это описать бизнес взаимодействия таким образом, как будто они происходят в компании в 1950-х. Назовем нашу компанию Big Corporation, Inc. Это классическая корпорация 1950-х годов – иерархическая, с огромным количеством отделов, содержащая бесчисленное множество людей, которые являются винтиками в Большой машине. Они все знают свои места, их должностные функции ясно определены, и нет запутанных организационных границ.
Помните, позиции «менеджер проекта» пока не существует. Вы можете воспользоваться только телефоном и внутренней почтой. Вот как может пойти сценарий.
Боб оформляет отпуск
Боб работает в Big Corporation, Inc. Боб хочет взять отпуск. Он усердно работал и думает, что этого заслуживает. Поэтому Боб идет к полке канцелярских принадлежностей, берет бланк заявления на ежегодный отпуск и старательно его заполняет. Это довольно обычное заявление: он заполняет своё имя, отдел, даты отпуска и затем подписывает документ. В дополнение он указывает свой добавочный номер телефона в нижней части заявления.
Боб относит заявление своему линейному руководителю, который его подписывает, и потом Боб отправляет документ по внутренней почте. О, внутренняя почта! Она откровенно ненадежна, но он в любом случае отправляет форму и воссылает тихую молитву. Он делает заметку в своем настольном календаре, чтобы не забыть проверить результаты через неделю.
Затем он возвращается к работе на его важной административной должности.
Спустя неделю календарь Боба напоминает ему, что Боб не получил ответа от отдела кадров, поэтому он решает позвонить им.
- «Боб» как вы сказали? Нет, у нас нет вашей заявки на отпуск. Да, конечно, я бы знала, я обрабатываю все заявления о предоставлении отпуска.
Извините!
Непоколебимо Боб заполняет другое заявление, оставляет его во внутренней почте и возвращается к работе. Через пару дней конверт падает в почтовый ящик Боба. Его отпуск был утвержден – отличная новость! Теперь нужно забронировать отель и рассказать жене и детям.
Повторим сценарий в сервис-ориентированных терминах
Теперь, давайте-ка, воспроизведем этот сценарий и определим, где используются услуги, и на что похожи аспекты взаимодействия. С точки зрения СОА, отдел кадров – это поставщик услуг. Одной из услуг является планирование ежегодных отпусков. Боб является клиентом или заказчиком (потребителем) услуги. Бланк заявления на отпуск описывает заказ на предоставление услуг. Заполненный бланк в таком случае – асинхронное сообщение: Боб не приостанавливает свою деятельность, чтобы дождаться ответа, вместо этого он продолжает свою обычную работу.
Внутренняя почта – это передача сообщений, в этом случае – ненадежная. К счастью, у Боба есть протокол обработки ошибок, а именно тайм аут. Через неделю календарь оповещает о том, что следует позвонить в отдел кадров. Телефонный звонок – это синхронное взаимодействие — он говорит по телефону в режиме реального времени. Затем он реализует стратегию с исправлением ошибок, которая заключается в том, чтобы еще раз отправить сообщение. Обратите внимание, что вся последовательность – напоминание в календаре, ожидание, телефонный звонок и повторное отправление сообщения – была необходима только потому, что передача сообщения была ненадежной. Мы вернемся к этой мысли позже.
Второе асинхронное сообщение отправлено, и в этот раз Боб получает ответ на свою входящую почту. Это асинхронный ответ. В итоге Боб соотносит ответ с первоначальным запросом и обмен завершен.
Используем бизнес-ориентированный сценарий для изучения сервис-ориентированных допущений
Технические термины в предыдущем разделе могут быть вам непривычны, если вы не опытный разработчик СОА. Тем не менее они имеют прямую, один к одному взаимосвязь с терминами в бизнес-версии, преимущество которой – реальность и осязаемость. Исходя из предыдущего примера, ниже представлены некоторые обсуждения и вопросы, помогающие разъяснить допущения, которые могут появиться у ваших архитекторов в процессе проектирования сервиса:
Надежность передачи сообщений
Из описания мы узнали, что система доставки сообщений внутренней почтой ненадежна. Действительно ли это то, что мы не можем контролировать? Можем ли мы сделать процесс более надежным или даже вовсе заменить его? Если нет, то каковы требования, в рамках которых мы работаем, и на какой уровень сервиса можно рассчитывать?
Стратегия обработки ошибок
Сценарий не описывает, как теряется первое сообщение. Было ли оно вообще доставлено или потерялось, попав в отдел кадров? В последнем случае может быть намного больше потенциально ошибочных ситуаций, которые стоит учесть. Например, если кто-то обновляет записи о работе Боба, чтобы уменьшить количество оставшихся дней отпуска, а заявление теряется перед тем, как отпуск был утвержден, то его данные находятся в рассогласованном состоянии. Записи не будут отражать реальность: отдел кадров “потерял” несколько дней отпуска Боба. Иными словами, сервис бронирования отпусков должен быть транзакционным. Это похоже на ситуацию, когда вы снимаете деньги с одного счёта и переводите на другой – либо оба действия удаются, либо оба действия отменяются.
Ключ к разгадке в телефонном разговоре. Видимо, только один человек занимается заявлениями о предоставлении отпуска, из-за этого вероятность потери запроса на полпути существенно меньше, чем если бы этим занимались несколько человек. Такова особенность реализации сервиса: чем он сложнее, тем больше мы должны анализировать границы транзакций и последствия сбоев на разных этапах процесса.
Те ошибки, которые мы на данный момент обсудили зависят от того, как осуществляется запрос (то есть, как он реализован). Но есть несколько коммерческих причин, почему подача заявления на отпуск может не пройти. На языке СОА это семантика или бизнес-правила. Что если Боб уже израсходовал норму отпуска или же его заявление превышает эту норму? А вдруг менеджер, подписавший заявление, не уполномочен подписывать заявления на отпуск? В этих случаях мы вероятно отправим Бобу ответ, объясняя, почему мы не можем обработать его запрос.
Согласовываем ответы
Боб получает ответ через некоторое время после того, как он отправил первоначальный запрос. В это время он был занят другими делами, поэтому он должен суметь соотнести ответ со своим запросом. Конечно, это легко, потому что у него только одно неподтвержденное заявление на отпуск. Если бы он отправлял и получал много запросов такого характера и все асинхронно, ему нужен был бы более надежный подход к сопоставлению ответов по мере их поступления, например, такой как использование номеров для документов, чтобы их сопоставлять.
Таким же образом, если бы было много людей, отправляющих заявления на отпуск в одно время, внутренней почтовой системе могла бы понадобиться помощь, чтобы избежать перегруженности и соответственно доставки ответов на неправильные почтовые ящики или их полной потери. Очень полезно представлять себе ожидаемые шаблоны использования сервиса в терминах «пиков и долин» и максимального количества одновременных запросов. Это может варьироваться в зависимости от времени суток, недели, месяца или года. Может увеличиваться или уменьшаться в конце недели или в конце месяца, или может быть сезонным.
В нашем примере отпуски цикличны, с максимальными значениями зимой и летом. Мы должны установить, является ли сервис международным, в таком случае зима и лето могут быть в разное время для разных пользователей. Это может фигурировать в наших дискуссиях о соотношении асинхронных ответов.
Доступность сервиса
Говоря об идее пиковых нагрузок, необходимо затронуть более широкий круг вопросов касающихся доступности сервиса. Должны ли мы предоставить соглашение об уровне услуг (SLA), в котором прописывается, скорость отклика сервиса при различных обстоятельствах? Если нет, можем ли мы обеспечить заказчикам то, чего они могут ожидать от нашего сервиса? Мы можем это гарантировать? Должны ли мы отдавать предпочтение одним сервисам и если да, то каким образом? Например, если отдел кадров также бронирует билеты для деловых поездок, они могут оформить все деловые поездки перед тем, как бронировать билеты для отпусков. Кроме того, сервис должен гарантированно обеспечивать определенный процент своей мощности (своих ресурсов) для каждого типа запроса.
Безопасность и соответствие требованиям
В этом примере безопасность, вероятно, не проблема. Вряд ли кто-то захочет подделать заявление на отпуск от имени Боба. Однако, что мы знаем о самом Бобе? Возможно, его начальник отклонил заявление, и Боб подделал подпись своего руководителя. Это было бы вероятно, если бы отпускные Боба отслеживал его начальник, а не отдел кадров. В этом случае мы вероятно рассмотрим более тщательную проверку запроса, такую как (синхронный) звонок менеджеру Боба, чтобы убедиться, что она действительно подписала заявление. В дополнение к нашим собственным бизнес правилам, мы должны учитывать внешние ограничения правового характера, которые могут налагаться на нас. Это особенно реально для систем, сохраняющих конфиденциальной финансовую и личную информацию.
Некоторые наблюдения
Как видите, нам удалось задать несколько полезных вопросов, которые помогают понять природу сервиса без углубления в технологические дискуссии или отвлечения на детали реализации. Ведение обсуждения на уровне бизнеса позволяет понять истинную деловую ценность и цель сервиса, и дает нам возможность исследовать любые сложные аспекты бизнеса независимо от технических вопросов. Фактически у настоящей сервис-ориентированной архитектуры должны быть сервисы с прямым аналогом в бизнесе; в противном случае они едва ли смогут моделировать бизнес-процесс.
Такие абстрактные технические понятия, как «служба обработки и передачи данных» или «служба репликации» не имеют никакого смысла в бизнесе. (Существуют доступные наборы модулей и библиотек, которые технически обеспечивают соответствующую функциональность, но они не могут внедряться и использоваться как сервис). Полезным эвристическим алгоритмом будет отождествить поставщика сервиса с отделом или командой внутри организации. Например, мы можем смоделировать отдел кадров как единого поставщика сервиса, предлагающего ряд услуг, или мы могли бы разделить его на более маленьких поставщиков сервиса, если услуги естественным образом делятся на категории.
Развитие сервиса в бизнес-терминах
До сих пор мы говорили только о начальном проекте сервис-ориентированной архитектуры, но мы также хотим иметь возможность менять и адаптировать сервисы с течением времени. Чтобы понять встречающиеся здесь вопросы, полезно взглянуть на то, в связи с чем сервис может развиваться. Опять же, начнем с бизнес-ориентированного сценария и затем сопоставим его с терминологией СОА.
Сьюзи спасает день
Сьюзи работает в отделе кадров Big Corporation, Inc., обрабатывая заявления на предоставление отпуска. Однажды она получает заявление на отпуск от Боба, тогда она просматривает его оставшийся отпуск и обнаруживает, что количества дней недостаточно. Она замечает, что отпуск неминуем – он хочет уйти в отпуск через два дня. К тому моменту, как ответ дойдет до него, и он отправит заявление повторно, будет уже слишком поздно. Она замечает, что он черкнул свой добавочный номер телефона в нижней части заявления, ну и звонит ему.
- Привет, Боб, это Сьюзи из отдела персонала. Боюсь, я вынуждена отклонить ваше заявление на трехнедельный отпуск; у вас осталось недостаточное количество дней.
- Три недели? Я имел в виду только две недели! Какие даты указаны на этом заявлении?
- с 1-го по 21-ое
- Бог ты мой, простите, там должно быть написано: с1-го по 14-ое. Должно быть, я отвлекся. Я читаю эту статью про летающие автомобили, которые будут у всех в 2000 году.
- Ничего. Я подпишу заявление. Приятного отдыха.
- Спасибо, Сьюзи. Ты действительно спасла мой день!
Со временем она замечает, что все больше и больше людей указывают свои номера телефонов на заявлениях, таким образом она может решать проблемы быстрее. Она решает добавить новое, дополнительное поле на бланке для добавочного номера и называет его «заявление о предоставлении отпуска версия 2».
Некоторое время спустя она получает памятку о новом распорядительном документе. Видимо, все заявления на отпуск теперь должны содержать имя человека, который будет ответственным за рабочие вопросы в отсутствие отдыхающего. Такие правила без исключений вступают в силу немедленно. Поэтому она создает новую форму, версию 3, и рассылает всей компании памятку, в которой говорится, что, к сожалению, версии 1 и 2 больше не будут приниматься. Она также набрасывает черновик со стандартным ответом, чтобы отправить любому, кто будет использовать старые бланки.
Повторим сценарий в сервис-ориентированных терминах
Прокручивая этот сценарий, мы видим, что сервис изменяется дважды по разным причинам. В первую очередь, мы понимаем, что можем предоставить более эффективный сервис, если у запроса есть некая дополнительная информация. Мы публикуем вторую версию договора об оказании услуг – бланк с добавленным дополнительным полем. Обратите внимание, что мы не аннулируем все бланки версии 1. Мы все еще можем обслуживать клиентов, использующих старую версию договора об оказании услуг. Единственное, мы вежливо ухудшили сервис, потому что не сможем позвонить инициатору запроса, если возникнут какие-то проблемы. Это позволяет клиентам выбирать, когда перейти на новый договор об оказании услуг и получить новые возможности, а также обеспечивает слабую связь между модернизацией сервиса и клиентом.
Это наиболее распространенная форма эволюции сервиса. Либо через обратную связь от ваших пользователей, либо исходя из идей вашей собственной организации или конкурентов, вы захотите добавить новые функции или улучшения вашему сервису.
Будьте ответственным, когда вносите изменение, которое заденет работу существующих потребителей сервиса
Вторая ситуация несколько иная. Новый, обязательный элемент данных необходим, без него сервис не может быть реализован. Это означает, что ни один потребитель не может воспользоваться сервисом с существующим договором об оказании услуг и каждый должен «обновить» бланк документа. В связи с тем, что мы ответственные разработчики услуг, мы предоставляем сообщение об ошибке, а не молча сбрасываем все устаревшие запросы.
Эта стратегия, предоставляющая немедленную обратную связь с потребителем известна как «быстрый облом». Это полезно, так как клиент теперь ясно понимает, почему запрос был отклонен (и будет продолжать отклоняться до тех пор, пока он не обновит формат запроса). В ином случае он мог предположить, что неполадка была из-за каких-то инфраструктурных вопросов или временного перерыва в обслуживании и просто пытался бы еще раз отправить запрос.
Как бы аккуратно вы ни развивали сервис, всегда может произойти внезапное существенное изменение, особенно в сильно зарегулированных средах, где регуляторы находятся вне вашего контроля.
Избегайте универсальных доменных моделей
Прежде чем мы покинем Big Corporation, Inc., проведем еще одну аналогию между сценариями. Она включает в себя понимание моделей того, как Боб и Сьюзи соображают. Когда Боб думает об отпуске, он скорее всего представляет себе пальмы, развлечения для детей, долгие прогулки по пляжу – в общем, курортные дела. Когда Сьюзи думает об отпуске, она думает об обновлении файлов, заполнении бланков и что еще нужно связаться с линейными руководителями.
Когда они разговаривают друг с другом, они используют одно слово «отпуск», но оно означает две совершенно разные вещи. В первом случае, оно относится к периоду времени вдали от офиса; в последнем случае оно относится к бизнес-процессу, который оформляет использование этого времени. Используя технологические термины, у каждого из них есть доменная модель отпуска. Все чаще мы наблюдаем попытки организаций ввести «информационную архитектуру предприятия», «универсальный словарь данных» и некоторые другие необычные термины, чтобы попытаться заставить всех использовать одну доменную модель. В нашем примере объединять доменную модель отпуска Сьюзи и Боба было бы не только трудно, но и вредоносно.
Так как отдел кадров растет, мы можем захотеть реорганизовать бизнес-процесс, отвечающий за сервис бронирования отпусков (например, путем расширения роли Сьюзи, таким образом, чтобы эту роль выполняли несколько человек). Этого было бы сложно достичь, если бы мы связали бизнес-понимание отпуска с пониманием отпуска Бобом или любыми другими людьми. Вместо этого мы вводим идею бизнес-концепции. Это, по существу, более высокий уровень, единый язык, который связывает вместе все узкоспециализированные доменные модели каждого сервиса. Так что «отпуск» становится бизнес-концепцией, которая интерпретируется Бобом и Сьюзи по-разному. У каждого есть доменная модель, которая соответствует отпуску, но в каждом случае она создана специально для их целей.
Договор об оказании услуг выражен языком бизнес-концепций корпоративного уровня, таких, как отпуск, корреспонденция или заказ покупателя, которые снова разделяют потребителя и поставщика услуг и позволяют им развиваться самостоятельно, в то время как общаться они могут на одном языке. Ошибка корпоративных информационных архитекторов (или людей с аналогичным названием роли) заключается в том, что они пытаются определить, что значит бизнес-концепт для каждого использующего его человека.
Резюме
Метафора корпорации 1950-х годов позволяет нам определить и обсудить сложные бизнес-взаимодействия в условиях сервис-ориентированной архитектуры, защищая нас от проблем реализации, деталей, инструментов и продуктов. Поддерживая дискуссию, сфокусированную на сценариях настоящего бизнеса, подальше от технологии, бизнес может играть важную роль в определении требований к СОА.
Несомненно, это только первый шаг в реализации полностью рабочей СОА для решаемой задачи, и немедленно следуя этому упражнению, вы с головой погрузитесь в детали, которые помогут реализовать решение конкретной проблемы. Это, впрочем, означает, что в любой момент технические решения могут обратным ходом связаны с бизнес-ценностями в терминах моделируемого нами бизнес процесса.
Спасибо Arjen Poutsma, Mats Helander и моим коллегам в ThoughtWorks за помощь со статьей.
Chief technology officer "Один Сервис.ВЦ" - Денис Олейник
Эта статья впервые была опубликована в 2007 году в майском номере журнала Better Software.
За последние несколько лет сервис-ориентированная архитектура (СОА) стала основным подходом к проектированию и разработке корпоративного программного обеспечения. Как и большинством новых технологий, внедрением СОА заведуют поставщики программного обеспечения и делают они это, используя свои специфические инструменты и преследуя свои же корыстные интересы. А в интересах производителей что? – Естественно, подчеркнуть сложность СОА и затем обеспечить своевременное и выгодное решение. Это приводит к тому, что многие системные архитекторы фокусируют свое внимание именно на технологической составляющей СОА, когда в действительности самый важный критерий для сервис-ориентированного архитектора — прежде чем с усердием браться за технологии — хорошее понимание бизнеса.
В этой статье представлен простой, независимый от технологий подход для проектирования и развития СОА. Вы не увидите такие акронимы, как WSDL, SOAP или REST, и я обещаю не использовать технические термины вроде «оркестрация», «реализация» и «управление». Благодаря этому, вы сможете проектировать и внедрять сервис-ориентированные архитектуры, которые действительно будут служить вашему бизнесу.
Опишем сценарий с точки зрения бизнеса
Представьте, что вы хотите внедрить службу бронирования отпусков и сделать ее частью корпоративной системы. Первым делом убираем все упоминания о компьютерах или современных технологиях. Это позволит вам сосредоточиться на бизнес-целях, не отвлекаясь на технологические аспекты. Другими словами, это позволяет отделить «что» от «как».
Простой способ сделать так – это описать бизнес взаимодействия таким образом, как будто они происходят в компании в 1950-х. Назовем нашу компанию Big Corporation, Inc. Это классическая корпорация 1950-х годов – иерархическая, с огромным количеством отделов, содержащая бесчисленное множество людей, которые являются винтиками в Большой машине. Они все знают свои места, их должностные функции ясно определены, и нет запутанных организационных границ.
Помните, позиции «менеджер проекта» пока не существует. Вы можете воспользоваться только телефоном и внутренней почтой. Вот как может пойти сценарий.
Боб оформляет отпуск
Боб работает в Big Corporation, Inc. Боб хочет взять отпуск. Он усердно работал и думает, что этого заслуживает. Поэтому Боб идет к полке канцелярских принадлежностей, берет бланк заявления на ежегодный отпуск и старательно его заполняет. Это довольно обычное заявление: он заполняет своё имя, отдел, даты отпуска и затем подписывает документ. В дополнение он указывает свой добавочный номер телефона в нижней части заявления.
Боб относит заявление своему линейному руководителю, который его подписывает, и потом Боб отправляет документ по внутренней почте. О, внутренняя почта! Она откровенно ненадежна, но он в любом случае отправляет форму и воссылает тихую молитву. Он делает заметку в своем настольном календаре, чтобы не забыть проверить результаты через неделю.
Затем он возвращается к работе на его важной административной должности.
Спустя неделю календарь Боба напоминает ему, что Боб не получил ответа от отдела кадров, поэтому он решает позвонить им.
- «Боб» как вы сказали? Нет, у нас нет вашей заявки на отпуск. Да, конечно, я бы знала, я обрабатываю все заявления о предоставлении отпуска.
Извините!
Непоколебимо Боб заполняет другое заявление, оставляет его во внутренней почте и возвращается к работе. Через пару дней конверт падает в почтовый ящик Боба. Его отпуск был утвержден – отличная новость! Теперь нужно забронировать отель и рассказать жене и детям.
Повторим сценарий в сервис-ориентированных терминах
Теперь, давайте-ка, воспроизведем этот сценарий и определим, где используются услуги, и на что похожи аспекты взаимодействия. С точки зрения СОА, отдел кадров – это поставщик услуг. Одной из услуг является планирование ежегодных отпусков. Боб является клиентом или заказчиком (потребителем) услуги. Бланк заявления на отпуск описывает заказ на предоставление услуг. Заполненный бланк в таком случае – асинхронное сообщение: Боб не приостанавливает свою деятельность, чтобы дождаться ответа, вместо этого он продолжает свою обычную работу.
Внутренняя почта – это передача сообщений, в этом случае – ненадежная. К счастью, у Боба есть протокол обработки ошибок, а именно тайм аут. Через неделю календарь оповещает о том, что следует позвонить в отдел кадров. Телефонный звонок – это синхронное взаимодействие — он говорит по телефону в режиме реального времени. Затем он реализует стратегию с исправлением ошибок, которая заключается в том, чтобы еще раз отправить сообщение. Обратите внимание, что вся последовательность – напоминание в календаре, ожидание, телефонный звонок и повторное отправление сообщения – была необходима только потому, что передача сообщения была ненадежной. Мы вернемся к этой мысли позже.
Второе асинхронное сообщение отправлено, и в этот раз Боб получает ответ на свою входящую почту. Это асинхронный ответ. В итоге Боб соотносит ответ с первоначальным запросом и обмен завершен.
Используем бизнес-ориентированный сценарий для изучения сервис-ориентированных допущений
Технические термины в предыдущем разделе могут быть вам непривычны, если вы не опытный разработчик СОА. Тем не менее они имеют прямую, один к одному взаимосвязь с терминами в бизнес-версии, преимущество которой – реальность и осязаемость. Исходя из предыдущего примера, ниже представлены некоторые обсуждения и вопросы, помогающие разъяснить допущения, которые могут появиться у ваших архитекторов в процессе проектирования сервиса:
Надежность передачи сообщений
Из описания мы узнали, что система доставки сообщений внутренней почтой ненадежна. Действительно ли это то, что мы не можем контролировать? Можем ли мы сделать процесс более надежным или даже вовсе заменить его? Если нет, то каковы требования, в рамках которых мы работаем, и на какой уровень сервиса можно рассчитывать?
Стратегия обработки ошибок
Сценарий не описывает, как теряется первое сообщение. Было ли оно вообще доставлено или потерялось, попав в отдел кадров? В последнем случае может быть намного больше потенциально ошибочных ситуаций, которые стоит учесть. Например, если кто-то обновляет записи о работе Боба, чтобы уменьшить количество оставшихся дней отпуска, а заявление теряется перед тем, как отпуск был утвержден, то его данные находятся в рассогласованном состоянии. Записи не будут отражать реальность: отдел кадров “потерял” несколько дней отпуска Боба. Иными словами, сервис бронирования отпусков должен быть транзакционным. Это похоже на ситуацию, когда вы снимаете деньги с одного счёта и переводите на другой – либо оба действия удаются, либо оба действия отменяются.
Ключ к разгадке в телефонном разговоре. Видимо, только один человек занимается заявлениями о предоставлении отпуска, из-за этого вероятность потери запроса на полпути существенно меньше, чем если бы этим занимались несколько человек. Такова особенность реализации сервиса: чем он сложнее, тем больше мы должны анализировать границы транзакций и последствия сбоев на разных этапах процесса.
Те ошибки, которые мы на данный момент обсудили зависят от того, как осуществляется запрос (то есть, как он реализован). Но есть несколько коммерческих причин, почему подача заявления на отпуск может не пройти. На языке СОА это семантика или бизнес-правила. Что если Боб уже израсходовал норму отпуска или же его заявление превышает эту норму? А вдруг менеджер, подписавший заявление, не уполномочен подписывать заявления на отпуск? В этих случаях мы вероятно отправим Бобу ответ, объясняя, почему мы не можем обработать его запрос.
Согласовываем ответы
Боб получает ответ через некоторое время после того, как он отправил первоначальный запрос. В это время он был занят другими делами, поэтому он должен суметь соотнести ответ со своим запросом. Конечно, это легко, потому что у него только одно неподтвержденное заявление на отпуск. Если бы он отправлял и получал много запросов такого характера и все асинхронно, ему нужен был бы более надежный подход к сопоставлению ответов по мере их поступления, например, такой как использование номеров для документов, чтобы их сопоставлять.
Таким же образом, если бы было много людей, отправляющих заявления на отпуск в одно время, внутренней почтовой системе могла бы понадобиться помощь, чтобы избежать перегруженности и соответственно доставки ответов на неправильные почтовые ящики или их полной потери. Очень полезно представлять себе ожидаемые шаблоны использования сервиса в терминах «пиков и долин» и максимального количества одновременных запросов. Это может варьироваться в зависимости от времени суток, недели, месяца или года. Может увеличиваться или уменьшаться в конце недели или в конце месяца, или может быть сезонным.
В нашем примере отпуски цикличны, с максимальными значениями зимой и летом. Мы должны установить, является ли сервис международным, в таком случае зима и лето могут быть в разное время для разных пользователей. Это может фигурировать в наших дискуссиях о соотношении асинхронных ответов.
Доступность сервиса
Говоря об идее пиковых нагрузок, необходимо затронуть более широкий круг вопросов касающихся доступности сервиса. Должны ли мы предоставить соглашение об уровне услуг (SLA), в котором прописывается, скорость отклика сервиса при различных обстоятельствах? Если нет, можем ли мы обеспечить заказчикам то, чего они могут ожидать от нашего сервиса? Мы можем это гарантировать? Должны ли мы отдавать предпочтение одним сервисам и если да, то каким образом? Например, если отдел кадров также бронирует билеты для деловых поездок, они могут оформить все деловые поездки перед тем, как бронировать билеты для отпусков. Кроме того, сервис должен гарантированно обеспечивать определенный процент своей мощности (своих ресурсов) для каждого типа запроса.
Безопасность и соответствие требованиям
В этом примере безопасность, вероятно, не проблема. Вряд ли кто-то захочет подделать заявление на отпуск от имени Боба. Однако, что мы знаем о самом Бобе? Возможно, его начальник отклонил заявление, и Боб подделал подпись своего руководителя. Это было бы вероятно, если бы отпускные Боба отслеживал его начальник, а не отдел кадров. В этом случае мы вероятно рассмотрим более тщательную проверку запроса, такую как (синхронный) звонок менеджеру Боба, чтобы убедиться, что она действительно подписала заявление. В дополнение к нашим собственным бизнес правилам, мы должны учитывать внешние ограничения правового характера, которые могут налагаться на нас. Это особенно реально для систем, сохраняющих конфиденциальной финансовую и личную информацию.
Некоторые наблюдения
Как видите, нам удалось задать несколько полезных вопросов, которые помогают понять природу сервиса без углубления в технологические дискуссии или отвлечения на детали реализации. Ведение обсуждения на уровне бизнеса позволяет понять истинную деловую ценность и цель сервиса, и дает нам возможность исследовать любые сложные аспекты бизнеса независимо от технических вопросов. Фактически у настоящей сервис-ориентированной архитектуры должны быть сервисы с прямым аналогом в бизнесе; в противном случае они едва ли смогут моделировать бизнес-процесс.
Такие абстрактные технические понятия, как «служба обработки и передачи данных» или «служба репликации» не имеют никакого смысла в бизнесе. (Существуют доступные наборы модулей и библиотек, которые технически обеспечивают соответствующую функциональность, но они не могут внедряться и использоваться как сервис). Полезным эвристическим алгоритмом будет отождествить поставщика сервиса с отделом или командой внутри организации. Например, мы можем смоделировать отдел кадров как единого поставщика сервиса, предлагающего ряд услуг, или мы могли бы разделить его на более маленьких поставщиков сервиса, если услуги естественным образом делятся на категории.
Развитие сервиса в бизнес-терминах
До сих пор мы говорили только о начальном проекте сервис-ориентированной архитектуры, но мы также хотим иметь возможность менять и адаптировать сервисы с течением времени. Чтобы понять встречающиеся здесь вопросы, полезно взглянуть на то, в связи с чем сервис может развиваться. Опять же, начнем с бизнес-ориентированного сценария и затем сопоставим его с терминологией СОА.
Сьюзи спасает день
Сьюзи работает в отделе кадров Big Corporation, Inc., обрабатывая заявления на предоставление отпуска. Однажды она получает заявление на отпуск от Боба, тогда она просматривает его оставшийся отпуск и обнаруживает, что количества дней недостаточно. Она замечает, что отпуск неминуем – он хочет уйти в отпуск через два дня. К тому моменту, как ответ дойдет до него, и он отправит заявление повторно, будет уже слишком поздно. Она замечает, что он черкнул свой добавочный номер телефона в нижней части заявления, ну и звонит ему.
- Привет, Боб, это Сьюзи из отдела персонала. Боюсь, я вынуждена отклонить ваше заявление на трехнедельный отпуск; у вас осталось недостаточное количество дней.
- Три недели? Я имел в виду только две недели! Какие даты указаны на этом заявлении?
- с 1-го по 21-ое
- Бог ты мой, простите, там должно быть написано: с1-го по 14-ое. Должно быть, я отвлекся. Я читаю эту статью про летающие автомобили, которые будут у всех в 2000 году.
- Ничего. Я подпишу заявление. Приятного отдыха.
- Спасибо, Сьюзи. Ты действительно спасла мой день!
Со временем она замечает, что все больше и больше людей указывают свои номера телефонов на заявлениях, таким образом она может решать проблемы быстрее. Она решает добавить новое, дополнительное поле на бланке для добавочного номера и называет его «заявление о предоставлении отпуска версия 2».
Некоторое время спустя она получает памятку о новом распорядительном документе. Видимо, все заявления на отпуск теперь должны содержать имя человека, который будет ответственным за рабочие вопросы в отсутствие отдыхающего. Такие правила без исключений вступают в силу немедленно. Поэтому она создает новую форму, версию 3, и рассылает всей компании памятку, в которой говорится, что, к сожалению, версии 1 и 2 больше не будут приниматься. Она также набрасывает черновик со стандартным ответом, чтобы отправить любому, кто будет использовать старые бланки.
Повторим сценарий в сервис-ориентированных терминах
Прокручивая этот сценарий, мы видим, что сервис изменяется дважды по разным причинам. В первую очередь, мы понимаем, что можем предоставить более эффективный сервис, если у запроса есть некая дополнительная информация. Мы публикуем вторую версию договора об оказании услуг – бланк с добавленным дополнительным полем. Обратите внимание, что мы не аннулируем все бланки версии 1. Мы все еще можем обслуживать клиентов, использующих старую версию договора об оказании услуг. Единственное, мы вежливо ухудшили сервис, потому что не сможем позвонить инициатору запроса, если возникнут какие-то проблемы. Это позволяет клиентам выбирать, когда перейти на новый договор об оказании услуг и получить новые возможности, а также обеспечивает слабую связь между модернизацией сервиса и клиентом.
Это наиболее распространенная форма эволюции сервиса. Либо через обратную связь от ваших пользователей, либо исходя из идей вашей собственной организации или конкурентов, вы захотите добавить новые функции или улучшения вашему сервису.
Будьте ответственным, когда вносите изменение, которое заденет работу существующих потребителей сервиса
Вторая ситуация несколько иная. Новый, обязательный элемент данных необходим, без него сервис не может быть реализован. Это означает, что ни один потребитель не может воспользоваться сервисом с существующим договором об оказании услуг и каждый должен «обновить» бланк документа. В связи с тем, что мы ответственные разработчики услуг, мы предоставляем сообщение об ошибке, а не молча сбрасываем все устаревшие запросы.
Эта стратегия, предоставляющая немедленную обратную связь с потребителем известна как «быстрый облом». Это полезно, так как клиент теперь ясно понимает, почему запрос был отклонен (и будет продолжать отклоняться до тех пор, пока он не обновит формат запроса). В ином случае он мог предположить, что неполадка была из-за каких-то инфраструктурных вопросов или временного перерыва в обслуживании и просто пытался бы еще раз отправить запрос.
Как бы аккуратно вы ни развивали сервис, всегда может произойти внезапное существенное изменение, особенно в сильно зарегулированных средах, где регуляторы находятся вне вашего контроля.
Избегайте универсальных доменных моделей
Прежде чем мы покинем Big Corporation, Inc., проведем еще одну аналогию между сценариями. Она включает в себя понимание моделей того, как Боб и Сьюзи соображают. Когда Боб думает об отпуске, он скорее всего представляет себе пальмы, развлечения для детей, долгие прогулки по пляжу – в общем, курортные дела. Когда Сьюзи думает об отпуске, она думает об обновлении файлов, заполнении бланков и что еще нужно связаться с линейными руководителями.
Когда они разговаривают друг с другом, они используют одно слово «отпуск», но оно означает две совершенно разные вещи. В первом случае, оно относится к периоду времени вдали от офиса; в последнем случае оно относится к бизнес-процессу, который оформляет использование этого времени. Используя технологические термины, у каждого из них есть доменная модель отпуска. Все чаще мы наблюдаем попытки организаций ввести «информационную архитектуру предприятия», «универсальный словарь данных» и некоторые другие необычные термины, чтобы попытаться заставить всех использовать одну доменную модель. В нашем примере объединять доменную модель отпуска Сьюзи и Боба было бы не только трудно, но и вредоносно.
Так как отдел кадров растет, мы можем захотеть реорганизовать бизнес-процесс, отвечающий за сервис бронирования отпусков (например, путем расширения роли Сьюзи, таким образом, чтобы эту роль выполняли несколько человек). Этого было бы сложно достичь, если бы мы связали бизнес-понимание отпуска с пониманием отпуска Бобом или любыми другими людьми. Вместо этого мы вводим идею бизнес-концепции. Это, по существу, более высокий уровень, единый язык, который связывает вместе все узкоспециализированные доменные модели каждого сервиса. Так что «отпуск» становится бизнес-концепцией, которая интерпретируется Бобом и Сьюзи по-разному. У каждого есть доменная модель, которая соответствует отпуску, но в каждом случае она создана специально для их целей.
Договор об оказании услуг выражен языком бизнес-концепций корпоративного уровня, таких, как отпуск, корреспонденция или заказ покупателя, которые снова разделяют потребителя и поставщика услуг и позволяют им развиваться самостоятельно, в то время как общаться они могут на одном языке. Ошибка корпоративных информационных архитекторов (или людей с аналогичным названием роли) заключается в том, что они пытаются определить, что значит бизнес-концепт для каждого использующего его человека.
Резюме
Метафора корпорации 1950-х годов позволяет нам определить и обсудить сложные бизнес-взаимодействия в условиях сервис-ориентированной архитектуры, защищая нас от проблем реализации, деталей, инструментов и продуктов. Поддерживая дискуссию, сфокусированную на сценариях настоящего бизнеса, подальше от технологии, бизнес может играть важную роль в определении требований к СОА.
Несомненно, это только первый шаг в реализации полностью рабочей СОА для решаемой задачи, и немедленно следуя этому упражнению, вы с головой погрузитесь в детали, которые помогут реализовать решение конкретной проблемы. Это, впрочем, означает, что в любой момент технические решения могут обратным ходом связаны с бизнес-ценностями в терминах моделируемого нами бизнес процесса.
Спасибо Arjen Poutsma, Mats Helander и моим коллегам в ThoughtWorks за помощь со статьей.
Chief technology officer "Один Сервис.ВЦ" - Денис Олейник