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

Question

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

interface MyInterface { 
    readonly attribute SomeType someName; 
}; 

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

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

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

...

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

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

Answer 1

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

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

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

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

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

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

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

Answer 2

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

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

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

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

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

private static i; 

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

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

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

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

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

Answer 3

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

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