Семантика атрибутов OMG IDL

Question

Я работаю над проверкой интерфейса, формализованного в IDL OMG, и у меня возникают проблемы с поиском окончательного ответа на семантику получения значения атрибута.В интерфейсе у меня есть запись ...

interface MyInterface {
  readonly attribute SomeType someName;
};

Мне нужно знать, допустимо ли для someObj.someName != someObj.someName значение true (где someObj - это экземпляр объекта, реализующего MyInterface).

Все, что я могу найти в документации OMG в отношении атрибутов, это ...

(5.14) Определение атрибута логически эквивалентно объявлению пары функций доступа;один для извлечения значения атрибута и один для установки значения атрибута.

...

Необязательное ключевое слово readonly указывает, что существует только одна функция доступа - извлечение значенияfunction.

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

Answer 1

Как известно, интерфейс IDL всегда будет представлен удаленным объектом. Атрибут не более, чем синтетический сахар для getAttributeName () и setAttributeName () . Лично я не люблю использовать атрибут , потому что его трудно понять, чем просто метод get / set.

У CORBA также есть тип значений, структура объект за значением - лучше объяснено здесь . Они очень полезны, потому что, в отличие от struct, позволяют нам наследовать от других valuetypes , abstract interface или abstract valuetype . Обычно, когда я моделирую объекты с большим количеством методы get / set, которые я предпочитаю использовать valuetypes вместо interfaces .

Возвращаясь к вашему вопросу, лучший способ понять «атрибут» - это найти C #. IIOP.NET сопоставляет атрибут с свойствами . Свойство имитирует открытый член, но это метод get / set.

Отвечая на ваш вопрос, я не могу знать, вернет ли someObj.someName != someObj.someName истину или ложь, не увидев реализацию someObj. Я добавлю два примера, чтобы дать представление о том, что мы можем видеть.

Пример 1) Эта реализация всегда будет возвращать false для выражения выше:

private static i;

public string getSomeName() {
  return "myName"   i;
}

Пример 2) Эта реализация ниже может возвращать true или false, в зависимости от параллелизма или «состояния гонки» между клиентами.

public string getSomeName() {
  return this.someName;
}

public setSomeName(string name) {
  this.someName = name;
}

Первый клиент может попытаться получить доступ к someObj.someName() != someObj.someName(). Второй клиент может вызвать setSomeName () перед вторым вызовом первого клиента.

Answer 2

Для someObj.someName != someObj.someName вполне приемлемо быть правдой, как это ни странно может показаться.

Причина (как на это ссылались другие) заключается в том, что атрибуты соответствуют реальным функциям RPC. В случае атрибутов readonly они просто отображаются на сеттер, а для атрибутов, не предназначенных только для чтения, есть сеттер и геттер, неявно созданные для вас при компиляции IDL. Но важно знать, что атрибут IDL имеет динамическое, определяемое сервером, RPC-управляемое значение .

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

Если атрибут, скажем, currentTime, то, возможно, вы будете получать текущее время сервера на каждом извлечении значения. В этом случае someObj.currentTime != someObj.currentTime, скорее всего, всегда будет истинным (при условии, что используемая гранулярность времени меньше, чем объединенное время приема-передачи для двух вызовов RPC).

Если вместо этого атрибута currentBankBalance, вы можете иметь значение someObj.currentBankBalance != someObj.currentBankBalance, которое может быть истинным, потому что могут быть другие клиенты, работающие в других местах, которые постоянно изменяют атрибут с помощью функции сеттера, поэтому вы имеете дело с условием гонки. тоже.

С учетом всего вышесказанного, если вы посмотрите очень формально на спецификацию IDL, он не содержит языка, который фактически требует, чтобы установка / доступ к атрибуту приводил к вызову RPC серверу. Может обслуживаться клиентским ORB. Фактически, это то, что некоторые поставщики ORB воспользовались еще во времена расцвета CORBA. Раньше я работал на Orbix ORB , и у нас была функция, называемая Smart Proxies - то, что позволяло бы разработчику приложения перегружать предоставляемые ORB клиентские прокси по умолчанию (которые всегда переадресовывать все вызовы атрибутов на сервер, на котором размещен целевой объект) с пользовательскими функциями (например, для кэширования значений атрибутов и возврата локальной копии без нагрузки на сеть или сервер).

Таким образом, вы должны быть очень четкими и точными в том, что вы пытаетесь проверить формально. Учитывая динамический и недетерминированный характер значений, которые они могут возвращать (и тот факт, что клиентские ORB могут вести себя по-разному друг от друга и при этом оставаться совместимыми со спецификацией CORBA) вы можете только надежно ожидать, что атрибуты IDL будут сопоставлены с получателями и сеттеры, которые можно использовать для получения или установки значения . Просто не существует предсказуемости, связанной с возвращаемыми фактическими значениями.

Answer 3

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

Так что в общем случае может случиться так, что someObj.someName! = SomeObj.someName. Например, атрибут может быть последним временем доступа.