Во-первых, о GT.CM и M/Wire я только прочитал в соответствующих источниках, еще продолжу чтение по этим продуктам.
Во-вторых, я разрабатываю сервер (демон), который будет клиентом по отношению к GT.M (и любой другой базе данных), и сервером для фронтэнда.
Вариант 1. Демон на том же железе, что и база данных. Здесь, я думаю, можно использовать свои C++ классы, посредством Call-Ins. Можно также разработать TCP Client на основе GT.CM или M/Wire продукта.
Вариант 2. Демон и база данных на разных железах. Здесть только TCP Client.

Из прочитанного я только один вывод сделал: M/Wire лучше GT.CM, лучше протокол, поддержка разных языков программирования, правда C++ код прийдется писать самому, наверное.

А еще такой вопрос. В этом я вообще ничего не понимаю еще.
Предполагается, что GT.M распределенная база данных (BC репликация), никак не могу понять, как продумать архитектуру решения, в котором участвуют:
1. Несколько экземпляров базы данных (GT.M Instances, BC Replication)
2. Один или несколько серверов (демонов)
Демон или демоны работают с фронтэндом, фронтэнд ничего не знает о базах данных.
Варианты архитектуры решения:
1. Один демон на всех. Тогда, по идее он должен быть и TCP Client для баз данных, но как такое может работать не пойму.
2. Каждому экземпляру базы данных по демону. Здесь возможно использование своих C++ классов (Call-Ins). Но здесь не пойму как организовать взаимодействие между фронтэндом и демонами.
Может какой то другой вариант есть?
Я понимаю, что есть еще вариант написания M кода и работы с ним, но опять же фронтэнд ничего не должен знать о базах данных (какие они, как распределены и прочее), он знает только доступный ему API для системы.

Спасибо :) Накатал сумбурно и предваряя собственное исследование в этой области...

DirksDR,

GT.CM (насколько я понял) обеспечивает распределенность базы данных, т.е. серверный процесс GT.M одного узла может обратиться к базе другого узла.



Спасибо :) А то пока разберешься, что к чему... да еще и за ограниченное время на изучение.

получается, что он должен выполнять функции (часть функций) сервера приложений, т.е. поддерживать пул соединений с сервером (серверами) БД, пул подключений для клиентов, и т.д.



Да, так и будет.
Ступор в понимании того, как это будет работать с несколькими серверами базы данных (как я понял это не тоже самое, что распределенная база данных) :) Возможно GT.M сама беспокоиться о надежности и доступности экземпляров базы данных, а соединения делать с одним из них...
Читаю-читаю я Таненбаума :)

Модератор:
Постарайтесь не использовать теги которые корежат внешний вид форума, когда форум растягивается в ширину шире экрана стоновится читать не удобно