[omniORB] Query - Regarding Limitations of CORBA

[Santosh N Dumbre]

Hi all,

I am trying to understand various features of CORBA.

Coming across a query -
Are there any limitations associated with CORBA ?

In case of remote call, it blocks the thread and wait for reply to be received.
Some people claim that it is inefficient and major limitation of CORBA.

It it true really with CORBA ?


Kindly help my understanding.

Please reply.

Thanks,
Santosh.


________________________________________
From: omniorb-list-request at omniorb-support.com [omniorb-list-request at omniorb-support.com]
Sent: Friday, October 05, 2012 3:24 PM
To: Santosh N Dumbre
Subject: Welcome to the "omniORB-list" mailing list

Welcome to the omniORB-list at omniorb-support.com mailing list!

To post to this list, send your email to:

omniorb-list at omniorb-support.com

General information about the mailing list is at:

http://www.omniorb-support.com/mailman/listinfo/omniorb-list

If you ever want to unsubscribe or change your options (eg, switch to
or from digest mode, change your password, etc.), visit your
subscription page at:

http://www.omniorb-support.com/mailman/options/omniorb-list/santosh.dumbre%40igate.com


You can also make such adjustments via email by sending a message to:

omniORB-list-request at omniorb-support.com

with the word `help' in the subject or body (don't include the
quotes), and you will get back a message with instructions.

You must know your password to change your options (including changing
the password, itself) or to unsubscribe. It is:

ddssnn

Normally, Mailman will remind you of your omniorb-support.com mailing
list passwords once every month, although you can disable this if you
prefer. This reminder will also include instructions on how to
unsubscribe or change your account options. There is also a button on
your options page that will email your current password to you.
Information contained and transmitted by this e-mail is confidential and proprietary to iGATE and its affiliates and is intended for use only by the recipient. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, copying or use of this e-mail is strictly prohibited and you are requested to delete this e-mail immediately and notify the originator or mailadmin at igate.com. iGATE does not enter into any agreement with any party by e-mail. Any views expressed by an individual do not necessarily reflect the view of iGATE. iGATE is not responsible for the consequences of any actions taken on the basis of information provided, through this email. The contents of an attachment to this e-mail may contain software viruses, which could damage your own computer system. While iGATE has taken every reasonable precaution to minimise this risk, we cannot accept liability for any damage which you sustain as a result of software viruses. You should carry out your own virus checks before opening an attachment. To know more about iGATE please visit www.igate.com.

[Johnny Willemsen]

Hi,

Post by Santosh N Dumbre
I am trying to understand various features of CORBA.
Coming across a query -
Are there any limitations associated with CORBA ?
In case of remote call, it blocks the thread and wait for reply to be received.
Some people claim that it is inefficient and major limitation of CORBA.
It it true really with CORBA ?

It is more an implementation issue of the ORB you are using. I can't
speak for omniORB, but in case of TAO this is not true, the thread isn't
blocked by default, but we have policies to change it to blocking, for
some applications it is easier/safer to use than not blocking.

Best regards,

Johnny Willemsen
Remedy IT
http://www.orbzone.org
http://www.theaceorb.nl

[Duncan Grisby]

Post by Santosh N Dumbre
Coming across a query -
Are there any limitations associated with CORBA ?
In case of remote call, it blocks the thread and wait for reply to be received.
Some people claim that it is inefficient and major limitation of CORBA.

What is the context for that claim? It is certainly true that CORBA is
primarily a remote procedure call system, meaning that when a client
thread makes a call to a server object, the client does not have use of
that thread until the call returns. That's just like a local function
call, and I don't think people say that that is inefficient.

What the CORBA layer does with the thread while the call is taking place
depends on the CORBA implementation. omniORB generally does block the
thread, and that _makes_ it efficient. It means that as soon as the
reply is received from the server, the call can return to the client. If
omniORB was to use the thread for other things, the client would have to
wait until the other things were at a stage that could be suspended. So,
if you are interested in the efficiency of individual calls, the most
efficient thing any RPC system can possibly do is to block the threads
doing the calls.

I presume that the remark about it being a limitation is with regard to
cases where a client needs to concurrently make calls to thousands of
different servers. In that case, blocking a thread for each call would
indeed be inefficient. CORBA clients generally don't need to do that,
though, and if that's the main thing your application needs to do, CORBA
probably isn't the right technology to base it upon. The CORBA standard
has a thing called Asynchronous Method Invocation (AMI), which allows
clients to make asynchronous calls that the ORB can choose to perform in
a non-blocking manner. AMI support will be in omniORB 4.2.

In summary, CORBA is a tool. Like any tool, it is a good choice for some
requirements, and a less appropriate choice for other requirements. You
have to look at what you require and choose the right tool for the job.

Cheers,

Duncan.