Вот довольно теоретический и абстрактный вопрос: как сервис-ориентированная архитектура (SOA) отличается от подхода на основе компонентов? Является ли концепция SOA продолжением подхода на основе компонентов?
Каковы ваши мысли? Может быть, вы знаете хорошие документы, которые охватывают этот вопрос?
Два понятия довольно ортогональны, не дополняют друг друга и не противоречат друг другу. Если бы вы угрожали вставить ржавую вилку в глаза и заставили меня обобщить, я бы сказал, что разработка на основе компонентов - это метод моделирования и сборки определенного программного обеспечения, где SOA - это способ организации отдельных систем, поэтому они могут разговаривать друг с другом.
Как я уже сказал, грубое обобщение, но все, что я собираюсь дать вам без более конкретного вопроса:)
В в этой статье авторы рассматривают разработку на основе компонентов как поддержку SOA - в конечном итоге вашим SOA нужны услуги которые будут реализованы, и вы создадите компоненты как результаты, обеспечивающие реализацию. Некоторое умение состоит в том, чтобы правильно получить гранулярность и сплоченность компонентов.
Я считаю, что эта перспектива является разумной характеристикой того, как сегодня выполняется SOA. Для меня ключевым является то, что вы сначала фокусируетесь на сервисах, что вам нужно делать в бизнес-смысле, а затем приходите к проектам компонентов. [Здесь статья об определении служб. Отказ от ответственности: я человек IBM, эти статьи написаны коллегами.]
Однако, если вы вернете часы назад, я думаю, вы обнаружите, что компонентное развитие было подходом, который предшествовал SOA, и имел многие из тех же целей, что и SOA. Я считаю излишне циничным мнение о том, что SOA - это просто реклама рекламы, наклеивающая новые ярлыки на старые концепции. Однако между КБР и SOA существует значительное перекрытие. Я просто рассматриваю SOA как лучшую коллективную мудрость, которую мы имеем на сегодняшний день, о том, как сделать интеграцию, без сомнения, по мере того как мы узнаем, что новые методы появятся до тех пор, пока общий комплект не получит новое имя снова.
Мое личное мнение заключается в том, что SOA получила импульс, потому что появился набор технологий, позволяющих разрозненные технические команды внутри организации (например, база IBM и база Microsoft) создавать компоненты, которые могли бы использовать услуги друг друга. Другими словами, уровень зрелости в том, как составлять компоненты, появился, так что новая метка (SOA) была привлекательной.
Можно сказать, что SOA представляет собой высокоуровневую форму разработки на основе компонентов, где компоненты были превращены в многократно используемые функции, называемые сервисами.
Разработка на основе компонентов потребовала репозитория фрагментов кода (иногда полных стеков объектов), как правило, в одном синтаксисе кода. Чтобы быть полезными во всех остальных случаях, эти фрагменты должны были быть перенесены или вызываться через общий интерфейс (например, API окон или COM, COM + и др.) Между VB6 и VС++. Таким образом, функции VС++ могут использоваться и вызываться VB6. Таким образом, для повторного использования компонентов иногда требовалось повторное использование рефакторинга, что было встречным интуитивным. Возникла также проблема раннего и позднего связывания. Компоненты репозитория все еще нуждались в создании и развертывании в качестве функциональной части базы кода для использования. Код должен был быть протестирован модулем перед добавлением в репозиторий, но все же требовал интеграционного тестирования для подтверждения функциональности. Вам также нужно будет построить правильные параметры, чтобы "пересечь интерфейс объекта". Опять же, этот обычно требуемый код оболочки.
Эти репозитории кода могут не включать в себя все, чтобы быть действительно кросс-платформой. Независимость от платформы обычно требуется, когда проблемы сегментируются в разных доменах, особенно в интегрированных системах. Интерфейс включен в встроенное и развернутое программное обеспечение, а не в действующий код.
То, что вам не хватает между двумя, - это Framework. SOA не является CBDv2 и не расширяет его, вам нужно пройти через реализацию сервиса. Рамки также не являются новой концепцией.
И CBD, и SOA в конечном счете способствуют повторному использованию кода. CBD, как правило, является более узким по охвату, чем SOA! SOA требует, чтобы структура была эффективной, CBD этого не делает. CBD связан с языком разработки и целевой платформой.