Войти
В контексте разработка программного обеспечения и архитектура программного обеспечения, гранулярность обслуживания является ключевой проблемой проектирования при применении парадигмы ориентации на службы, например, во время обслуживания -ориентированное моделирование. Гранулярность службы определяет объем бизнес-функций и структуру полезной нагрузки сообщения в операции службы, которая предоставляется в рамках сервис-ориентированной архитектуры (SOA).
Детализация сервиса - это как проблема домена приложения (детализация бизнеса), так и проблема программного интерфейса дизайна (техническая детализация); это свойство услуги контракт, предоставляемое поставщиком услуг. Он относится к семантике и синтаксису содержимого сообщений in (запрос) и out (ответ), которые можно рассматривать как экземпляры двух общих Enterprise Integration Patterns, Command Message и Сообщение документа. По определению, операция крупномасштабного сервиса имеет более широкую сферу применения, чем детализированный сервис, хотя термины являются относительными. Первый тип обычно требует повышенной сложности проектирования, но может уменьшить количество вызовов, необходимых для выполнения задачи.
Из-за ошибок распределенных вычислений поиск подходящего детализация сложна. Нет однозначного простого ответа, но существует ряд критериев (см. Ниже). Основная цель моделирования сервисов и проектирования гранулярности - достичь слабой связи и модульности, которые являются двумя основными принципами SOA, и удовлетворить другие архитектурно значимые требования.
На гранулярность обслуживания влияют многие факторы; Четыре особенно важных фактора, которые следует учитывать при разработке для обеспечения адекватной детализации, - это производительность, размер сообщения, транзакционность и бизнес-функция:
В идеале каждая операция службы сопоставляется с одной бизнес-функцией, хотя если одна операция может предоставить несколько функций без добавления сложности дизайна или увеличения размера сообщений, эта универсальность может снизить затраты на реализацию и использование.
Доступ к веб-службам осуществляется удаленно, и вызовы операций веб-службы создают дополнительные сетевые издержки. Уменьшение количества запросов на обслуживание снижает эти накладные расходы.
Крупнозернистые службы могут передавать больше данных, чем мелкие службы, включая данные, которые не требуются специально для задачи. Это усложняет обработку сообщений в конечной точке и, в свою очередь, может снизить производительность. Для уменьшения размера сообщения может потребоваться добавление более тонкой операции.
Для концептуальной ясности каждая операция службы должна выполнять одну транзакцию на системном уровне и оставлять целостность данных через границы службы бизнес-логике потребителя службы. Это также упрощает исправление ошибок и, как правило, упрощает дизайн.
Существует еще много критериев выбора для поиска подходящей степени детализации; глобального оптимума нет. Шестнадцать таких критериев связи собраны из литературы в.
Поскольку один размер не подходит всем, при проектировании гранулярностей услуг можно использовать множество существующих шаблонов для различных типов распределенных систем., особенно те, которые связаны со службами, а также работы с шаблонами, связанные с дизайном API (например, дизайн API в объектно-ориентированном программировании) и корпоративной интеграцией. Обзор таких языков дан здесь.
