«Услуги инкапсулируют бизнес-функциональность» и «Услуги могут быть объединены в бизнес-процессы» - PullRequest
1 голос
/ 20 января 2012

Недавно я читал 2 книги и натолкнулся на следующие утверждения

Изучение WCF от Мишель Леру:

Сервисы заключают в себе бизнес-функциональность

Сервис-ориентированная архитектура в реальном мире :

Сервисы могут быть собраны (или «составлены») в бизнес-процессы

Слабосвязанные системы приводят к слабосвязанным бизнес-процессам, [...].Службы и связанные с ними интерфейсы должны оставаться стабильными, чтобы их можно было переконфигурировать или повторно объединять для удовлетворения постоянно меняющихся потребностей бизнеса

Чтение SOA в реальном мире, я понял, что предположилсделать мои независимые (изначально бесполезные) сервисы абстрагированными от бизнес-контекста, а затем создавать и организовывать их, а затем делать что-то полезное, создавать бизнес-уровень и удовлетворять бизнес-потребности. заставил меня подумать, что я должен создать свой бизнес-уровень для удовлетворения конкретной потребности, а затем представить его как сервис (конечно, в формате, не зависящем от платформы)

В настоящее время я занимаюсь бизнесомслой, а затем демонстрируя некоторые из его общедоступных методов через четко определенные интерфейсы, но мне понравилась идея сделать более независимые сервисы и создавать их, а затем создавать бизнес-уровень.

Мне бы хотелось услышать мнение опытных разработчиков SOA, Какой из этих подходов был бы идеальным, чтобы получитьпочему SOA и почему ?

Я запутался в этой теме.Примеры и проекты с открытым исходным кодом будут очень полезны.

Ответы [ 2 ]

3 голосов
/ 20 января 2012

Для меня идея сервиса заключается в инкапсуляции функциональности, связанной с бизнесом. Однако это не то же самое, что бизнес-процесс. Часто отдельные части бизнес-функций должны быть объединены в более крупные единицы для представления целых бизнес-процессов. Например, для совершения продажи потребуется принять оплату, отгрузить товар, рассчитать комиссию с продаж. Все это отдельные бизнес-функции, которые можно смоделировать как сервисы, но они должны быть составлены так, чтобы представлять весь бизнес-процесс

Однако бизнес-процессы, как правило, работают относительно долго (больше времени ожидания одного запроса по сети), поэтому каким-то образом необходимо поддерживать состояние бизнес-процесса - это одна из вещей, которую Workflow и Biztalk могут принести в участник.

1 голос
/ 20 января 2012

В книгах Томаса Эрла он классифицирует Сервисы как «Сервисы сущностей», которые представляют собой детализированные, независимые от бизнес-процессов сервисы, которые относятся к одной сущности и часто используются в композициях / оркестровках, и «Сервисы задач», которые являются детализированный, обычно включает более одного объекта, содержит больше бизнес-логики, обладает некоторыми знаниями о бизнес-процессах и не является кандидатом на повторное использование / состав.

Таким образом, бизнес-процесс может быть реализован либо в одной большой службе задач, либо он может быть реализован путем объединения нескольких служб Entity Services в композицию.

«Сервисы заданий» звучат как видение сервиса Мишель Леру, в то время как SOA в реальном мире имеет больше видения «Сервиса сущностей».

С точки зрения Эрла в области SOA, оба типа сервисов могут работать бок о бок. Entity Services являются предпочтительной целью - их можно использовать повторно и проще, что повышает гибкость бизнеса. Но в некоторых случаях это может быть неуместно, и службы задач будут лучшим решением - требования к производительности и инкапсуляция унаследованного кода - два примера.

...