Являются ли самоописанные / автоописательные сервисы слабо или тесно связаны в архитектуре SOA?

Question

Я считаю самоописываемый / автоописательный сервис хорошей вещью в архитектуре SOA, поскольку (почти) все, что вы знаете для вызова сервиса, присутствует в контракте на обслуживание (например, WSDL).

Примером службы, не описывающей себя само по себе, является язык запросов Facebook (FQL http://wiki.developers.facebook.com/index.php/FQL), или любой веб-сервис, обменивающий поток XML одним параметром String для последующего анализа XML и выполнения обработок.

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

Этот вопрос относится к Как реализовать слабую связь с архитектурой SOA

Итак, самоописанные / автоописательные сервисы слабо или тесно связаны в архитектуре SOA? Какое влияние оказывает ESB?

Любой указатель будет оценен.

Answer 1

Дело в том, что слабосвязанные сервисы SOA будут стремиться взаимодействовать друг с другом, используя семантику публикации / подписки, не поддерживаемую WSDL (которая поддерживает только запрос / ответ).

Когда вы вводите ESB, такой как NServiceBus, он фокусируется на сообщениях и владении, а не на вызовах методов, которые инструменты генерируют из WSDL. Эти сообщения затем могут быть представлены либо как классы в коде, либо как XSD для совместимости.

Транспортировка XML-сообщений из одной конечной точки в другую, когда выполняется стандартными веб-службами, выглядит довольно глупо, поскольку контракт не указан в WSDL, и это одно из мест, где вступают ESB.

Надеюсь, это поможет.