Hello, I have reciently discovered this whole COM/DCOM/COM+/CORBA/UNO and the like, and am very confused.
I feel like I'm jumping from an imperative coding style, to functional, or from C to C++, in that I wonder why we use this.
I have searched for ages on www.omg.org, but I could not find anything like a Design Rationale for the effort.
Why do we do all this work with stubs, why has so much work been done with implementing the various CORBA implementations? Why is the (Correct me if I'm wrong), network archietecture not routable?
Why don't we just use shared libs or dll's to share functions?
Finally, I might add that while you may be able to answer most of these questions now, what I am asking for is why was this developed in the _first_place_? (Surely there was some document specifying a need, and a solution, ie, the Design Rationale).
I have poked around the omg.org website, but it seems to have a heck alot of technical implementation issues, and I can't find the wood for the trees.
CORBA, or some other distributed OO middlewares in general, are designed to fill up the semantic gap between high level distributed OO architecture design and low level transport. Here, distributed OO design means, your architecture design partitioned an application into business objects, located at different locations. As a good practice, architecture designs are usually business oriented, and avoid specific physical location, communication, platform, programming language, details. In this case, either you implement your own middle abstract layer to fill up this high level abstraction to low level transport, or, you use a third party middleware, like CORBA.
If your application itself is already system or transport oriented, such as your purpose is simply sending an email or sending some data through a socket, you certainly don't need such a middle abstraction layer, or any CORBA like middleware at all.
Arafangion wrote: > Hello, I have reciently discovered this whole COM/DCOM/COM+/CORBA/UNO > and the like, and am very confused.
> I feel like I'm jumping from an imperative coding style, to functional, > or from C to C++, in that I wonder why we use this.
> I have searched for ages on www.omg.org, but I could not find anything > like a Design Rationale for the effort.
> Why do we do all this work with stubs, why has so much work been done > with implementing the various CORBA implementations? > Why is the (Correct me if I'm wrong), network archietecture not routable?
This is irrelevant. CORBA is not for network routing.
> Why don't we just use shared libs or dll's to share functions?
This is irrelevant either. CORBA is not for sharing functions.
> Finally, I might add that while you may be able to answer most of these > questions now, what I am asking for is why was this developed in the > _first_place_? (Surely there was some document specifying a need, and a > solution, ie, the Design Rationale).
> I have poked around the omg.org website, but it seems to have a heck > alot of technical implementation issues, and I can't find the wood for > the trees.
Ke Jin wrote: > CORBA, or some other distributed OO middlewares in general, are > designed to fill up the semantic gap between high level distributed OO > architecture design and low level transport. Here, distributed OO > design means, your architecture design partitioned an application into > business objects, located at different locations. As a good practice, > architecture designs are usually business oriented, and avoid specific > physical location, communication, platform, programming language, > details. In this case, either you implement your own middle abstract > layer to fill up this high level abstraction to low level transport, > or, you use a third party middleware, like CORBA.
> If your application itself is already system or transport oriented, > such as your purpose is simply sending an email or sending some data > through a socket, you certainly don't need such a middle abstraction > layer, or any CORBA like middleware at all.
But, even though business logic design doesn't talk about the physical location of the objects, transport etc, isn't it the case that binding oneself to a particular implmentor (visi / omniorb etc), does pull that implementation's specifics into the application ? Doesn't that make it a tard difficult to move between various ORBs ? Ke what do you think about that ?
>> But, even though business logic design doesn't talk about the >> physical location of the objects, transport etc, isn't it the case >> that binding oneself to a particular implmentor (visi / omniorb >> etc), does pull that implementation's specifics into the >> application ? Doesn't that make it a tard difficult to move between >> various ORBs ?
Naturally, it depends on
. Which ORBs you use, e.g., some ORBs are more compliant with the spec than others. In particular, if you use the ORB bunded with the Sun JDK then you're simply SOL since that ORB is very non-compliant. Fortunately, the mainstream ORBs are much more compliant.
. How you approach ORB portability, e.g., what steps you take to avoid portability issues. In particular, if you check out
you'll see a toolkit that simplifies development of ORB-independent software for most mainstream ORBs.
Take care,
Doug -- Dr. Douglas C. Schmidt Professor and Associate Chair Electrical Engineering and Computer Science TEL: (615) 343-8197 Institute for Software Integrated Systems WEB: www.dre.vanderbilt.edu/~schmidt Vanderbilt University, Nashville TN, 37203 NET: d.schm...@vanderbilt.edu
Gangadhar NPK wrote: > But, even though business logic design doesn't talk about the physical > location of the objects, transport etc, isn't it the case that binding > oneself to a particular implmentor (visi / omniorb etc), does pull that > implementation's specifics into the application ? Doesn't that make it > a tard difficult to move between various ORBs ? Ke what do you think > about that ?
Middleware providing low level system "transparency", and applications' "portability" acrossing different middleware implementations are two orthogonal concepts.
Different ORBs are implemented differently, and likely come with various non-standard, vendor specific value added, portable or even non-portable, features. However, almost all of them are provided "transparently". For instance, many ORB implementations use OMG standardized IIOP (namely, GIOP over TCP) as well as vendor specific alternatives (such as GIOP over shared memory or solaris door) for distributed object invocations. But this transport detail, namely whether vendor specific, system level alternatives are used and how, is transparent to business level applications.
Moving applications across foreign ORBs is an "portability" issue. As said, it is orthogonal to the "transparency" concept discussed above. Differences on "how" ORBs was implemented do not prohibit applications to moving among them. What prohibit this kind move are differences (usually mean syntactic and semantic differences at application level) on "what" these ORB implemented. If your application used an application level feature only supported by one ORB but not another, it would have difficult to be ported from the first ORB to the second.
I think from "CORBA provides platform independence", this line implicit means that it must be providing system independence as well, that means abstraction over os specific features/calls as well.
And I think TAO build over ACE layer is an good effort and to an extent provides that.
Otherwise as well, it shuld not take much to at least standardize names of headers and libraries of ORB that are required to build a CORBA application. That way at least applications will be automatically ORB independent, and this will cost nothing to ORB vendors other than a name change to their corba related headers and library files.
comp.object wrote: > I think from "CORBA provides platform independence", this line implicit > means that it must be providing system independence as well, that means > abstraction over os specific features/calls as well.
Platform/system call level independence is usually referred to as "system level portability", namely porting applications across different OSs. This portability is different from previously mentioned "CORBA application level portability", moving CORBA applications acrossing forigen ORBs.
System level portability is not the task of CORBA, but a mission of system level API standards or packages, such as POSIX (including socket/winsock API, posix thread, etc.), or some portable socket/network/thread classes/packages (there are too many such libraries nowadays). Comparing to these portable system level APIs, CORBA provides higher level abstraction. In these abstractions, objects are system level entities, such as sockets (abstraction of network endpoint) or socket classes, files (abstraction of device), shared memory id (abstraction of shared memory sections), etc.. If you need write system/network level applications, you should use a portable system/network level library, but not CORBA.
Instead of providing a portable unification of system/network logic and objects, CORBA hides these low level logic/objects/location on performing distributed business level object invocations. OS level details are transparent to business level applications, not mention portability. CORBA Objects at this level are user defined, business oriented objects.
> And I think TAO build over ACE layer is an good effort and to an extent > provides that.
I don't know too much about TAO and ACE, therefore, can't comment. But AFAIK, almost all ORBs are built on an OS level portable layer, chosen and usually implemented by vendor themselves. Vendors may or may not expose/provide this layer along with their ORBs.
As said, CORBA is to HIDE OS level logic, therefore, application PORTABILITY at this level is not a task of CORBA. Certainly, your business level object implmentation (servant implementation) may use system level logic, database logic, etc., but that is out side the scope of CORBA.
> Otherwise as well, it shuld not take much to at least standardize names > of headers and libraries of ORB that are required to build a CORBA > application. That way at least applications will be automatically ORB > independent, and this will cost nothing to ORB vendors other than a > name change to their corba related headers and library files. > Wonder why this has not still been standardized.
Now, you come back to CORBA application portability acrossing foreign ORBs. This is different from system level portability you mentioned above. OMG has port many effort on this, including standardize client and server side language mappings, POA and PI. Not standardizing header file names (in C++ mapping), I guess, is merely to give flexability to different ORBs, as well as to favor different application preferances. As far as I know, most ORBs allow application developers to specify the generated header file name prefix and extension, even the full name.
I agree that system portability is not an issue addressed by CORBA. But it may address that as well? right..?After all, if we are looking for truly distributed software systems, we should have mechanism to develop such system as welll uniformly?
So my version is it should not take much for OMG to extend its specification to cover abstraction over underlying os as well, as it affects distribution, deployment etc.
My view is mapping may not be standardaized suppose. but the names of stubs/skeleton files can be standardized so that we dont have to change the name everytime we change ORB at least? And anyway it doesnt affects any other behaviour right? Just a name change.
I could not get how it provide vendors more flexibility by not standardizing the header file name? what flexibility u r referring to?
Its true most of the ORB provides mechanism to specify the header file name, but that is an unnecessary step.
>> I agree that system portability is not an issue addressed by CORBA. >> But it may address that as well? right..?After all, if we are looking >> for truly distributed software systems, we should have mechanism to >> develop such system as welll uniformly?
>> So my version is it should not take much for OMG to extend its >> specification to cover abstraction over underlying os as well, as it >> affects distribution, deployment etc.
There have been various efforts in the OMG to standardize this layer of abstraction. OCI recently presented a proposal for using portions of ACE to accomplish this. It's not very technically hard to do this - the trick is to get the other ORB vendors to agree. Until they do, of course, you can simply use ACE as a portability layer within your client and servant implementations (it should work with any C++ ORB) and get the same effect.
>> My view is mapping may not be standardaized suppose. but the names of >> stubs/skeleton files can be standardized so that we dont have to change >> the name everytime we change ORB at least? And anyway it doesnt affects >> any other behaviour right? Just a name change.
I agree that it would be a good idea to standard this sort of stuff. While we're waiting for that to happen, you can already accomplish your objectives by using the CORBA-conf tool at
-- Dr. Douglas C. Schmidt Professor and Associate Chair Electrical Engineering and Computer Science TEL: (615) 343-8197 Institute for Software Integrated Systems WEB: www.dre.vanderbilt.edu/~schmidt Vanderbilt University, Nashville TN, 37203 NET: d.schm...@vanderbilt.edu
> Why do we do all this work with stubs, why has so much work been done > with implementing the various CORBA implementations? > Why is the (Correct me if I'm wrong), network archietecture not routable?
> Why don't we just use shared libs or dll's to share functions?
> Finally, I might add that while you may be able to answer most of these > questions now, what I am asking for is why was this developed in the > _first_place_? (Surely there was some document specifying a need, and a > solution, ie, the Design Rationale).
If u look for developing a c++/fortran/c/java etc application running in a single host environment its fine.
But how about when u want to develop an application part of whoes logic could be in a flying plane or satellite up in the sky and part at its control center down on earth. Making it easy how about reservation systems or banking systems whoes logic is partially distributed across hosts of computer?
Here comes the problem. Either each systems should be uniformly developed using same language / computer to enable interactions. Also u need to take care of connection management, connection opening/closing, U need to put in lots of efforts to enable fault tolerance, load-balancing etc. Then their are issues to be managed related to location of each of these hosts etc.
the tech like CORBA, COM/DCOM/ etc. provides u a platform to develop such an application with the relatively same ease as any standalone systems.
These tech/softwares takes care of networking stuff, and provide an abstraction that enables u to develop application in a completely transparent manner.
A programmer doesnt requires to write any code for connecting/disconnecting remote objects. He is required to address any issue arising out of "what if various objects of the systems are developed using diff languages on diff platforms".
In other words it provides complete interoperability among objects written in any platform (read os and language).
And also because CORBA comes with host of standard services, so makes code portable across any corba implementations (albeit with a trivial efforts).
comp.object wrote: > I agree that system portability is not an issue addressed by CORBA.
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. 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.
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.
> But it may address that as well? right..? After all, if we are looking > for truly distributed software systems, we should have mechanism to > develop such system as welll uniformly?
> So my version is it should not take much for OMG to extend its > specification to cover abstraction over underlying os as well, as it > affects distribution, deployment etc.
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.
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.
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. 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. 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?
> My view is mapping may not be standardaized suppose. but the names of > stubs/skeleton files can be standardized so that we dont have to change > the name everytime we change ORB at least? And anyway it doesnt affects > any other behaviour right? Just a name change.
> I could not get how it provide vendors more flexibility by not > standardizing the header file name? what flexibility u r referring to?
> Its true most of the ORB provides mechanism to specify the header file > name, but that is an unnecessary step.
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). 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?
> 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?
corba.object wrote: > > 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.
You have brought two issues in this thread:
1. Generated header file names unification crossing foreign orbs. I don't call this "portability" to avoid confusion with next issue. For this unification, I said, I was just "guessing" why folks defined C++ mapping didn't put this seemingly trivial thing in the specification.
2. Extending CORBA specification to support generic application code portability. As you are just iterating your original arguments, I also will iterate mine briefly (for detail, see previous post):
* OMG is not a right organization to head this effort. It should go to Opengroup, ISO, IEEE, etc..
* It is easy to construct an OS portable layer sufficient for one ORB or few applications. But, it is non-trivial at all to generize this.
> 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?
>> 1. Generated header file names unification crossing foreign orbs. I >> don't call this "portability" to avoid confusion with next issue. For >> this unification, I said, I was just "guessing" why folks defined C++ >> mapping didn't put this seemingly trivial thing in the specification.
Even POSIX standardizes header files. This should be done for CORBA, as well. If it's so trivial it should be a no-brainer to standardized.
>> * OMG is not a right organization to head this effort. It should go to >> Opengroup, ISO, IEEE, etc..
Those organizations haven't stepped up to the plate to do this for anything except C. OMG is as good as a place as any.
>> * It is easy to construct an OS portable layer sufficient for one >> ORB or few applications. But, it is non-trivial at all to generize >> this.
It's non-trivial, but it's doable.
>> * It damages CORBA.
Huh? You need to explain this better - it makes no sense at face value, and is one of the reasons why CORBA is losing out to other middleware technologies.
Take care,
Doug -- Dr. Douglas C. Schmidt Professor and Associate Chair Electrical Engineering and Computer Science TEL: (615) 343-8197 Institute for Software Integrated Systems WEB: www.dre.vanderbilt.edu/~schmidt Vanderbilt University, Nashville TN, 37203 NET: d.schm...@vanderbilt.edu
> >> 1. Generated header file names unification crossing foreign orbs. I > >> don't call this "portability" to avoid confusion with next issue. For > >> this unification, I said, I was just "guessing" why folks defined C++ > >> mapping didn't put this seemingly trivial thing in the specification.
> Even POSIX standardizes header files. This should be done for CORBA, > as well. If it's so trivial it should be a no-brainer to standardized.
Again, the 4th times: I was "guessing"!! Also, pls read considerations I put in previous post. Besides, I don't recall POSIX standard needs to deal with header files generated from an user specified interface file. Pls enlight us!
> >> * OMG is not a right organization to head this effort. It should go to > >> Opengroup, ISO, IEEE, etc..
> Those organizations haven't stepped up to the plate to do this for > anything except C. OMG is as good as a place as any.
If IETF, TMF, and especially W3C also doing the samething and saying "we are as good as a place as any", do you agree?
> >> * It is easy to construct an OS portable layer sufficient for one > >> ORB or few applications. But, it is non-trivial at all to generize > >> this.
> It's non-trivial, but it's doable.
Now, you start to agree "it is non-trivial"!? It is definitly doable, and has been repeatly independently done for many years, many times, by many people, in many commercial products and student projects. But, to "standardize" this be able to meet reasonably generic application needs is more than to implement it for few specific applications and few specific platforms.
> >> * It damages CORBA.
> Huh? You need to explain this better - it makes no sense at face > value, and is one of the reasons why CORBA is losing out to other > middleware technologies.
See previous post. Also, I don't see other comparable "middleware" technologies "standardized" this. Which one? J2EE and .NET do standardize their system interfaces. However, they are both (claimed to be) middlewares, as well as programming environment/platforms. If you are really ambitious to extend CORBA beyond middleware scope to become a programming environment/platform as well, you should:
* Make it clear in OMG, especially to most members and AB. This is not a small move. and it should be done top down, starting from an overall architecture vision, and the foundition hierarchy, rather than bottom up, starting from a specific system interfaces without knowing whether and where it would fit in within the final architecture.
* At least define your system interfaces using IDL, instead of language specific;
> Doug > -- > Dr. Douglas C. Schmidt Professor and Associate Chair > Electrical Engineering and Computer Science TEL: (615) 343-8197 > Institute for Software Integrated Systems WEB: www.dre.vanderbilt.edu/~schmidt > Vanderbilt University, Nashville TN, 37203 NET: d.schm...@vanderbilt.edu
Ke Jin wrote: > Douglas C. Schmidt wrote: > > Hi Ke,
> > >> * OMG is not a right organization to head this effort. It should go to > > >> Opengroup, ISO, IEEE, etc..
> > Those organizations haven't stepped up to the plate to do this for > > anything except C. OMG is as good as a place as any.
> If IETF, TMF, and especially W3C also doing the samething and saying > "we are as good as a place as any", do you agree?
To clarify myself, I can think of two possible intentions of you standardize system interface:
1. For generic applications, not necessary relevant to CORBA. If this is your intention, you certainly can specify you interface language specifically (for instance, C++ only). However, OMG will not be the right origination to head this effort. You should go Opengroup, ISO, IEEE, or try ANSI, etc.
2. For extending CORBA from a middleware platform to a programming environment/platform (similar to J2EE and .NET). If this is your intention, YES, you should do it within OMG. However, you should not do it in language specific way, and also should no do it from bottom up.
>Again, the 4th times: I was "guessing"!! Also, pls read considerations >I put in previous post. Besides, I don't recall POSIX standard needs to >deal with header files generated from an user specified interface file. >Pls enlight us!
What about generated from standard corba interfaces??
>If IETF, TMF, and especially W3C also doing the samething and saying >"we are as good as a place as any", do you agree?
OMG today is writing standards for middleware. So whatever is required for the longevity, portability etc. of such softwares, it must take initiative to address that. It may do that in conjunction with other existing bodies, but that is upto it.!!
>Now, you start to agree "it is non-trivial"!? It is definitly doable, >and has been repeatly independently done for many years, many times, by >many people, in many commercial products and student projects. But, to >"standardize" this be able to meet reasonably generic application needs >is more than to implement it for few specific applications and few >specific platforms.
I think its not trivial. But definitely required for building up a portable and more widely deployable applications. And more for promoting/ popularity of CORBA among user community.
And so a concerted effort is required to achieve the same.
>See previous post. Also, I don't see other comparable "middleware" >technologies "standardized" this. Which one? J2EE and .NET do >standardize their system interfaces. However, they are both (claimed to >be) middlewares, as well as programming environment/platforms. If you >are really ambitious to extend CORBA beyond middleware scope to become >a programming environment/platform as well, you should:
You are making me wonder !! Should not middleware provide uniform programming model as well. CORBA does provides a programming model/ environment only thing is it is limited for its own usage and to an extent it provides some powerful mechanism (Servant Managers for programmers) still it must be enhanced to assist end users or application programmer, specifically portability.
And this will definitely help to even tool vendors to develop better corba based tools.
>Make it clear in OMG, especially to most members and AB. This is not >a small move. and it should be done top down, starting from an overall >architecture vision, and the foundition hierarchy, rather than bottom >up, starting from a specific system interfaces without knowing whether >and where it would fit in within the final architecture.
Here is the list of platforms supported by Visibroker CORBA implementation
I assume most of the vendors would have already abstracted in their implementation a uniform application interfaces over os for developing their own corba implementation. As most of the vendors provide CORBA implementation over no of platforms.
Why and how will it be different than providing (Definitely it will be some effort for adjustment. But overall good for corba industry.
I mean what is stopping vendors themselves proposing this to OMG. As TAO has done. And in most probability others would have done it already.
If not let ACE framework be made as standard.
>At least define your system interfaces using IDL, instead of language >specific;
I think most of big application developers do it. We also do it. Still it should be addressed by middleware.
regards
------------- Shashank D. Jha iCMG e-mail shash...@icmgworld.com
>1. For generic applications, not necessary relevant to CORBA. If this >is your intention, you certainly can specify you interface language >specifically (for instance, C++ only).
Let me state in other words
I want to use CORBA for my applications. CORBA is an standard specification. Why I need to write any code at least when I want to use CORBA implementation i.e. ORB, specific to an ORB?
I know its trivial to make changes in spec as well as implementation to ensure that the programmers code specific to CORBA (ORB) should not change as per ORB. Also it doesn't takes much even for a programmer to include appropriate headers as per ORB but still.
Secondly I want to write applications that are going to use CORBA middleware. Doesn't it make sense for the middleware to provide uniform system interface as well to enable complete portability of not only programming/ development but distribution/ deployment as well.
If you feel that distribution and deployment of an application is a trivial issue refer to "Deployment and configuration spec for CCM components".
At least to an extent those issues can be made much simpler if the developer need not write code specific to an os, and this layer is abstracted within middleware itself.
>2. For extending CORBA from a middleware platform to a programming >environment/platform (similar to J2EE and .NET). If this is your >intention, YES, you should do it within OMG. However, you should not do >it in language specific way, and also should no do it from bottom up.
I think OMG will certainly address these issues sooner or later. But vendors should themselves take active interest and participate in standardizing this layer.
regards
------------- Shashank D. Jha iCMG e-mail shash...@icmgworld.com
> >1. For generic applications, not necessary relevant to CORBA. If this > >is your intention, you certainly can specify you interface language > >specifically (for instance, C++ only).
[snip]
> Secondly I want to write applications that are going to use CORBA > middleware. Doesn't it make sense for the middleware to provide > uniform system interface as well to enable complete portability of not > only programming/ development but distribution/ deployment as well.
> If you feel that distribution and deployment of an application is a > trivial issue refer to "Deployment and configuration spec for CCM > components".
> At least to an extent those issues can be made much simpler if the > developer need not write code specific to an os, and this layer is > abstracted within middleware itself.
There is nothing prevents you from having such a portable OS layer today. There are tens of them on market. What you need is one, standard based and widely accepted and supported.
Now, as said in a previous post, OMG does not have the history, influence, credit on heading a generic specification which have no tie to CORBA. Therefore, it is not right to have this kind of standard process leading by OMG. It is highly questionable this standard would be accepted beyond CORBA community. If other standard bodies, such as W3C, IETF, TMF, etc. all came out their own C++ OS portable layer, the result would be none of them be widely accepted and supported. We would get multiple OS portable layer standards, and each of them was only backed by very few vendors, and only used within their individual isolated communities. This result would be no better than what we have today. We would still have tens of different OS portable layer implementations around, but all of them started to claim they were compliant to their own individual standards. I would prefer to call them "wolf-tickets"!
Therefore, if someone is trying to standardize a C++ OS portable layer, which has no tie to CORBA, it should be submit to Opengroup, ISO, IEEE or try ANSI. OMG is not the right group to play this game.
Shashank wrote: > >Again, the 4th times: I was "guessing"!! Also, pls read considerations > >I put in previous post. Besides, I don't recall POSIX standard needs to > >deal with header files generated from an user specified interface file. > >Pls enlight us!
> What about generated from standard corba interfaces??
That is not what we discussed.
[snip]
> >See previous post. Also, I don't see other comparable "middleware" > >technologies "standardized" this. Which one? J2EE and .NET do > >standardize their system interfaces. However, they are both (claimed to > >be) middlewares, as well as programming environment/platforms. If you > >are really ambitious to extend CORBA beyond middleware scope to become > >a programming environment/platform as well, you should:
> You are making me wonder !! Should not middleware provide uniform > programming model as well.
Almost ever middlewares (and also many non-middlewares) provide such OS portable wrapper. The question is NOT whether a middleware vendor should provide this solution, but whether the "standard" of this OS portable layer should be CORBA (other another) middleware specific, or independent. I don't see why this OS portable layer should be and could be CORBA specific. If it is CORBA independent, it should not be specified by a OMG. It should go to a standard body who has been engaging in the standardization of OS API or programming environment, such as Opengroup, ISO, IEEE, and ANSI, etc.. (see another of my followup)
If we really want this layer to be CORBA specific, and fit in the CORBA architecture, it should be defined using IDL. However, there are more problems I would expect.....
