CORBA：CORBA IDL 类型可以是另一个类型的属性吗？

发布于 2024-09-15 09:51:15 字数 553 浏览 1 评论 0原文

在开始使用 CORBA 之前，我想了解一些信息。

对我来说，很直观的是，您可以使用 IDL 类型作为另一个 IDL 类型的属性，然后该属性也会将该属性的方法公开给客户端应用程序（使用“.”）。

但这可能吗？

例如（请原谅我糟糕的 IDL）：

interface Car{ 
      attribute BrakePedal brakePedal; 
      //... 
}



//then.. (place above) 

interface BrakePedal{ 
      void press(); 
      //... 
} 

//...

然后在客户端应用程序中，您可以执行以下操作： myCar.brakePedal.press();

如果您无法执行这些多级操作，CORBA 会显得很糟糕对象接口。毕竟，现实世界的物体是多层次的，对吧？也可以有人让我放心并确认（或者尝试，如果您已经设置了 CORBA）这是否确实有效？ IDL 文档都没有在示例中明确显示这一点，这就是我担心的原因。谢谢！

原文

Before I start using CORBA I want to know something.

It would seem intuitive to me that you could use an IDL type as an attribute of another, which would then expose that attribute's methods to the client application (using ".") as well.

But is this possible?

For example (excuse my bad IDL):

interface Car{ 
      attribute BrakePedal brakePedal; 
      //... 
}



//then.. (place above) 

interface BrakePedal{ 
      void press(); 
      //... 
} 

//...

Then in the client app, you could do: myCar.brakePedal.press();

CORBA would seem crappy if you couldn't do these kind of multi-level
object interfaces. After all, real-world objects are multi-level, right? So can
someone put my mind at ease and confirm (or try, if you already have CORBA set up) if this definitely works? None of the IDL documentation explicitly shows this in example, which is why I'm concerned. Thanks!

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

冷弦 2024-09-22 09:51:15

声明一个属性在逻辑上相当于声明一对访问器函数，一个用于读取属性的值，一个用于写入它（您也可以拥有只读属性，在这种情况下您只会得到读取功能）。

它确实出现在 CORBA 规范中。您可以将接口名称作为属性名称。我尝试将这样的 IDL 提供给omniORB 的 IDL 到 C++ 转换器，它并没有拒绝它。所以我认为这是允许的。

但是，我真的不确定您是否愿意在实践中这样做。大多数 CORBA 专家建议，如果您要使用属性，则仅使用 readonly 属性。对于这样的事情，我只需声明我自己的返回接口的函数。

请注意，无论如何，您都无法真正在 C++ 映射中执行您想要的语法；例如

server->brakePedal()->press();   // major resource leak here

，brakePedal() 是返回 CORBA 对象引用的属性访问器函数。如果您立即对其调用 press() ，您将泄漏对象引用。

要做到这一点而不发生泄漏，您必须执行以下操作：

BrakePedal_var brakePedal(server->brakePedal());
brakePedal->press();

在这种情况下，您根本无法使用 C++ 映射从属性中获得所需的符号便利性（也许您可以在 Python 映射中获得）。因此，加上我一般不喜欢属性，我只使用常规函数来返回 BrakePedal 接口。

Declaring an attribute is logically equivalent to declaring a pair of accessor functions, one to read the value of the attribute, and one to write it (you can also have readonly attributes, in which case you would only get the read function).

It does appear from the CORBA spec. that you could put an interface name as an attribute name. I tried feeding such IDL to omniORB's IDL to C++ translator, and it didn't reject it. So I think it is allowed.

But, I'm really not sure you would want to do this in practice. Most CORBA experts recommend that if you are going to use attributes you only use readonly attributes. And for something like this, I would just declare my own function that returned an interface.

Note that you can't really do the syntax you want in the C++ mapping anyway; e.g.

server->brakePedal()->press();   // major resource leak here

brakePedal() is the attribute accessor function that returns a CORBA object reference. If you immediately call press() on it, you are going to leak the object reference.

To do this without a leak you would have to do something like this:

BrakePedal_var brakePedal(server->brakePedal());
brakePedal->press();

You simply can't obtain the notational convenience you want from attributes in this scenario with the C++ mapping (perhaps you could in the Python mapping). Because of this, and my general dislike for attributes, I'd just use a regular function to return the BrakePedal interface.

回复收藏 0 原文

眼眸里的那抹悲凉 2024-09-22 09:51:15

您不了解分布式对象的一些重要内容：远程对象（无论是使用 CORBA、RMI、.NET 远程处理还是 Web 服务实现）与本地对象不同。对 CORBA 对象的调用成本高昂、速度缓慢，并且可能因网络问题而失败。 object.attribute.method() 语法会让人很难看到同一行上正在执行两个不同的远程调用，并且很难处理可能发生的任何故障。

回复收藏 0 原文

~没有更多了~