воскресенье, Январь 29, 2006
Проектирование сервисов и объектов
Практика объектно-ориентированного программирования и проектирования быстро распространилось в начале 90-х благодаря простоте, с которой суть ООП можно было донести и воспринять. Физические объекты повсюду окружают нас и тем самым обеспечивают обилие метафор. Объект -- это вещь (например, "стол" или "телефон") , у которой есть характеристики и функции. Объекты инкапсулируют данные и алгоритмы, реализующие их функциональность. Вследствие простоты восприятия и наглядности преимуществ ООП стало общепринятой практикой.
Сервис объектом не является (концептуально, о реализации см. ниже), и привычные объектные метафоры к сервисам неприменимы. Сервисы можно воспринимать как, например, совокупность функций, предоставляемых организацией своим контрагентам. Данные инкапсулируются в сообщениях, являющих собой запросы к сервису на исполнение той или иной полезной с точки зрения потребителя сервиса функции. Получив сообщение, организация (например, "магазин", "склад" или "цех") предпринимает совокупность соответствующих запросу действий.
Как генерация, так и обработка сообщения может происходить в самых разных средах -- и процедурных, и объектных, в том числе, как это происходит все чаще, непосредственно на Web-странице (благодаря AJAX). Однако наиболее распространенные модели программирования сервисов основаны на ООП, что намеренно соответствует превалирующим навыкам и привычкам. В стремлении сделать сервис-ориентированное программирование доступным, сервисные контейнеры подают обмен сообщениями под видом старых добрых вызовов функций, чем способствуют распространению некорректной практики моделирования сервисов и SOA.
Более продуктивными представляются абстрации, основанные непосредственно на обработке сообщений (например, очереди сообщений в стиле pub/sub) сервисом тем или иным образом по мере их получения. Проектируя систему в рамках такой понятийной базы, ее архитектура естественным образом выстроится в соответствии с ограничениями и преимуществами сервисной ориентации, а не будет имитировать объектно-ориентированные метафоры. Если же окажется, что такая модель программирования не подходит или неоптимальна для выбранного сервиса, то, вероятно, что была допущена ошибка при проектировании системы -- либо сервисы выделены неправильно, либо сервисная ориентация неоптимальна на этом уровне IT-архитектуры.
Сервис объектом не является (концептуально, о реализации см. ниже), и привычные объектные метафоры к сервисам неприменимы. Сервисы можно воспринимать как, например, совокупность функций, предоставляемых организацией своим контрагентам. Данные инкапсулируются в сообщениях, являющих собой запросы к сервису на исполнение той или иной полезной с точки зрения потребителя сервиса функции. Получив сообщение, организация (например, "магазин", "склад" или "цех") предпринимает совокупность соответствующих запросу действий.
Как генерация, так и обработка сообщения может происходить в самых разных средах -- и процедурных, и объектных, в том числе, как это происходит все чаще, непосредственно на Web-странице (благодаря AJAX). Однако наиболее распространенные модели программирования сервисов основаны на ООП, что намеренно соответствует превалирующим навыкам и привычкам. В стремлении сделать сервис-ориентированное программирование доступным, сервисные контейнеры подают обмен сообщениями под видом старых добрых вызовов функций, чем способствуют распространению некорректной практики моделирования сервисов и SOA.
Более продуктивными представляются абстрации, основанные непосредственно на обработке сообщений (например, очереди сообщений в стиле pub/sub) сервисом тем или иным образом по мере их получения. Проектируя систему в рамках такой понятийной базы, ее архитектура естественным образом выстроится в соответствии с ограничениями и преимуществами сервисной ориентации, а не будет имитировать объектно-ориентированные метафоры. Если же окажется, что такая модель программирования не подходит или неоптимальна для выбранного сервиса, то, вероятно, что была допущена ошибка при проектировании системы -- либо сервисы выделены неправильно, либо сервисная ориентация неоптимальна на этом уровне IT-архитектуры.
LinkedIn
vCard
Лента
