Интеграция на уровне вызовов или мета-данных?

Архитектура ИС на основе Web-сервисов позиционируется как поддерживающая динамическое связывание с помощью мета-языков WSDL, UDDI и SSDL, а так же принципы CRUD/REST, однако, это распространенное мнение обманчиво, о чем писал еще в 2002 году Густаво Алонсо в статье "Мифы про веб-сервисы" (Gustavo Alonso - Myths around Web Services). К сожалению, сейчас все материалы, на английском языке по этому вопросу в интернете ведут на битые ссылки, а кое-какие даже на страницу 404 на сайте Microsoft Research (о причинах остается догадываться... а для того, чтобы привести тут ссылку, мне пришлось достать копию статьи из своего бекапа и разместить у себя на сервере). Не буду повторять тут пять основных критических тезисов Алонсо, но постараюсь рассмотреть саму теоретическую возможность динамического связывания в разных архитектурах, безотносительно конкретных реализаций, проприетарных технологий и торговыхмарок.

Рассмотрим композитную информационную систему, состоящую из нескольких слоев или модулей. Каждый модуль имеет интерфейс, через который к нему обращаются другие, а так же тело, содержащее логику работы модуля (состоящее из кода и данных). Все входящие вызовы к модулю изут через интерфейс, а все исходящие - рассеяны по логике. Таким образом, если меняется логика, то это может происходить "прозрачно" для вышестоящих слоев, которые имею дело все с тем же интерфейсом (или с интерфейсом, поддерживающим обратную совместимость). Но вот если функциональность модуля изменилась существенно, т.е. не только старые функции были модифицированы, но и появились принципиально новые, вышестоящие слои просто не будут "знать" этой логики без соответствующей доработки (не будут знать имен новых функций, набора параметров и семантики или смысловой нагрузки вызовов). Эту задачу и призваны решать WSDL и UDDI, они ее и решают, но на две трети: применяя эти средства описания интерфейсов, мы получаем каталог функций и их параметров, но опять остается "потерянна семантика". Задача связывания веб-сервисов опять остается на человеке, который принимает решение на основе договоренностей между разработчиками модулей, т.е. задача выходит с технологического уровня на организационно-технологический и другого решения пока нет.

CRUD/REST"интерфейсом сверху" пытается решить ту же проблему, ограничивая модуль не только , но и "нижним интерфейсом", более того, оба этих интерфейса становятся идентичными между собой и одинаковыми для всех систем. Ограниченный набор команд не решает проблему связывания, он просто смещает ее с уровня вызовов к уровню мета-данных. Действительно, связывание на уровне вызовов предельно простое, например, в HTTP протоколе набор команд сводится к GET, POST, PUT, PATCH, DELETE, LINK, UNLINK, HEAD, OPTIONS, TRACE, CONNECT. Параметры этих команд так же формализованы и фиксированы. Но принципиальная проблема в том, что логика одного модуля ничего не "знает" о логике другого, кроме того алгоритма, который "зашил" программист. Как же может произойти динамическое связывание, если новая функциональность остается невостребованной, а старую, тем временем, приходится поддерживать. Сформулируем задачу яснее: как две системы, имеющие разные языки, разную логику и разную лексику, т.е. просто - разную информационную модель могут договориться? Ответ очевиден: без установления правил отображения информационных моделей двух систем друг в друга, динамическое связывание просто не имеет смысла. А когда таких информационных систем не две, а больше? А нам интересен именно общий случай автоматизации межсистемной интеграции. Гораздо проще решить проблему введя во все системы одну информационную модель, тогда мы получаем выигрыш в количестве правил отображения: вместо (N²-N)/2 нам нужно будет всего N двухсторонних конвертеров. Но все интегрируемые системы должны иметь разные модели, т.к. решают разные задачи и даже одни и те же объекты и явления описывают с разных сторон, классифицируют и формализуют иначе.

Есть еще одно решение: добавлять интерпретируемые мета-данные в межсистемные вызовы вместе с передаваемыми объектами. Т.е. объекты должны содержать как пассивное формализованное описание, так и активную интерпретируемую логику, а модули информационной системы можно максимально абстрагировать от логики предметной области, повысив уровень абстракции на два-три порядка. Например, решая задачу отслеживания перемещения контейнеров с макаронами от производителя через дистрибьюторов к покупателям, мы можем без существенного усложнения модели перейти к задаче отслеживания перемещения произвольных товаров между произвольными точками, введя классификацию точек (например: производство, склад, магазин) и имея возможность расширять эту классификацию. Бизнес-логику процесса можно отобразить в интерпретируемую модель, частично в виде атрибутов, свойств и связей, а частично в виде интерпретируемых алгоритмов.

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