Какие различия допустимы между IDL сервера CORBA и клиента?

мне известно, что спецификация CORBA как таковая не допускает различий между IDL, которые использует серверная программа и IDL, который использует клиентская программа.

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

Что я хотел бы установить, так это какие различия разрешены между серверным и клиентским IDL универсально между произвольными ORB, пока используется GIOP/IIOP.

Например: Пока я предполагаю, что это работает для:

  • Добавляйте любой тип/интерфейс в серверный IDL при условии, что типы, о которых знает клиентский IDL, не затрагиваются или какие-либо неизвестные новые типы отправляются обратно клиенту.
  • Добавьте метод к существующему интерфейсу на стороне сервера — клиент должен иметь возможность продолжать вызывать объекты с этим интерфейсом, даже если его IDL не перечисляет указанный метод. (Кажется, здесь отвечено да.)
  • Добавьте элемент в конец перечисления, пока клиент никогда не увидит это новое значение.
  • Добавить участника в союз, если клиент никогда не увидит этот тип Union с дискриминатором, установленным на новое значение.

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


person Martin Ba    schedule 25.08.2012    source источник
comment
Я не думаю, что вам стоит даже думать об этом. Это закончится слезами.   -  person user207421    schedule 15.09.2012
comment
@ejp - вы когда-нибудь работали с corba? вы эксперт по IIOP?   -  person Martin Ba    schedule 16.09.2012
comment
Я достаточно хорошо разбираюсь в вычислениях, чтобы понимать, что не следует заигрывать с недокументированным и неуказанным поведением.   -  person user207421    schedule 23.09.2012
comment
@EJP - А, хорошо, спасибо за эту информацию. Я боялся, что ваш комментарий был основан на более конкретной информации. В этом случае, хотя я счастлив игнорировать это. :-)   -  person Martin Ba    schedule 23.09.2012
comment
Это основано на конкретной информации о том, что Corba и IDL не предназначены для такого рода вещей.   -  person user207421    schedule 25.09.2012
comment
@EJP: специально для этого не предназначен: да. Но создан для связи через GIOP, а GIOP (IIOP) делает некоторые различия необнаружимыми по спецификации.   -  person Martin Ba    schedule 25.09.2012
comment
GIOP — это просто протокол связи. Спецификации можно читать, понимая, что можно, а что нельзя. Если некоторая информация, такая как список всех методов, не включена в протокол GIOP, она не включается.   -  person Audrius Meskauskas    schedule 13.01.2013


Ответы (1)


  • Да, набор методов сервера и клиента не обязательно должен полностью совпадать, поскольку доступ к методам осуществляется по имени (поле операции в сообщении GIOP) и независимо друг от друга. Другими словами, вызов GIOP включает в себя имя метода в виде строки, далее параметры кодируются так, как они ожидаются этим параметром. См. пример галстук CORBA и Заглушка CORBA.

  • Да, если вы создаете и экспортируете новый интерфейс, это просто новый интерфейс. Его можно привязать к любой службе имен независимо от других, и клиенты, не знающие об этом новом интерфейсе, просто не смогут его использовать. Они смогут использовать известные типы, связанные с той же службой имен.

  • Да, GIOP записывает перечисления как unsigned long, первое значение всегда кодируется нулями, последующие идентификаторы принимают восходящие числовые значения в порядке объявления слева направо. Следовательно, совершенно безопасно добавлять новые идентификаторы перечисления, но не удалять и не изменять порядок.

Прочтите спецификацию GIOP, очень помогает. Также очень полезно посмотреть на код, сгенерированный компилятором IDL, и на то, как он меняется, когда что-то меняется в IDL.

Конечно, не рекомендуется использовать несоответствующие IDL только из-за невнимательности, поскольку также легко внести несовместимые изменения. Это имеет смысл, вероятно, только в тех случаях, когда вы больше не можете получить доступ и обновить клиент, поскольку он был выпущен для пользователя.

person Audrius Meskauskas    schedule 13.01.2013