What is Corba used for?
Arafangion
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.
Thankyou.
Ke Jin
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.
See other inline comments.
Ke
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.
Arafangion
> 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.
Thankyou, I think that makes sense now.
Gangadhar NPK
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 ?
Douglas C. Schmidt
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.sc...@vanderbilt.edu
Ke Jin
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.
Regards,
Ke
comp.object
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.
Wonder why this has not still been standardized.
Ke Jin
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.
Regards,
Ke
comp.object
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.
Douglas C. Schmidt
>> 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
Markus Elfring
> 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).
Can this article answer any of your questions?
http://en.wikipedia.org/wiki/CORBA
How do you think about the answers in this document?
http://www.omg.org/gettingstarted/corbafaq.htm
Regards,
Markus
comp.object
bie.
It was better explained here in a post earlier.
Anyway it was nice link.
comp.object
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).
Let me know if u still dont follow.
Ke Jin
> 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?
Regards,
Ke
corba.object
> 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?
Ke Jin
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.
* It damages CORBA.
Regards,
Ke
Douglas C. Schmidt
>> 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.
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.
Ke Jin
> Hi Ke,
>
> >> 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.
>
> 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;
Good luck!
Ke
Ke Jin
> Douglas C. Schmidt wrote:
> > Hi Ke,
>
> > >> 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.
Regards,
Ke
Shashank
>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
http://info.borland.com/techpubs/visibroker/platforms/vbj45.html
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 shas...@icmgworld.com
Shashank D. Jha
>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.
Shashank D. Jha
??
Ke Jin
Shashank D. Jha wrote:
> :
>
> >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.
Regards,
Ke
Ke Jin
> >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.....
[snip]
Regards,
Ke
Ke Jin
> >* It damages CORBA.
>
> ??
>
I have already answered multiple times in this thread. Read other posts
to find your answer. Thanks!
Ke
Ke Jin
Shashank D. Jha wrote:
> :
> >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 (MDA is an irrelevant story). Therefore, it is not right to
Shashank D. Jha
> > What about generated from standard corba interfaces??
>
> That is not what we discussed.
See previous post.
> 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)
>
It may not be CORBA specific but should be available as standard for
CORBA users.
Anyway I dont really get what is meant by CORBA specific here. ACE
exists and can be used independent of CORBA.
I am not saying to standardize uniform os layer for ORB developers to
use it. But for exposing those functionalities through CORBA/ ORB for
application programmers.
And my point is already vendors would have done it.
Let me know if you have not already abstracted os layer and you use
that for implementing your ORB across various platofms?
> 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.....
refer above.
It may be and also it might be done by extending language specific
mappings.
Shashank D. Jha
> 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 (MDA is an irrelevant story). 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.
Doesn't matter. We are talking about CORBA community here. How
programming in corba becomes simpler.
OMG should make programming in CORBA uniform and simpler.
> 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"!
>
Does MDA becomes relevent now?
> 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.
It matters. In one of the posting in C++ group earlier, I read about
C++ community talking about developing a C++ framework for developing
distributed application in C++? How do you react to this?
A centralized body has to evolved to direct global software /technology
devlopment. Is there anyone better than OMG? More so because it affects
corba community. And middlewares vision of portability and longevity of
software systems.
regards,
------------
Shashank D. Jha
iCMG
e-mail : shas...@icmgworld.com
Phone : +91-80-98451 87302
Shashank D. Jha
> I have already answered multiple times in this thread. Read other posts
> to find your answer. Thanks!
Dr. Schmidt wrote :
..start
>> * It damages CORBA.
--start
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.
--end
Ke Jin
> "Ke Jin" <ke...@borland.com> wrote in message
>
> > I have already answered multiple times in this thread. Read other posts
> > to find your answer. Thanks!
>
>
> Dr. Schmidt wrote :
> ..start
> >> * It damages CORBA.
> --start
> 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.
> --end
>
Pls read my reply to his question, and also my post before his post.
The statement he questioned was a brief repeat of a longer one I posted
previously.
Regards,
Ke
Ke Jin
> Ke Jin wrote:
> > > What about generated from standard corba interfaces??
> >
> > That is not what we discussed.
>
> See previous post.
>
If you feel relevant. You can answer four "no-brainer" questions I
listed in previous post, let me know how POSIX addressed them.
Again, that was my "guess", don't split hair.
>
> > 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)
> >
>
> It may not be CORBA specific but should be available as standard for
> CORBA users.
> Anyway I dont really get what is meant by CORBA specific here. ACE
> exists and can be used independent of CORBA.
>
By "CORBA specific", I mean somehow it has tie to CORBA architecture
and is specially designed based on CORBA, and likely not be interested
outside. For instance, OS API interfaces are defined with IDL.
I could not see why this needs to be CORBA specific either! That is
why, from very beginning, I believe this should not be a task for OMG.
With the same specification, why not submit it to Opengroup/ISO/IEEE or
ANSI to get more wide support and acceptance? If all standardization
groups just try unify OS portable layer inside their own backyard, we
would endup with an more non-unified world.
>
> I am not saying to standardize uniform os layer for ORB developers to
> use it. But for exposing those functionalities through CORBA/ ORB for
> application programmers.
Why have to exposing those functionalities through CORBa/orb? Our OS
portable layer and many others do not need CORBA/ORB to expose OS
system functions.
>
> And my point is already vendors would have done it.
>
I have repeat many times, having an implementation sufficient for
implementing an ORB or supporting some applications is easy. Generize
it is non-trivial! For more discussions, see my previous post(s).
Besides, writing a specification and having it stamped by OMG without
caring its vendor supportness and user acceptance, and only use it as
wolf-ticket, sometime, is also easy. But writing a technically good
specification, and having it widely accepted and supported requires
much more indepth/forward thinking and responsible attitude!
> Let me know if you have not already abstracted os layer and you use
> that for implementing your ORB across various platofms?
>
Sorry, I HAVE NO TIME AND INTEREST ON FLAME WAR. GOOD LUCK!
Ke
Ke Jin
> "Ke Jin" <ke...@borland.com> wrote in message
>
> > 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 (MDA is an irrelevant story). 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.
>
> Doesn't matter. We are talking about CORBA community here. How
> programming in corba becomes simpler.
>
> OMG should make programming in CORBA uniform and simpler.
>
This is not a issue specific to CORBA, it is common to many non-CORBA
applications as well, such as application using webservice as
middleware infrastructure. Therefore, this portable layer shouldn't be
designed to be CORBA specific, and should be standardized by the right
organization.
If all organizations, OMG/W3C/IETF/TMF/ITU/3GPP/... just address this
common issue independently within their own backyards, we would endup
with a more non-standardized world.
> > 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"!
> >
>
> Does MDA becomes relevent now?
>
It is not relevant to what are we discussed here. Also, the suggested
attempt of standardizing C++ OS portable layer is not compareable to
what OMG did for MDA.
> > 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.
>
> It matters. In one of the posting in C++ group earlier, I read about
> C++ community talking about developing a C++ framework for developing
> distributed application in C++? How do you react to this?
I would also suggest them standardize it in a right organization,
likely to be ANSI/ISO, if it is C++ language oriented (similar to STL),
or Opengroup it is more system oriented (similar to socket and pthread,
but in C++ form).
>
> A centralized body has to evolved to direct global software /technology
> devlopment. Is there anyone better than OMG?
On C++ and portable system layer, Opengroup/ISO/IEEE and ANSI are
definitly better than OMG, unless this layer is defined with IDL. OMG
has no history, influence, credit to play such a generic role beyond
CORBA/MDA scope. Pls be real, unless your only motivation is to have
your implementation stamped by OMG and use it as a wolf-ticket!
> More so because it affects
> corba community. And middlewares vision of portability and longevity of
> software systems.
It also affect web service, MOM applications and many other communities
as well.
Regards,
Ke
Shashank D. Jha
Ke Jin wrote:
> This is not a issue specific to CORBA, it is common to many non-CORBA
> applications as well, such as application using webservice as
> middleware infrastructure. Therefore, this portable layer shouldn't be
> designed to be CORBA specific, and should be standardized by the right
> organization.
I agree. but that doesnt means it should not be resolved for CORBA.
> If all organizations, OMG/W3C/IETF/TMF/ITU/3GPP/... just address this
> common issue independently within their own backyards, we would endup
> with a more non-standardized world.
Who will/ should take initiative?
CORBA is the most visionary and capable architecture for middleware
solution.
If languages are constraints to it, it should go ahead and write/
suggest/ mediate among all standard bodies to come together to make it
possible for its community.
> It is not relevant to what are we discussed here. Also, the suggested
> attempt of standardizing C++ OS portable layer is not compareable to
> what OMG did for MDA.
I agree its not comparable,an I dont intend to compare it either. But
to have an consistent approach to realize MDA vision we need this.
In MDA when we generate PIM to PSM code, PSM is CORBA right? or Orbix,
visibroker , OminiORB etc..?
How do you realize this unless we have consistent programming platform/
environment offered by CORBA?
And if this has to be consistently automated, we need abstraction of os
layer to be provided by middleware, which will be used for PIM to PSM
translation.
What I meant to suggest that, even if all other oranizations develop
their own standards, assuming they refused to work in co-ordination
with OMG for the same, OMG can always extend MDA's PSM model to
generate PSM model specific to execution environment.
OMG has to realize its MDA vision. And so it must take this initiative.
> I would also suggest them standardize it in a right organization,
> likely to be ANSI/ISO, if it is C++ language oriented (similar to STL),
> or Opengroup it is more system oriented (similar to socket and pthread,
> but in C++ form).On C++ and portable system layer, Opengroup/ISO/IEEE and
> ANSI are definitly better than OMG, unless this layer is defined with IDL.
Issue is not with any language. Nothing wrong with C++ as such.
ANSI/ISO and other organizations dont have vision to enable middleware
software systemes development, distribution, packaging, deployment etc.
that are portable across various middlewares.
So, initiative has to come from OMG.
> OMG has no history, influence, credit to play such a generic role beyond
> CORBA/MDA scope. Pls be real, unless your only motivation is to have
> your implementation stamped by OMG and use it as a wolf-ticket!
Doesnt matters much. As it has demonstrated successfully in directing
the industry to more methodical approach for software development with
MDA, UML, CORBA etc.
It has a vision, for middleware solutions.
> > More so because it affects
> > corba community. And middlewares vision of portability and longevity of
> > software systems.
>
> It also affect web service, MOM applications and many other communities
> as well.
Good, this will force then to work in more co-ordiantion with OMG.
Shashank D. Jha
>> What about generated from standard corba interfaces??
> If you feel relevant. You can answer four "no-brainer" questions I
> listed in previous post, let me know how POSIX addressed them.
>
Doesnt matter to me, whether POSIX addresses that or not.
What matters is we need to make/ maintain an unnecessary if-else in
source code of application layer as well ORB codes.
Or provide some configuration to manage something that is completely
avoidable.
> By "CORBA specific", I mean somehow it has tie to CORBA architecture
> and is specially designed based on CORBA, and likely not be interested
> outside. For instance, OS API interfaces are defined with IDL.
Why this has to be of interest outside CORBA?
you mean to suggest when Web Services standars are written, or for the
matter spec for C++ is changed they take care of not upsetting IDL to
C++ mapping?? Or provide suggestions for new IDL to C++ mappings?
Let at least be OS API be standardized. at the minimum. And let both
application programmer and ORB provider both implement that for same
software !! albeit in diff layers!! for same software system.
> I could not see why this needs to be CORBA specific either! That is
> why, from very beginning, I believe this should not be a task for OMG.
> With the same specification, why not submit it to Opengroup/ISO/IEEE or
> ANSI to get more wide support and acceptance? If all standardization
> groups just try unify OS portable layer inside their own backyard, we
> would endup with an more non-unified world.
OMG should take initiative. And it may go to Opengroup/ISO/IEEE if it
is industry wide relevant.
> Why have to exposing those functionalities through CORBa/orb? Our OS
> portable layer and many others do not need CORBA/ORB to expose OS
> system functions.
Correct. I am not insistent that it should be part of core corba. but
it has to be shipped with CORBA. May b as a standard user library to be
provided by CORBA. Or as a part of programming model specification ..or
whatever, this can be more clearified with time. Depending on corba
vendors and user communities experience.
> I have repeat many times, having an implementation sufficient for
> implementing an ORB or supporting some applications is easy. Generize
> it is non-trivial! For more discussions, see my previous post(s).
It not trivial I assume. But definitely less complex that CORBA, CCM,
UML, MDA?
> Besides, writing a specification and having it stamped by OMG without
> caring its vendor supportness and user acceptance, and only use it as
> wolf-ticket, sometime, is also easy. But writing a technically good
> specification, and having it widely accepted and supported requires
> much more indepth/forward thinking and responsible attitude!
Let me know which user wont like this?
And who among major vendors dont already have this layer in their CORBA
implementation. Offcourse its difficult to know ..but just curious.
CCM, CORBA, UML etc. are well written spec I believe.
regards,
------------
Shashank D. Jha
iCMG
e-mail : shas...@icmgworld.com
Phone : +91-80-98451 87302
Shashank D. Jha
> 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!
Stubs and skeletons generated from CORBA are of least concern for an
application programmer. Except other than that we need to include
headers of the same in client/ server source code.
These source code has to be deployable on the middleware. But has to be
changed for each implementation of middleware..read CORBA.
Why I cant just right in my client/ server file something like
"interface_file_name.h" and all the underlying implementations
understand this? So that i dont need to change name, or add if-else,
maintain make file configuration for the same?
Doesnt just standardizing name, simplifies the things?
What about standard corba related headers?
> If IETF, TMF, and especially W3C also doing the samething and saying
> "we are as good as a place as any", do you agree?
Yeah. there concerns are different.
At least soemone attends to problem we face. And they attend to
problems that their community faces.
Better than no solution right?
> 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.
You mean to suggest it is more complex that CORBA spec. including CORBA
Real Time, AMI, FT etc ?
And that they are not generic?
> 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:
how much relevant is that issue with these middleware?
Problem is more of conern in CORBA than in.NET or J2EE, for obvious
reasons.
> * 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.
I believe in this case, vendors would have already implemented this.
Let them propose to OMG or let the vendors themselves come out with
common model, at least.
> * At least define your system interfaces using IDL, instead of language
> specific;
Or use ACE Framework for the same.
Ke Jin
> Ke Jin wrote:
> > This is not a issue specific to CORBA, it is common to many non-CORBA
> > applications as well, such as application using webservice as
> > middleware infrastructure. Therefore, this portable layer shouldn't be
> > designed to be CORBA specific, and should be standardized by the right
> > organization.
>
> I agree. but that doesnt means it should not be resolved for CORBA.
>
Saying "it should be standardized by the right organization" doesn't
imply it would not be resolved for CORBA.
>
> > If all organizations, OMG/W3C/IETF/TMF/ITU/3GPP/... just address this
> > common issue independently within their own backyards, we would endup
> > with a more non-standardized world.
>
> Who will/ should take initiative?
>
> CORBA is the most visionary and capable architecture for middleware
> solution.
> If languages are constraints to it, it should go ahead and write/
> suggest/ mediate among all standard bodies to come together to make it
> possible for its community.
>
As one said in this thread, OMG should reinvent-the-wheel, because
other middleware communities have already standardized their OS API
layer. Regardless his statement is true or false, it reflects his (and
of many other people like you) thinking on this issue: OMG should NOT
join with other communities on standardizing this API, especially when
they already initiated and done the work ahead of OMG.
If OMG members think this way, how would other communities response on
OMG's behind them initiative call? Why they should support a standard
which is later than theirs and from an organization with minor
influence on this area?
> > It is not relevant to what are we discussed here. Also, the suggested
> > attempt of standardizing C++ OS portable layer is not compareable to
> > what OMG did for MDA.
>
> I agree its not comparable,an I dont intend to compare it either. But
> to have an consistent approach to realize MDA vision we need this.
>
> In MDA when we generate PIM to PSM code, PSM is CORBA right? or Orbix,
> visibroker , OminiORB etc..?
>
> How do you realize this unless we have consistent programming platform/
> environment offered by CORBA?
>
> And if this has to be consistently automated, we need abstraction of os
> layer to be provided by middleware, which will be used for PIM to PSM
> translation.
>
> What I meant to suggest that, even if all other oranizations develop
> their own standards, assuming they refused to work in co-ordination
> with OMG for the same, OMG can always extend MDA's PSM model to
> generate PSM model specific to execution environment.
>
> OMG has to realize its MDA vision. And so it must take this initiative.
>
What you have talked about, are simply vaporware ideas. You should
present the solution before saying you will have the solution when it
come to the time we need it. As I comment to Doug's post, if you really
want to do a serious job, pls to it topdown, starting from an
architecture/hierarchy design. Instead of bottomup, from defining one
needed node/leaf of the architecture/hierarchy without knowing
where/how/whether it would fit in the final system. This is just like
you were building a tower on a sand beach, without an architecture
design and without a base, and saying you would have them available
when the tower reach high enough.
> > I would also suggest them standardize it in a right organization,
> > likely to be ANSI/ISO, if it is C++ language oriented (similar to STL),
> > or Opengroup it is more system oriented (similar to socket and pthread,
> > but in C++ form).On C++ and portable system layer, Opengroup/ISO/IEEE and
> > ANSI are definitly better than OMG, unless this layer is defined with IDL.
>
> Issue is not with any language. Nothing wrong with C++ as such.
> ANSI/ISO and other organizations dont have vision to enable middleware
> software systemes development, distribution, packaging, deployment etc.
> that are portable across various middlewares.
>
Pls don't play red herring. First, no body ever compliant about C++ in
this thread! It is either your misinterpretation, or your
misunderstanding. Second, what we talked about is only a portable OS
API standard. It is orthogonal to other issues. Third, who said
ANSI/ISO/IEEE/Opengroup have less vision on portability issues? They
have engaged on this much longer than OMG does!
> So, initiative has to come from OMG.
>
> > OMG has no history, influence, credit to play such a generic role beyond
> > CORBA/MDA scope. Pls be real, unless your only motivation is to have
> > your implementation stamped by OMG and use it as a wolf-ticket!
>
> Doesnt matters much. As it has demonstrated successfully in directing
> the industry to more methodical approach for software development with
> MDA, UML, CORBA etc.
>
> It has a vision, for middleware solutions.
An portable OS API is not a middleware. Otherwise, socket/thread, STL,
MFC, JFC, etc.... can all be called middleware!
>
> > > More so because it affects
> > > corba community. And middlewares vision of portability and longevity of
> > > software systems.
> >
> > It also affect web service, MOM applications and many other communities
> > as well.
>
> Good, this will force then to work in more co-ordiantion with OMG.
>
Pls be realistic, unless you are talking about vaporware.
Regards,
Ke
Ke Jin
> Ke Jin wrote:
>
> >> What about generated from standard corba interfaces??
>
> > If you feel relevant. You can answer four "no-brainer" questions I
> > listed in previous post, let me know how POSIX addressed them.
> >
>
> Doesnt matter to me, whether POSIX addresses that or not.
>
Which means, you don't know the answer!
> What matters is we need to make/ maintain an unnecessary if-else in
> source code of application layer as well ORB codes.
>
> Or provide some configuration to manage something that is completely
> avoidable.
Then, give me your answer! Pls explicitly answer my four questions
(actually, at least one of them has already answered by OMG
specification)
>
>
> > By "CORBA specific", I mean somehow it has tie to CORBA architecture
> > and is specially designed based on CORBA, and likely not be interested
> > outside. For instance, OS API interfaces are defined with IDL.
>
> Why this has to be of interest outside CORBA?
> you mean to suggest when Web Services standars are written, or for the
> matter spec for C++ is changed they take care of not upsetting IDL to
> C++ mapping?? Or provide suggestions for new IDL to C++ mappings?
>
First, I was just answering you the question of what is the literal
definition of "CORBA specific". If you really want to understand
something, instead of simply proving you were right, don't try to
redirect the discussion to irrelevant subject!
> Let at least be OS API be standardized. at the minimum. And let both
> application programmer and ORB provider both implement that for same
> software !! albeit in diff layers!! for same software system.
>
You are just iterate the original question. Therefore, I give you my
original reply on this:
1. OMG is not a right organization to specify this, especially if your
OS API definition isn't CORBA specific (e.g. defined by IDL). If really
want, you should go to Opengroup, ISO, IEEE or try ANSI.
2. It is easy to define and construct an ad hoc portable OS API
library, sufficient for a ORB or certain applications, but it is
non-trivial at all to generalize this into a standard!
3. It damages CORBA.
> > I could not see why this needs to be CORBA specific either! That is
> > why, from very beginning, I believe this should not be a task for OMG.
> > With the same specification, why not submit it to Opengroup/ISO/IEEE or
> > ANSI to get more wide support and acceptance? If all standardization
> > groups just try unify OS portable layer inside their own backyard, we
> > would endup with an more non-unified world.
>
> OMG should take initiative. And it may go to Opengroup/ISO/IEEE if it
> is industry wide relevant.
>
This is just worthless statement, no guarantee at all. Especially, you
intentionally not start the initiative in the right organization, and
saying we might have it corrected later on.
> > Why have to exposing those functionalities through CORBa/orb? Our OS
> > portable layer and many others do not need CORBA/ORB to expose OS
> > system functions.
>
> Correct. I am not insistent that it should be part of core corba. but
> it has to be shipped with CORBA. May b as a standard user library to be
> provided by CORBA. Or as a part of programming model specification ..or
> whatever, this can be more clearified with time. Depending on corba
> vendors and user communities experience.
>
Why it can't be shipped with other middleware, for instance WebService.
Just like later on we extend this to cover database access, middleware
access, as well as structure files (e.g. B+ tree), why this have to be
shipped with CORBA, but not by itself or with other middleware or
applications?
>
> > I have repeat many times, having an implementation sufficient for
> > implementing an ORB or supporting some applications is easy. Generize
> > it is non-trivial! For more discussions, see my previous post(s).
>
> It not trivial I assume. But definitely less complex that CORBA, CCM,
> UML, MDA?
>
The challenges are different, and not really comparable.
> > Besides, writing a specification and having it stamped by OMG without
> > caring its vendor supportness and user acceptance, and only use it as
> > wolf-ticket, sometime, is also easy. But writing a technically good
> > specification, and having it widely accepted and supported requires
> > much more indepth/forward thinking and responsible attitude!
>
> Let me know which user wont like this?
>
All used would not like a wolf-ticket. Let me know which user like it?
> And who among major vendors dont already have this layer in their CORBA
> implementation. Offcourse its difficult to know ..but just curious.
You are trying to change the topic and try to flame again and again.
Here is my ansewer, iterate here one more time:
I am discussing HOW and WHRER the suggested portable API should be
standardized, instead of whether an ad hoc OS API for a ORB could be
implemented. Therefore, don't try to imply that, the one with negative
opinion couldn't have an OS abstraction for his/her ORB/applications.
In fact, as I said in another reply of this thread, that:
* it is easy to define/construct an ad hoc portable OS API library
sufficient for a ORB or few applications.
* And this kind of thing have been implemented by many people, many
times, in many commercial products and student projects, independently
and repeatly!! If you believe this is some challenge, it is your
problem.
* it is non-trivial at all to generalize these an ad hoc implementation
into a standardized specification, especially at low level!
>
> CCM, CORBA, UML etc. are well written spec I believe.
Irrelevant!
Regards,
Ke
Ke Jin
> "Ke Jin" <ke...@borland.com> wrote in message
>
> > 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!
>
> Stubs and skeletons generated from CORBA are of least concern for an
> application programmer. Except other than that we need to include
> headers of the same in client/ server source code.
>
> These source code has to be deployable on the middleware. But has to be
> changed for each implementation of middleware..read CORBA.
>
> Why I cant just right in my client/ server file something like
> "interface_file_name.h" and all the underlying implementations
> understand this?
Why? You should read the four "no-brainer" questions on this issue and
anser them. By the way, I am repeating the fifth time, I was only
"guessing" why the original folks didn't standardize this.
> So that i dont need to change name, or add if-else,
> maintain make file configuration for the same?
>
> Doesnt just standardizing name, simplifies the things?
>
Answer those four questions.
> What about standard corba related headers?
>
> > If IETF, TMF, and especially W3C also doing the samething and saying
> > "we are as good as a place as any", do you agree?
>
> Yeah. there concerns are different.
> At least soemone attends to problem we face. And they attend to
> problems that their community faces.
>
> Better than no solution right?
In some cases, quick thought near-sight "solutions" can make things
worse!
>
> > 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.
>
> You mean to suggest it is more complex that CORBA spec. including CORBA
> Real Time, AMI, FT etc ?
> And that they are not generic?
Irrelevant to the discussion. Ignored!
>
> > 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:
>
> how much relevant is that issue with these middleware?
>
I am not suggesting the issue is relevant to these middlewaer, but
suggest it is also relevant to applications using those middlewares! I
don't think you were really misunderstanding my real words, you just
try to divert the discussion.
> Problem is more of conern in CORBA than in.NET or J2EE, for obvious
> reasons.
>
Irrelevant to the discussion. I am not compare CORBA to .NET or J2EE. I
was just asking Doug which middlewares he meant having it standardized
already? J2EE and .NET are just two examples I try to excluded from his
list. Again, you try to diverting the discussion.
> > * 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.
>
> I believe in this case, vendors would have already implemented this.
> Let them propose to OMG or let the vendors themselves come out with
> common model, at least.
Again, ad hoc implemention sufficient for a ORB and few applications is
easy. Generalize this into a standardized specification is non-trivial
at all.
>
> > * At least define your system interfaces using IDL, instead of language
> > specific;
>
> Or use ACE Framework for the same.
>
Pls read the CORBa architecture specification and CORBA RFP
requirements first.
Regards,
Ke
Shashank D. Jha
Ke Jin wrote:
> Shashank D. Jha wrote:
> > Ke Jin wrote:
> > > This is not a issue specific to CORBA, it is common to many non-CORBA
> > > applications as well, such as application using webservice as
> > > middleware infrastructure. Therefore, this portable layer shouldn't be
> > > designed to be CORBA specific, and should be standardized by the right
> > > organization.
> >
> > I agree. but that doesnt means it should not be resolved for CORBA.
> >
>
> Saying "it should be standardized by the right organization" doesn't
> imply it would not be resolved for CORBA.
>
Let me know whey they have not already made available well publicised
standard os layer API to C++ programmer, which is completely portable.
> As one said in this thread, OMG should reinvent-the-wheel, because
> other middleware communities have already standardized their OS API
> layer. Regardless his statement is true or false, it reflects his (and
> of many other people like you) thinking on this issue: OMG should NOT
> join with other communities on standardizing this API, especially when
> they already initiated and done the work ahead of OMG.
I am not suggesting to re-invent the wheel. Either you are mis-reading
my quotes or mis-understanding.
What am suggesting is OMG should take initiative. It can always work
with other , may be more appropriate organization to make this
available to CORBA programmers at least or to start with.
> If OMG members think this way, how would other communities response on
> OMG's behind them initiative call? Why they should support a standard
> which is later than theirs and from an organization with minor
> influence on this area?
Which standard? Standard C++ os layer API? Is it available?
> > What I meant to suggest that, even if all other oranizations develop
> > their own standards, assuming they refused to work in co-ordination
> > with OMG for the same, OMG can always extend MDA's PSM model to
> > generate PSM model specific to execution environment.
> >
> > OMG has to realize its MDA vision. And so it must take this initiative.
> >
>
> What you have talked about, are simply vaporware ideas. You should
> present the solution before saying you will have the solution when it
> come to the time we need it.
If you think that "Middleware is key enabler for vision of MDA to be
realized" is vaporware!! then am sorry to say, you are not following
MDA spec closely.
I already suggested to be start with minimum that can be made is make
corba systems completely portable. And for that to start with lets have
uniform programming model.
> As I comment to Doug's post, if you really
> want to do a serious job, pls to it topdown, starting from an
> architecture/hierarchy design. Instead of bottomup, from defining one
> needed node/leaf of the architecture/hierarchy without knowing
> where/how/whether it would fit in the final system. This is just like
> you were building a tower on a sand beach, without an architecture
> design and without a base, and saying you would have them available
> when the tower reach high enough.
I think first idea should be presented, should be agreed upon for
common consensus.
And already suggested in the thread that its doable.
If people in this forum agree, then we may take to higher level by
working on its architecture.
> > > I would also suggest them standardize it in a right organization,
> > > likely to be ANSI/ISO, if it is C++ language oriented (similar to STL),
> > > or Opengroup it is more system oriented (similar to socket and pthread,
> > > but in C++ form).On C++ and portable system layer, Opengroup/ISO/IEEE and
> > > ANSI are definitly better than OMG, unless this layer is defined with IDL.
May be ANSI is better. Why they are hiding the standard os API layer?
> > Issue is not with any language. Nothing wrong with C++ as such.
> > ANSI/ISO and other organizations dont have vision to enable middleware
> > software systemes development, distribution, packaging, deployment etc.
> > that are portable across various middlewares.
> >
>
> Pls don't play red herring. First, no body ever compliant about C++ in
> this thread! It is either your misinterpretation, or your
> misunderstanding. Second, what we talked about is only a portable OS
> API standard. It is orthogonal to other issues. Third, who said
> ANSI/ISO/IEEE/Opengroup have less vision on portability issues? They
> have engaged on this much longer than OMG does!
Then why do we still dont have any standard os layer API, if they were
so ahead?
Thats what I said earlier, nothing wrong with C++. CORBA programming
model needs to be extended to enable completely portable software
systems.
> >
> > Good, this will force then to work in more co-ordiantion with OMG.
> >
>
> Pls be realistic, unless you are talking about vaporware.
So you want OMG to work with them? Doesnt matter. In either case CORBA
programmers will have soemthing better.
Shashank D. Jha
> > Doesnt matter to me, whether POSIX addresses that or not.
> >
>
> Which means, you don't know the answer!
If you wanna assume. I wont stop you.
> > What matters is we need to make/ maintain an unnecessary if-else in
> > source code of application layer as well ORB codes.
> >
> > Or provide some configuration to manage something that is completely
> > avoidable.
>
> Then, give me your answer! Pls explicitly answer my four questions
> (actually, at least one of them has already answered by OMG
> specification)
Which one you are referrig to? Please mention here all your questions.
> > > By "CORBA specific", I mean somehow it has tie to CORBA architecture
> >
> > Why this has to be of interest outside CORBA?
>
> First, I was just answering you the question of what is the literal
> definition of "CORBA specific". If you really want to understand
> something, instead of simply proving you were right, don't try to
> redirect the discussion to irrelevant subject!
Either you are not getitng my point. Or intentionally trying to evade
it, just to prove your point.
What I am maintaining is that today CORBA and C++ standards are
evolving independently.
Any development in CORBA doesnt directly affects C++ standards/
programmers. But C++ standards affect CORBA. It requires to modify
(possibly) IDL to C++ mapping etc as well as may be servant
implementation.
Problem is in CORBA domain. Because if we use currently corba
programming model, it doesnt provides portability of language specifics
over underlying systems. While other more popular middlewars because of
their simple programming model, are easier to develop.
So CORBA needs to provide solution for this.
> 3. It damages CORBA.
Because it will make development in CORBA simpler.
> > > I could not see why this needs to be CORBA specific either! That is
> > > why, from very beginning, I believe this should not be a task for OMG.
> > > With the same specification, why not submit it to Opengroup/ISO/IEEE or
> > > ANSI to get more wide support and acceptance? If all standardization
> > > groups just try unify OS portable layer inside their own backyard, we
> > > would endup with an more non-unified world.
> >
> > OMG should take initiative. And it may go to Opengroup/ISO/IEEE if it
> > is industry wide relevant.
> >
>
> This is just worthless statement, no guarantee at all. Especially, you
> intentionally not start the initiative in the right organization, and
> saying we might have it corrected later on.
CORBA as a middleware should provide system portability. This is my
view. And so it must take initiative to enable the same.
If you dont agree, can say so. Doesnt means you are right.
And no point in continuing un-ending repeating the same things.
> > > Why have to exposing those functionalities through CORBa/orb? Our OS
> > > portable layer and many others do not need CORBA/ORB to expose OS
> > Correct. I am not insistent that it should be part of core corba. but
> > it has to be shipped with CORBA. May b as a standard user library to be
> Why it can't be shipped with other middleware, for instance WebService.
> Just like later on we extend this to cover database access, middleware
> access, as well as structure files (e.g. B+ tree), why this have to be
> shipped with CORBA, but not by itself or with other middleware or
> applications?
I don want to answer WHY?
My point is we use CORBA middleware. And my view is it should provide
standard portable os API layer. So why should I go to Web Services,
ANSI or no.s of other organizations that you have listed?
How does CORBA acquires and provides to its users , whether borrows
from ANSI standards, or asks IEEE to develop that or whatever is of
later concern.
First concern is the let their be a consensus among users and vendors
for the same.
> > > I have repeat many times, having an implementation sufficient for
> > > implementing an ORB or supporting some applications is easy. Generize
> > > it is non-trivial! For more discussions, see my previous post(s).
> > > Besides, writing a specification and having it stamped by OMG without
> > > caring its vendor supportness and user acceptance, and only use it as
> > > wolf-ticket, sometime, is also easy. But writing a technically good
> > > specification, and having it widely accepted and supported requires
> > > much more indepth/forward thinking and responsible attitude!
> >
> > Let me know which user wont like this?
> >
>
> All used would not like a wolf-ticket. Let me know which user like it?
You mean to suggest that users and vendors love to handle this in their
implementation?
And if some standard for the same is made available to them they will
discard it because they dont want it?
> * it is easy to define/construct an ad hoc portable OS API library
> sufficient for a ORB or few applications.
>
> * And this kind of thing have been implemented by many people, many
> times, in many commercial products and student projects, independently
> and repeatly!! If you believe this is some challenge, it is your
> problem.
>
> * it is non-trivial at all to generalize these an ad hoc implementation
> into a standardized specification, especially at low level!
>
> >
> > CCM, CORBA, UML etc. are well written spec I believe.
>
> Irrelevant!
This is in response to your abov star (*) marked points. If you think
other specifications written by OMG are not well written and its not
competent org? ?
Shashank D. Jha
> > Why I cant just right in my client/ server file something like
> > "interface_file_name.h" and all the underlying implementations
> > understand this?
>
> Why? You should read the four "no-brainer" questions on this issue and
> anser them. By the way, I am repeating the fifth time, I was only
> "guessing" why the original folks didn't standardize this.
So you agree they should have been standardized?
> > So that i dont need to change name, or add if-else,
> > maintain make file configuration for the same?
> >
> > Doesnt just standardizing name, simplifies the things?
> >
>
> Answer those four questions.
How is that relevent?
> > What about standard corba related headers?
> >
> > > If IETF, TMF, and especially W3C also doing the samething and saying
> > > "we are as good as a place as any", do you agree?
> >
> > Yeah. there concerns are different.
> > At least soemone attends to problem we face. And they attend to
> > problems that their community faces.
> >
> > Better than no solution right?
>
> In some cases, quick thought near-sight "solutions" can make things
> worse!
I agree. But who suggested to rush into standardizing things?
> > You mean to suggest it is more complex that CORBA spec. including CORBA
> > Real Time, AMI, FT etc ?
> > And that they are not generic?
>
> Irrelevant to the discussion. Ignored!
This was in response to
> > > 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.
As if to suggest the other specifications by OMG doesnt meets these
criterias.
> > > 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:
> >
> > how much relevant is that issue with these middleware?
> >
>
> Irrelevant to the discussion. I am not compare CORBA to .NET or J2EE. I
> was just asking Doug which middlewares he meant having it standardized
> already? J2EE and .NET are just two examples I try to excluded from his
> list. Again, you try to diverting the discussion.
So which specification provides "ports" to a component? in their
component model?
Merely if something is not available if in some other middlewares
doesn't discards of its usefulness here?? Dont find these logics
relevent.
Issue is will that make things simpler? or not?
> Again, ad hoc implemention sufficient for a ORB and few applications is
> easy. Generalize this into a standardized specification is non-trivial
> at all.
No one is suggesting ad-hoc implementaiton of anything. Its always bad/
worse.
To make things more useful can you mention the issues because of which
these API's cannot be generalized and not applicable to generic
applications?
> Pls read the CORBa architecture specification and CORBA RFP
> requirements first.
To understand what?
Am not suggesting something which already is there? Am suggesting that
will at least make things bit simpler in CORBA.
regards,
Ke Jin
> Ke Jin wrote:
> > Shashank D. Jha wrote:
> > > Ke Jin wrote:
> > > > This is not a issue specific to CORBA, it is common to many non-CORBA
> > > > applications as well, such as application using webservice as
> > > > middleware infrastructure. Therefore, this portable layer shouldn't be
> > > > designed to be CORBA specific, and should be standardized by the right
> > > > organization.
> > >
> > > I agree. but that doesnt means it should not be resolved for CORBA.
> > >
> >
> > Saying "it should be standardized by the right organization" doesn't
> > imply it would not be resolved for CORBA.
> >
>
> Let me know whey they have not already made available well publicised
> standard os layer API to C++ programmer, which is completely portable.
Again, you are diverting the discussion. Read above q&a, you first try
to say "not standardizing in OMG == not resolved for CORBA
application". Then, after my reply of "it doesn't imply it would not be
resolved for CORBA", you changed the question above to "why they have
not already made available". This is totally different question. The
original discussion above was where we should do it (if we really need
to), which certainly agreed that it hasn't been done yet. The answer
dosen't imply right organization means an organization has a solution
ready!!
>
>
> > As one said in this thread, OMG should reinvent-the-wheel, because
> > other middleware communities have already standardized their OS API
> > layer. Regardless his statement is true or false, it reflects his (and
> > of many other people like you) thinking on this issue: OMG should NOT
> > join with other communities on standardizing this API, especially when
> > they already initiated and done the work ahead of OMG.
>
> I am not suggesting to re-invent the wheel. Either you are mis-reading
> my quotes or mis-understanding.
>
> What am suggesting is OMG should take initiative. It can always work
> with other , may be more appropriate organization to make this
> available to CORBA programmers at least or to start with.
OMG member can take initiative, but should lobby in the right
organization, unless it is CORBA specific. Reinvent-the-wheel inside
OMG with the intention of competing with other available initiatives
(as themselves said) would not be possible to get support and
acceptance outside OMG, and doubtfully even inside CORBA community. The
result would be a wolf-ticket.
>
> > If OMG members think this way, how would other communities response on
> > OMG's behind them initiative call? Why they should support a standard
> > which is later than theirs and from an organization with minor
> > influence on this area?
>
> Which standard? Standard C++ os layer API? Is it available?
First, you should not ask me, but the one who made the original
statement of "OMG should standardize this, b/c other middlewares
standardized this already". Second, as I said, regardless his statement
was false or true, it reflect a thinking, of to have our own standard,
rather than join with others. With this thinking, your promise of OMG
will join with other or other will join OMG would be unlikely. Again,
don't try to divert the discussion.
>
> > > What I meant to suggest that, even if all other oranizations develop
> > > their own standards, assuming they refused to work in co-ordination
> > > with OMG for the same, OMG can always extend MDA's PSM model to
> > > generate PSM model specific to execution environment.
> > >
> > > OMG has to realize its MDA vision. And so it must take this initiative.
> > >
> >
> > What you have talked about, are simply vaporware ideas. You should
> > present the solution before saying you will have the solution when it
> > come to the time we need it.
>
> If you think that "Middleware is key enabler for vision of MDA to be
> realized" is vaporware!! then am sorry to say, you are not following
> MDA spec closely.
You have a strawman logical fallacy! What I said was, your promises and
ideas of saying we could resolve all these issues with all these
technologies (including MDA) were vaporware ideas. This doesn't imply
MDA is vaporware!
>
> I already suggested to be start with minimum that can be made is make
> corba systems completely portable. And for that to start with lets have
> uniform programming model.
You should start topdown, having an architecture/hierarchy design.
Instead of start from bottomup, from a minimum function module under a
vaporware architecture, and don't know whether/how/where this function
module fit in the final architecture.
>
> > As I comment to Doug's post, if you really
> > want to do a serious job, pls to it topdown, starting from an
> > architecture/hierarchy design. Instead of bottomup, from defining one
> > needed node/leaf of the architecture/hierarchy without knowing
> > where/how/whether it would fit in the final system. This is just like
> > you were building a tower on a sand beach, without an architecture
> > design and without a base, and saying you would have them available
> > when the tower reach high enough.
>
> I think first idea should be presented, should be agreed upon for
> common consensus.
> And already suggested in the thread that its doable.
>
No. You didn't answer the key questions of:
1. how it fit in the CORBA architecture, without define this in IDL.
Are you suggesting local OS API call and remote object invocation
should use different programming model? Different management rules?
different parameter styles? ..., and OMG should define such an
abstraction for each needed language?
2. you didn't define how this portable OS API can be extended to cover
and harmonize with other abstractions such as database access , message
middleware access, STL, GUI, Web, email, structured file (B+ tree,
etc.), etc...
3. How you would address those requirements I listed in original reply
to Doug's post. Some of those reqirements are mutual excluded.
Simply saying it is doable has nothing more than its face value.
> If people in this forum agree, then we may take to higher level by
> working on its architecture.
>
First, it has to be agreed in OMG, by OMG member. Second, even if you
got a OMG stamp, it still needs to be supported by reasonable number of
vendors with reasonable coverage of functions, and accepted by majority
customers,
> > > > I would also suggest them standardize it in a right organization,
> > > > likely to be ANSI/ISO, if it is C++ language oriented (similar to STL),
> > > > or Opengroup it is more system oriented (similar to socket and pthread,
> > > > but in C++ form).On C++ and portable system layer, Opengroup/ISO/IEEE and
> > > > ANSI are definitly better than OMG, unless this layer is defined with IDL.
>
> May be ANSI is better. Why they are hiding the standard os API layer?
>
This is a good start thinking. You should think about why
Opengroup/ISO/IEEE slowed or even stopped their work on OS API
standardization? Why ANSI standardized STL but not pursures the
seemingly trivial OS API standardization?
A post in this claimed, a standardized OS API is something "not very
technically hard to do". This is definitly a short-sight statement
without a indepth thinking. Firstly, we should not assume OS API is
simply socket and thread. If we claim it is "OS API", rather than
"socket/thread API", it should include much more than socket and thread
alone. Second, even if we only limit ourselves to thread (and socket)
API, there are still many challenges on unifying different thread
models for generic applications, with minimum sacrifice on performance,
API simplicity, functionality, resource consumption, etc.. As said,
some requirement may even be mutual exclusive.
> > > Issue is not with any language. Nothing wrong with C++ as such.
> > > ANSI/ISO and other organizations dont have vision to enable middleware
> > > software systemes development, distribution, packaging, deployment etc.
> > > that are portable across various middlewares.
> > >
> >
> > Pls don't play red herring. First, no body ever compliant about C++ in
> > this thread! It is either your misinterpretation, or your
> > misunderstanding. Second, what we talked about is only a portable OS
> > API standard. It is orthogonal to other issues. Third, who said
> > ANSI/ISO/IEEE/Opengroup have less vision on portability issues? They
> > have engaged on this much longer than OMG does!
>
> Then why do we still dont have any standard os layer API, if they were
> so ahead?
Because it is not as trivial as you thought!
>
> Thats what I said earlier, nothing wrong with C++. CORBA programming
> model needs to be extended to enable completely portable software
> systems.
>
You start to iterate again, I have to iterate mine.
1. Nothing wrong with C++. But, if you define a C++ OS API layer, you
should go to a right organization, such as Opengroup/ISO/IEEE/ANSI,
etc.
2. If you defining it in OMG, esepcially trying to put it into CORBA
architecture, you should define it using IDL.
Regards,
Ke
Ke Jin
> "Ke Jin" <ke...@borland.com> wrote in message
>
> > > Doesnt matter to me, whether POSIX addresses that or not.
> > >
> >
> > Which means, you don't know the answer!
>
> If you wanna assume. I wont stop you.
Because, Doug claimed this issue is trivial and has been addressed by
POSIX. Therefore, it is natural to ask how POSIX can address this
issue? YOu neither can't answer my four questions, no care others'
solution, what else I can assume?
>
> > > What matters is we need to make/ maintain an unnecessary if-else in
> > > source code of application layer as well ORB codes.
> > >
> > > Or provide some configuration to manage something that is completely
> > > avoidable.
> >
> > Then, give me your answer! Pls explicitly answer my four questions
> > (actually, at least one of them has already answered by OMG
> > specification)
>
> Which one you are referrig to? Please mention here all your questions.
>
Read the thread before you jumped in.
>
> > > > By "CORBA specific", I mean somehow it has tie to CORBA architecture
>
> > >
> > > Why this has to be of interest outside CORBA?
>
> >
> > First, I was just answering you the question of what is the literal
> > definition of "CORBA specific". If you really want to understand
> > something, instead of simply proving you were right, don't try to
> > redirect the discussion to irrelevant subject!
>
> Either you are not getitng my point. Or intentionally trying to evade
> it, just to prove your point.
>
> What I am maintaining is that today CORBA and C++ standards are
> evolving independently.
>
> Any development in CORBA doesnt directly affects C++ standards/
> programmers. But C++ standards affect CORBA. It requires to modify
> (possibly) IDL to C++ mapping etc as well as may be servant
> implementation.
>
> Problem is in CORBA domain. Because if we use currently corba
> programming model, it doesnt provides portability of language specifics
> over underlying systems. While other more popular middlewars because of
> their simple programming model, are easier to develop.
>
> So CORBA needs to provide solution for this.
The problem is not merely in CORBA domain, the problem is not specific
and tie to CORBA either. Applications using other non-CORBA distributed
middlewares (such as WebService, message middleware, even RPC, etc.)
could encount exactly same problems. Therefore, generic problems should
be addressed at generic scope.
>
> > 3. It damages CORBA.
>
> Because it will make development in CORBA simpler.
>
Adding a C++ language specific and inconsistent (on programming style,
management rule, etc..) part into CORBA architecture will definitly
damages it, and COMPLEX it.
> > > > I could not see why this needs to be CORBA specific either! That is
> > > > why, from very beginning, I believe this should not be a task for OMG.
> > > > With the same specification, why not submit it to Opengroup/ISO/IEEE or
> > > > ANSI to get more wide support and acceptance? If all standardization
> > > > groups just try unify OS portable layer inside their own backyard, we
> > > > would endup with an more non-unified world.
> > >
> > > OMG should take initiative. And it may go to Opengroup/ISO/IEEE if it
> > > is industry wide relevant.
> > >
> >
> > This is just worthless statement, no guarantee at all. Especially, you
> > intentionally not start the initiative in the right organization, and
> > saying we might have it corrected later on.
>
> CORBA as a middleware should provide system portability. This is my
> view. And so it must take initiative to enable the same.
>
Pls think about if each middleware community defined its own C++
language, its own STL, its own database access CLI, etc.., standards,
what would be the case? This is called community proprietary solution.
It is designed, supported and used by this community alone, even if it
was to address a generic problem, which could be addressed at much
large scope. Third parties and developers, who have no tie to this
community, would have no interest to support and use this standard.
This would largely reduce the supportness and acceptance of this
"standard". It also prevents knowledge transferability across
application developers with different background. If a developer happen
need to use multiple middlewares, he/she has to learn multiple OS API
standards.
We are lucky today that or predecessor standardized C++/STL/CLI in
ANSI. They standardized major flavor socket and thread in merely two
major communities, instead of for each individual middleware community.
If they followed your suggestion here, you would have a nightmare today
to have a portable socket/thread API.
User definitly doesn't love to handle portability issue, it has
solution today, and your solution doesn't go far than what they have
today, but would cause CORBA's language independency and programming
model consistency.
>
> And if some standard for the same is made available to them they will
> discard it because they dont want it?
What users care is not merely a specification stamped by an standard
body and claimed to be standard. They care more on how this standard is
supported and accepted. If it only get one or few vendor support, only
support minimum functions from the standard, etc..
>
> > * it is easy to define/construct an ad hoc portable OS API library
> > sufficient for a ORB or few applications.
> >
> > * And this kind of thing have been implemented by many people, many
> > times, in many commercial products and student projects, independently
> > and repeatly!! If you believe this is some challenge, it is your
> > problem.
> >
> > * it is non-trivial at all to generalize these an ad hoc implementation
> > into a standardized specification, especially at low level!
> >
> > >
> > > CCM, CORBA, UML etc. are well written spec I believe.
> >
> > Irrelevant!
>
> This is in response to your abov star (*) marked points. If you think
> other specifications written by OMG are not well written and its not
> competent org? ?
The fact of those standards were well written have no relevance to my
original statement of (*). OMG did something right doesn't indicate
everything in an OMG member's proposal would be right. It also doesn't
imply it would be trivial to generalize an ad hoc socket/thread
implementation into a OS API standard. That is why, I simply said your
statement, is completely "irrelevant" to mine!
Regards,
Ke
Ke Jin
> "Ke Jin" <ke...@borland.com> wrote in message
>
> > > Why I cant just right in my client/ server file something like
> > > "interface_file_name.h" and all the underlying implementations
> > > understand this?
> >
> > Why? You should read the four "no-brainer" questions on this issue and
> > anser them. By the way, I am repeating the fifth time, I was only
> > "guessing" why the original folks didn't standardize this.
>
> So you agree they should have been standardized?
>
I never agree or disagree whethere this should be specified (I call it
unify/specify, to avoid confuse with OS API standardization debate).
First, I was just guessing why it was not specified in the original C++
language mapping. Second, I was just brainstorm where and what we
should have a second thought on unify generated head file name(s).
> > > So that i dont need to change name, or add if-else,
> > > maintain make file configuration for the same?
> > >
> > > Doesnt just standardizing name, simplifies the things?
> > >
> >
> > Answer those four questions.
>
> How is that relevent?
Because your suggested solution, snipped from your current post,
immedately violates some requirements listed in my questions.
>
> > > What about standard corba related headers?
> > >
> > > > If IETF, TMF, and especially W3C also doing the samething and saying
> > > > "we are as good as a place as any", do you agree?
> > >
> > > Yeah. there concerns are different.
> > > At least soemone attends to problem we face. And they attend to
> > > problems that their community faces.
> > >
> > > Better than no solution right?
> >
> > In some cases, quick thought near-sight "solutions" can make things
> > worse!
>
> I agree. But who suggested to rush into standardizing things?
>
Not me.
>
> > > You mean to suggest it is more complex that CORBA spec. including CORBA
> > > Real Time, AMI, FT etc ?
> > > And that they are not generic?
> >
> > Irrelevant to the discussion. Ignored!
>
> This was in response to
> > > > 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.
When I saying "it is non-trivial", I was just trying to point out it is
not as trivial as what most people thought. One writer in this thread
said previously, "it is not hard to do technically" (I guess it is just
b/c he did it easily for his ORB, and he only covers part of
socket/thread functions in his API). Also, you have been repeatly
trying to indicate I don't have an implemetation. B/c you thought if I
had an implemetation, I would feel it is easy to do and would support
we standardize it in OMG.
As I have repeated many times, it is not as trivial as that writer and
you thought, because:
1. OS API is more than merely socket/thread API.
2. Implementing an ad hoc portable socket/thread API for a ORB or few
applications is easy, generializing this into a standardized
specification involve more issues (e.g. how to balance and trade-off
mutual exclusive requirements).
3. etc..
>
> As if to suggest the other specifications by OMG doesnt meets these
> criterias.
This is your strawman fallacy again.
>
> > > > 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:
> > >
> > > how much relevant is that issue with these middleware?
> > >
> >
> > Irrelevant to the discussion. I am not compare CORBA to .NET or J2EE. I
> > was just asking Doug which middlewares he meant having it standardized
> > already? J2EE and .NET are just two examples I try to excluded from his
> > list. Again, you try to diverting the discussion.
>
> So which specification provides "ports" to a component? in their
> component model?
You have a "burden of proof" fallacy here. It was my question, you
either answer my question, or wait the answer from the one I was
asking.
>
> Merely if something is not available if in some other middlewares
> doesn't discards of its usefulness here?? Dont find these logics
> relevent.
Again, this is a strawman fallacy.
>
> Issue is will that make things simpler? or not?
>
If you can have it standardized, widely supported, accepted and
consistent with existing architecture. Otherwise, better to stay where
you are and think about what should be right solution instead of jump
forward.
> > Again, ad hoc implemention sufficient for a ORB and few applications is
> > easy. Generalize this into a standardized specification is non-trivial
> > at all.
>
> No one is suggesting ad-hoc implementaiton of anything. Its always bad/
> worse.
I never say anyone suggest ad hoc implementation. What I said was, many
people have wrong assumption of standardizing a specification
generalized from their experience of constructing/using an ad hoc
implementation is not hard to do technically.
>
> To make things more useful can you mention the issues because of which
> these API's cannot be generalized and not applicable to generic
> applications?
>
"Not easy to be generialized" is more than "can not be generalized
syntactically or semantically". A bad design would be simply include
common set of functions of different OSs. Another bad design would be
simply an flat aggregate of all OS functions from different OSs. These
are two easy to spot bad designs, as a specification be able to claim
itself OS API. Java is one such bad example, it couldn't even get
process id, send a signal to another specified process, get process
(and its child) CPU consumption (user and system), etc.., without
relying on native code. Just get a POSIX system call manual and Win32
System API manual, do a comparsion, see how would you unify them
without arriving above bad designs.
Besides, in real case, it is more subtle than syntactic and semantic
unifications across OSs. The issues, requirements this standard OS
API's designers facing and need to trade-off are multi-dimensional,
some of them are mutual exclusive.
> > Pls read the CORBa architecture specification and CORBA RFP
> > requirements first.
>
> To understand what?
>
Again, you snipped your origianl statement I were commenting on.
> Am not suggesting something which already is there? Am suggesting that
> will at least make things bit simpler in CORBA.
YOu need think twice on the cost and consequence, not merely an OMG
stamped specification. If this specification doesn't get wide support,
acceptance and it introduces complexity and inconsistency into the
existing CORBA architecture, would you still feel it make things
simpler?
Regards,
Ke
Shashank D. Jha
have not already made available well publicised
> > standard os layer API to C++ programmer, which is completely portable.
>
> Again, you are diverting the discussion. Read above q&a, you first try
> to say "not standardizing in OMG == not resolved for CORBA
> application". Then, after my reply of "it doesn't imply it would not be
> resolved for CORBA", you changed the question above to "why they have
> not already made available".
I wanted to highlight that whatever may be reason, its not available to
CORBA programmers.
> This is totally different question. The
> original discussion above was where we should do it (if we really need
> to), which certainly agreed that it hasn't been done yet. The answer
> dosen't imply right organization means an organization has a solution
> ready!!
I still believe, portability of middleware application surpasses one
language issues. It has to be enabled for all the languages supported
today at least, by CORBA. So OMG is the right organization to begin
with for the same.
> OMG member can take initiative, but should lobby in the right
> organization, unless it is CORBA specific. Reinvent-the-wheel inside
> OMG with the intention of competing with other available initiatives
> (as themselves said) would not be possible to get support and
> acceptance outside OMG, and doubtfully even inside CORBA community. The
> result would be a wolf-ticket.
I think I have been maintaining that OMG should be the initiator,
however it gets it done, at the end CORBA community gets framework to
develop portable applications, while programming to CORBA.
You may be correct by proposing that this should be taken up with right
organization. I agree there. Where I differ is that this selection of
rightful organization be done by OMG, may be in consultation with user
and vendor community, considering overall affect it may bring for any
user in any technology.
> > Which standard? Standard C++ os layer API? Is it available?
>
> First, you should not ask me, but the one who made the original
> statement of "OMG should standardize this, b/c other middlewares
> standardized this already". Second, as I said, regardless his statement
> was false or true, it reflect a thinking, of to have our own standard,
> rather than join with others. With this thinking, your promise of OMG
> will join with other or other will join OMG would be unlikely. Again,
> don't try to divert the discussion.
But isnt it offers more organized, and higher level effort than each of
the language (supported by CORBA) community approaching their
organization for the standardization of the same, rather then it be
co-ordianted by OMG?
> You have a strawman logical fallacy! What I said was, your promises and
> ideas of saying we could resolve all these issues with all these
> technologies (including MDA) were vaporware ideas. This doesn't imply
> MDA is vaporware!
How MDA is realizable unless we resolve all these issues?
> > I already suggested to be start with minimum that can be made is make
> > corba systems completely portable. And for that to start with lets have
> > uniform programming model.
>
> You should start topdown, having an architecture/hierarchy design.
> Instead of start from bottomup, from a minimum function module under a
> vaporware architecture, and don't know whether/how/where this function
> module fit in the final architecture.
You seems to be more experienced in this regard to propose the initial
architecture.
I think it may fit into CORBA programming model. Which may be divide
into two layers, CORBA development programming and CORBA deployment
programming. This may fit into CORBA application development layer.
Well this is just initial idea. Dont make out much out of it unless you
also find some reasonableness into it.
> > I think first idea should be presented, should be agreed upon for
> > common consensus.
> > And already suggested in the thread that its doable.
> >
>
> No. You didn't answer the key questions of:
>
> 1. how it fit in the CORBA architecture, without define this in IDL.
Mentioned above.
> Are you suggesting local OS API call and remote object invocation
> should use different programming model? Different management rules?
> different parameter styles?
May be.
..., and OMG should define such an
> abstraction for each needed language?
yes. because this is needed for each of languages supported by CORBA.
So that's why to have uniformity in standardization of the same we need
OMG's effort.
> 2. you didn't define how this portable OS API can be extended to cover
> and harmonize with other abstractions such as database access , message
> middleware access, STL, GUI, Web, email, structured file (B+ tree,
> etc.), etc...
Sorry for not getting this completely.
data base access is already part of PSS spec I beleive.
As far as harmonizing access to message middleware, GUI, Web, email etc
are concerned they may be an issue. These issues exist indenpendent of
language or os layer portability and may be a issue for separate
concern.
> 3. How you would address those requirements I listed in original reply
> to Doug's post. Some of those reqirements are mutual excluded.
>
> Simply saying it is doable has nothing more than its face value.
But its done and freely available as part of ACE framework.
> > If people in this forum agree, then we may take to higher level by
> > working on its architecture.
> >
>
> First, it has to be agreed in OMG, by OMG member. Second, even if you
> got a OMG stamp, it still needs to be supported by reasonable number of
> vendors with reasonable coverage of functions, and accepted by majority
> customers,
I agree to all of you conerns. But my point is we need it and it will
resolve at least some (but significant) of the problems that industry
faces in terms of portability today.
> > > > > I would also suggest them standardize it in a right organization,
> > > > > likely to be ANSI/ISO, if it is C++ language oriented (similar to STL),
> > > > > or Opengroup it is more system oriented (similar to socket and pthread,
> > > > > but in C++ form).On C++ and portable system layer, Opengroup/ISO/IEEE and
> > > > > ANSI are definitly better than OMG, unless this layer is defined with IDL.
> >
> > May be ANSI is better. Why they are hiding the standard os API layer?
> >
>
> This is a good start thinking. You should think about why
> Opengroup/ISO/IEEE slowed or even stopped their work on OS API
> standardization? Why ANSI standardized STL but not pursures the
> seemingly trivial OS API standardization?
I am not aware of all the issues for the same. But if any consolidated
list of such issues exisits it may be listed here it will be helpful.
> A post in this claimed, a standardized OS API is something "not very
> technically hard to do". This is definitly a short-sight statement
> without a indepth thinking. Firstly, we should not assume OS API is
> simply socket and thread. If we claim it is "OS API", rather than
> "socket/thread API", it should include much more than socket and thread
> alone. Second, even if we only limit ourselves to thread (and socket)
> API, there are still many challenges on unifying different thread
> models for generic applications, with minimum sacrifice on performance,
> API simplicity, functionality, resource consumption, etc.. As said,
> some requirement may even be mutual exclusive.
But such a framework does exists. That allows you to write portable
applications.
> > Then why do we still dont have any standard os layer API, if they were
> > so ahead?
>
> Because it is not as trivial as you thought!
I agree here again. But my point is such a framework does exists that
allows us to write portable applications.
So that may be studied, analyzed, proposed, or better part of that may
be standardized.
regards