Какие различия допустимы между IDL сервера CORBA и клиента?
До сих пор я знаю, что спецификация CORBA как таковая не допускает различий между IDL, который использует серверная программа, и IDL, который использует клиентская программа.
Однако на практике некоторые различия должны работать (довольно) универсально, потому что основным механизмом коммуникации, скорее всего, является GIOP (по крайней мере, IIOP), а некоторые различия не могут быть обнаружены с помощью IIOP.
Я хотел бы установить, какие различия допускаются между IDL сервера и клиента универсально между произвольными ORB, если используется GIOP/IIOP.
Например: пока я предполагаю, что это работает для:
- Добавьте любой тип / интерфейс к IDL сервера, если типы, о которых знает IDL клиента, не затрагиваются или любые неизвестные новые типы отправляются обратно клиенту.
- Добавьте метод к существующему интерфейсу на стороне сервера - клиент должен иметь возможность продолжать вызывать объекты с этим интерфейсом, даже если его IDL не перечисляет указанный метод. (Здесь, кажется, ответили да.)
- Добавьте член в конец перечисления, если клиент никогда не увидит это новое значение.
- Добавьте члена в объединение, если клиент никогда не увидит этот тип объединения с установленным новым значением дискриминатора.
Моя цель состоит в том, чтобы получить что-то вроде короткого списка вещей, которые можно сделать в существующей IDL, чтобы расширить "сервер" новыми вещами без необходимости перекомпиляции выходящих клиентов с измененной IDL.
1 ответ
Да, набор методов сервера и клиента не обязательно должен совпадать, так как доступ к методам осуществляется по имени (поле операции в сообщении GIOP) и независимо. Другими словами, вызов GIOP включает в себя имя метода в виде строки, затем параметры кодируются так, как ожидается этим параметром. Смотрите пример галстука CORBA и заглушки CORBA.
Да, если вы создаете и экспортируете новый интерфейс, это просто новый интерфейс. Он может быть привязан к любой службе имен независимо от других, и клиенты, не знающие об этом новом интерфейсе, просто не смогут его использовать. Он сможет использовать известные типы, привязанные к одной и той же службе имен.
Да, GIOP записывает перечисления в виде беззнаковых длин, первое значение всегда кодируется как нули, последовательные идентификаторы принимают возрастающие числовые значения в порядке объявления слева направо. Следовательно, совершенно безопасно добавлять новые идентификаторы enum, но не удалять и не менять порядок.
Читать спецификацию GIOP, очень помогает. Также очень хорошо посмотреть на код, сгенерированный компилятором IDL, и как он меняется, когда что-то меняется в IDL.
Конечно, не рекомендуется использовать несовпадающие IDL только из-за отсутствия осторожности, поскольку также легко вносить несовместимые изменения. Это имеет смысл, вероятно, только в тех случаях, если вы не можете больше обращаться к клиенту и обновлять его, поскольку он был предоставлен пользователю.