Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
comp.object.corba
+ new post
About this group
Subscribe to this group
This is a Usenet group - learn more
Message from discussion What is Corba used for?
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
corba.object  
View profile  
 More options May 31 2005, 8:32 am
Newsgroups: comp.object.corba
From: "corba.object" <paperless...@gmail.com>
Date: 31 May 2005 05:32:42 -0700
Local: Tues, May 31 2005 8:32 am
Subject: Re: What is Corba used for?
Print | View thread | Show original | Report this message | Find messages by this author

> Not exactly. It depends on what/where/how the system functions are
> used. If used for delivering CORBA object invocations or to performing
> CORBA services/features (such as calling functions of ORB, POA or PI),
> they are transparent to CORBA applications, and inherently, the system
> portability issue has been addressed already.

Well, when I say a software system, CORBA is a small part of it, that
only enables transparent communication among its objects and access
domain services in a uniform manner.

 But it is not my complete system. Right? CORBA then becomes very small
part of my overall system. By that what I mean is that object
communication is not the end am looking for. Am looking for development
and deployment of those objects as well, over heterogeneous
environment.

 Here comes one of the most trivial and irritating problem CORBA
offers, name of stubs and skeletons files, is not portable.! No other
words than its ridiculous, then that vendors didnt suggest this
themselves?

Dr. Schmidt has correctly suggested to correct this issue.

> If used to implement
> client logic or servant logic, then, they are out of the scope of
> CORBA, and their portability is not an issue of CORBA.

I never said that it is within scope of CORBA currently. But if I go by
general definition of "middleware"

------start
A "middleware system" (a.k.a. computing infrastructure) constitutes a
set of services that aim at facilitating the development of distributed
applications in heterogeneous environments. The primary objectives of
middleware are to foster APPLICATION PORTABILITY and distributed
application component interoperability. At least conceptually, the
"middleware layer" comprises a layer below the application and above
the operating system and network substrate. Common middleware platforms
include CORBA, DCOM, Java RMI, MQSeries, and MSMQ et al.
----end

Repeat "application portability". Lets forget about all middle
wares other than CORBA (as they don't resolve so many complex issues
that corba resolves). So how does corba resolves "application
portability". When the vendors are stuck at "non portability" of
stubs and skeletons (use less from application programmers
perspective).

Let me put this way, how does vendors provide corba implementation for
different platforms?  I am sure they would have abstracted a layer
wherein they would be handling all platform specific issues. At least
ACE (TAO) has open implementation. And this is better design as well.

So what am suggesting is make this layer available to application
programmer as well, as a standard.  So that CORBA becomes a true
middleware by providing complete portability.

> Unlike Java, .NET, etc,. CORBA itself is not "yet another uniform"
> programming environment/platform, but a "middleware" infrastructure
> to "mediate" business logics  distributed over heterogeneous
> environments.

J2EE / .NET too provide middleware infrastructure. And to a large
extend their success can be attributed to uniform programming
environment and supporting tools that are easy to develop, at least
compared to corba tools!

CORBA can be made to address this aspect as well.

> Firstly, there had been many attempts to standardize portable OS
> interfaces in history, seen in the efforts of UI (unix international),
> POSIX, OSF and X/Open (the two are now OpenGroup), etc.. Attempts of
> having similar thing crossing unix and windows are not rare either,
> including POSIX API (or its C++ variant) on Windows, WIN32 API or MFC
> for unix, and so on, not mention open source contribution from GNU and
> others. OMG is only one middleware standard body (certainly, OMG also
> has many service and domain specific standards and MDA). To standardize
> portable OS interface, OMG has almost no influence and zero credit
> comparing to OpenGroup, ISO, IEEE and even ANSI, etc.. Therefore, even
> if people wanted to reinvent-the-wheel, OMG is not the right
> organization to head this effort.

I never meant to let OMG standardize os layer. After all OMG is not
trying to address that space at all. It is putting all the efforts to
standardize middleware, so that completely interoperable and portable
systems may be developed.

Mind you portable! Again. And this can be achieved as demonstrated by
at least one orb vendor.

> Secondly, it is easy to construct a portable OS layer which covers
> selected system functions enough to implement a few specific ORBs and
> applications. NEVERTHELESS, contrary to what you thought, it is
> non-trivial at all to generalize this, by extending CORBA, to an
> universal portable application programming platform. If it was as easy
> and useful as you thought, why it hasn't been addressed for years,
> and has to wait  the hero OMG, who was said to out smart OpenGroup,
> ISO, IEEE, ANSI folks just because who happen to have a magic thing
> called CORBA? Even if excluded database and message middleware
> abstractions and so on, and only limited this portable layer to cover
> OS system functions, it would still not be a trivial undertaking to
> have most mainstream flavor unix, windows and various RTOS (not merely
> socket and thread parts) covered by one Swiss army knife which could be
> reasonably function complete (not merely a small common subset),
> efficient (it is no than an impl. issue!!), scaleable (in sense of
> dynamic and static), consistent, extendable, intuitive and clear-cut,
> ... and so on.  Some of the above requirements are even mutual
> exclusive. For instance, function complete (even if not 100%),
> simplicity, lightweight and efficient together may prohibit
> portability.

Am not suggesting to make uniform os layer. But provide to application
programmer uniform layer.

> Thirdly, extending CORBA specification (or some other OMG
> specifications) to based on a language (C++) specific design would
> immediately bring damages to the consistency of the CORBA architecture,
> such as language neutral and consistent memory management rule defined
> by IDL-to-C++ mapping.

Why How?? Even now we do have language specific mapping specification.

> An alternative is using local object IDL to
> define such abstraction. Nevertheless, even if it could be accepted
> outside OMG community, it was likely to have performance penalty, as a
> lesson we have learnt from portable interceptor.

Things can always be designed in a better way. I mean vendors should
use that knowledge and contribute as per their exp for the development
of such a standard than allowing again to develop non portable
application, and incur cost in when needed for migration, re-deployment
etc.

> Again, pls consider,
> if we could easily and consistently extend CORBA or another OMG
> specifications to include what you suggested, why would it wasn't
> there in the original OMA or CORBA architecture? We are out smart our
> OMG initiators?

Ah not like that. Everything has a start, and we know a thing finally
shapes up in iteration. Not waterfall. Right?

> As I said, it was my GUESS. I don't assume I am out smart those folks
> defined the C++ mapping, and would like to GUESS their original
> consideration of not specifying this. Pls think about non-trivial
> cases. For instance, how would the specification avoid generated head
> file names to conflict with existing system and library header files.
> How would the specification ensure the generated header file name and
> extension name are valid on all mainstream platforms (some platforms
> have strict name length limitation).

How does it currently addresses using c++ key words in idl?

Point is we need to first do correct things and than address things
that are now behaving wrong because of this correction. Provide some
solution for that.

> What would be the best practice to
> partition generated content in header files (e.g. all in one jumbo
> header file, or partitioned to multiple header files). If an IDL file
> includes other IDL files, should one jumbo header file be generated, or
> one (or multiple) header file(s) for each of the original and included
> IDL files?

How much does that affects the user?

 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
©2012 Google