Netscape Communicator's ORB, How do we use it
E. Kideys
I recall several sources mentioning that the latest release of Netscape
Communicator has a Visibroker ORB included with it. I have downloaded
Communicator 4 and looked through the help and docs and as of yet could
not find much on this ORB or how to use it. Please help me with the
questions below.
* Where to find the documentation on how to use this ORB?
* In what ways can I benefit from this arrangement of having the ORB
within the Netscape browser?
* Is there a way to use this Visibroker without invoking Communicator?
In other words, if Visibroker is already included with the browser,
could I use it for designing CORBA applications without purchasing a
seperate licensing agreement with Inprise Visigenic?
* Is there any difference between the Visibroker included in
Communicator and the one we download from the Inprise site (and have to
pay for)?
* Where is the documentation?
If any one has had experience with using the ORB embedded in
Communicator please share it with us. Thank you.
Ed Kideys
Peter Norr
I believe the reason the ORB is included with Netscape is because if your
applet is developed using Visibroker, and a user is viewing it through
Netscape, the ORB does not have to be downloaded because it is already in
the browser!!
If your applet was developed using another vendors orb, then that vendors
orb needs to be downloaded to Netscape for the applet to run.
Pete
E. Kideys <e...@kideys.com> wrote in article
<365D2C2A...@kideys.com>...
Marc Laukien
Peter Norr wrote:
>
> Ed,
>
> I believe the reason the ORB is included with Netscape is because if your
> applet is developed using Visibroker, and a user is viewing it through
> Netscape, the ORB does not have to be downloaded because it is already in
> the browser!!
>
> If your applet was developed using another vendors orb, then that vendors
> orb needs to be downloaded to Netscape for the applet to run.
No, not necessarily. Thanks to portable stubs and skeletons, as defined
by the IDL-to-Java language mapping, you can use one vendor's runtime
with stubs/skels compiled with another vendor's ORB product. For
example, stubs/skels generated with ORBacus for Java (see
http://www.ooc.com/) work with the Netscape built-in ORB as long as you
don't use any ORBacus specific features.
Cheers,
Marc
> Pete
>
> E. Kideys <e...@kideys.com> wrote in article
> <365D2C2A...@kideys.com>...
> > Hi everyone,
> >
> > I recall several sources mentioning that the latest release of Netscape
> > Communicator has a Visibroker ORB included with it. I have downloaded
> > Communicator 4 and looked through the help and docs and as of yet could
> > not find much on this ORB or how to use it. Please help me with the
> > questions below.
> >
> > * Where to find the documentation on how to use this ORB?
> >
> > * In what ways can I benefit from this arrangement of having the ORB
> > within the Netscape browser?
> >
> > * Is there a way to use this Visibroker without invoking Communicator?
> > In other words, if Visibroker is already included with the browser,
> > could I use it for designing CORBA applications without purchasing a
> > seperate licensing agreement with Inprise Visigenic?
> >
> > * Is there any difference between the Visibroker included in
> > Communicator and the one we download from the Inprise site (and have to
> > pay for)?
> >
> > * Where is the documentation?
> >
> >
> > If any one has had experience with using the ORB embedded in
> > Communicator please share it with us. Thank you.
> >
> > Ed Kideys
> >
--
Marc Laukien Phone: (978) 439 9285 x 245
Object-Oriented Concepts, Inc. FAX: (978) 439 9286
44 Manning Rd. WWW: http://www.ooc.com
Billerica, MA 01821 E-Mail: mailto:m...@ooc.com
David Graff
interfaces to be defined while the implementation of those is opaquely defined. As
long as you are going to use the OMG defined interfaces and no vendor specific
interfaces you're fine.
That's one of the problems that I have right now. My company is using
Orbix/OrbixWeb from Iona. We're using their "opaque" type which is essentially an
implementation of the CORBA3 pass-by-value specification. The problem is that the
pass-by-value implementation is VERY Orbix specific so I'm hosed as far as using
the OMG mapping to cut down my need of extra classes...it'd be real nice if we
could get away with it but we're stuck...
Peter Norr wrote:
> Ed,
>
> I believe the reason the ORB is included with Netscape is because if your
> applet is developed using Visibroker, and a user is viewing it through
> Netscape, the ORB does not have to be downloaded because it is already in
> the browser!!
>
> If your applet was developed using another vendors orb, then that vendors
> orb needs to be downloaded to Netscape for the applet to run.
>
> Pete
>
> E. Kideys <e...@kideys.com> wrote in article
> <365D2C2A...@kideys.com>...
> > Hi everyone,
> >
> > I recall several sources mentioning that the latest release of Netscape
> > Communicator has a Visibroker ORB included with it. I have downloaded
> > Communicator 4 and looked through the help and docs and as of yet could
> > not find much on this ORB or how to use it. Please help me with the
> > questions below.
> >
> > * Where to find the documentation on how to use this ORB?
> >
> > * In what ways can I benefit from this arrangement of having the ORB
> > within the Netscape browser?
> >
> > * Is there a way to use this Visibroker without invoking Communicator?
> > In other words, if Visibroker is already included with the browser,
> > could I use it for designing CORBA applications without purchasing a
> > seperate licensing agreement with Inprise Visigenic?
> >
> > * Is there any difference between the Visibroker included in
> > Communicator and the one we download from the Inprise site (and have to
> > pay for)?
> >
> > * Where is the documentation?
> >
> >
> > If any one has had experience with using the ORB embedded in
> > Communicator please share it with us. Thank you.
> >
> > Ed Kideys
> >
--
****************************************************************
David J. Graff International CompuTex, Inc.
mailto:dgr...@computex.com Phone: (770) 953-1464
Direct: (770) 240-2289 Fax: (770) 953-1574
****************************************************************
Matthew Newhook
>Ed,
>
>I believe the reason the ORB is included with Netscape is because if your
>applet is developed using Visibroker, and a user is viewing it through
>Netscape, the ORB does not have to be downloaded because it is already in
>the browser!!
>
>If your applet was developed using another vendors orb, then that vendors
>orb needs to be downloaded to Netscape for the applet to run.
This isn't true. The stubs generated by our ORB ORBacus (and probably
other compliant Java ORB's) will run just fine with Netscape. This means
that you can develop your applets with ORBacus, and run them under
Netscape using the built-in ORB.
>Pete
Best Regards, Matthew
--
Matthew Newhook E-Mail: mailto:mat...@ooc.com
Software Designer WWW: http://www.ooc.com
Object Oriented Concepts, Inc. Phone: (978) 439 9285 x 246
danpel
I believe docs in inprise.com says something about this. But that is
just docs on how to use/activate its use in an applet (some applet param
tags).
> * In what ways can I benefit from this arrangement of having the ORB
> within the Netscape browser?
You do not have to download one when the applet is using corba.
> * Is there a way to use this Visibroker without invoking Communicator?
> In other words, if Visibroker is already included with the browser,
> could I use it for designing CORBA applications without purchasing a
> seperate licensing agreement with Inprise Visigenic?
You cannot use the visibroker orb in communicator for development. You
will need a lot of the development stuff, where e.g. an idl2java
compiler really is missing :-)
The orb in communicator is "only" the runtime (deployment only).
> * Is there any difference between the Visibroker included in
> Communicator and the one we download from the Inprise site (and have to
> pay for)?
Yep! No development.
> * Where is the documentation?
Try looking at inprise.com.
Thien Nguyen
>
> In article <01be1ce6$76f3d660$2b034f0c@peterscomputer>, Peter Norr wrote:
> >Ed,
> >
> >I believe the reason the ORB is included with Netscape is because if your
> >applet is developed using Visibroker, and a user is viewing it through
> >Netscape, the ORB does not have to be downloaded because it is already in
> >the browser!!
> >
> >If your applet was developed using another vendors orb, then that vendors
> >orb needs to be downloaded to Netscape for the applet to run.
>
> This isn't true. The stubs generated by our ORB ORBacus (and probably
> other compliant Java ORB's) will run just fine with Netscape. This means
> that you can develop your applets with ORBacus, and run them under
> Netscape using the built-in ORB.
>
This is a pleasant surprise. I was under the impression that I have to
include the vendor's orb (in my case ORBacus) along with the applet's
jar since Netscape's orb was not up to date.
I now stripped the orbs from the jar and also the applet's embedded
parameters:
<param name=org.omg.CORBA.ORBClass value=com.ooc.CORBA.ORB>
<param name=org.omg.CORBA.ORBSingletonClass
value=com.ooc.CORBA.ORBSingleton>
I ran the applet on Netscape 4.0.6 and 4.5, it seems to work fine
(though I have not tested it thoroughly). The nice thing is my jar
reduced from a hefty 800K down to 180K. The downside is now the applet
only works with Netscape and not IE. I guess I will have to have a
separate version of the applet for different type of browser.
Does any body know if IE will have an orb in the near future?
Thanks for pointing this out, Matthew.
Thien Nguyen
Michi Henning
> I ran the applet on Netscape 4.0.6 and 4.5, it seems to work fine
> (though I have not tested it thoroughly). The nice thing is my jar
> reduced from a hefty 800K down to 180K. The downside is now the applet
> only works with Netscape and not IE. I guess I will have to have a
> separate version of the applet for different type of browser.
>
> Does any body know if IE will have an orb in the near future?
Not until hell freezes over, I suspect. MS are doing their damndest
to make DCOM the OO middleware platform of choice. I think it is highly
unlikely that they would support CORBA in any form.
Cheers,
Michi.
--
Michi Henning +61 7 3236 1633
Triodia Technologies +61 4 1118 2700 (mobile)
PO Box 372 +61 7 3211 0047 (fax)
Annerley 4103 mi...@triodia.com
AUSTRALIA http://www.triodia.com/staff/michi-henning.html
Christopher Browne
>Does any body know if IE will have an orb in the near future?
I seriously doubt that CORBA is on Microsoft's list of "things to
include with IE" in the near future. Using CORBA would require
providing a component that is based on a public standard that Microsoft
doesn't control, and that is certainly not in Microsoft's interests...
--
..you could spend *all day* customizing the title bar. Believe me. I
speak from experience." -- Matt Welsh
cbbr...@hex.net- <http://www.hex.net/~cbbrowne/lsf.html>
meMRmm
Micro Sloth's software, they are ___holes and want to control
everything using their VERY inferior technology (ie - DCOM) which
is about as much object oriented as C and DCE are (which is
exactly how it is implemented along with OLE/COM)!
A very dated and crappy model, if I am allowed to have an
opinion!
So, multiple versions depending on the browser is necessary or
always download the ORB!
Michi Henning wrote:
> On Thu, 10 Dec 1998, Thien Nguyen wrote:
>
> > I ran the applet on Netscape 4.0.6 and 4.5, it seems to work fine
> > (though I have not tested it thoroughly). The nice thing is my jar
> > reduced from a hefty 800K down to 180K. The downside is now the applet
> > only works with Netscape and not IE. I guess I will have to have a
> > separate version of the applet for different type of browser.
> >
> > Does any body know if IE will have an orb in the near future?
>
Douglas C. Schmidt
>
> Not until hell freezes over, I suspect. MS are doing their damndest
> to make DCOM the OO middleware platform of choice.
Speaking of which, is it just me, or has anyone else noticed that DCOM
doesn't seem to be catching on very fast in the world of distributed
computing? Perhaps I'm just working in the wrong domains, e.g.,
telecom, aerospace, and financial systems, but it's been my experience
over the past year that CORBA is really taking hold, whereas DCOM
hasn't. For instance, all the telecommunications companies, e.g.,
Sprint, Nortel, Lucent, Nokia, Motorola, Bellcore, GTE, AT&T, are in
the midst of deploying CORBA-based systems, as are aerospace companies
like Raytheon, Hughes, Boeing, and Lockheed.
In trying to figure out what's going on here, it strikes me that
Microsoft has a "chicken and egg" problem getting DCOM to be the
middleware platform of choice. For instance, DCOM is not suited for
heterogeneous systems, yet almost all non-trivial distributed
computing environments are highly heterogeneous, particularly in the
telecom, aerospace, and financial domains. Thus, until Windows NT
becomes stable enough to run "bet your business" backend server
applications it doesn't seem that DCOM has much chance to catch on in
serious distributed computing systems.
I'd be curious to hear opinions from folks working in these and other
domains.
Take care,
Doug
--
Dr. Douglas C. Schmidt, Associate Professor
Department of Computer Science, Washington University
St. Louis, MO 63130. Work #: (314) 935-4215; FAX #: (314) 935-7302
sch...@cs.wustl.edu, www.cs.wustl.edu/~schmidt/
Michi Henning
> Speaking of which, is it just me, or has anyone else noticed that DCOM
> doesn't seem to be catching on very fast in the world of distributed
> computing? Perhaps I'm just working in the wrong domains, e.g.,
> telecom, aerospace, and financial systems, but it's been my experience
> over the past year that CORBA is really taking hold, whereas DCOM
> hasn't. For instance, all the telecommunications companies, e.g.,
> Sprint, Nortel, Lucent, Nokia, Motorola, Bellcore, GTE, AT&T, are in
> the midst of deploying CORBA-based systems, as are aerospace companies
> like Raytheon, Hughes, Boeing, and Lockheed.
Yes. Whenever you are talking things that are mission-critical, heterogeneous,
or large scale, CORBA is the platform of choice. In particular for
mission-critical and heterogeneous environments, DCOM is not a good choice.
For one, it won't run on anything except Windows (MS's claims to the contrary
notwithstanding). Second, NT won't stay up for long enough to use it
for anything that's 24x7.
> In trying to figure out what's going on here, it strikes me that
> Microsoft has a "chicken and egg" problem getting DCOM to be the
> middleware platform of choice. For instance, DCOM is not suited for
> heterogeneous systems, yet almost all non-trivial distributed
> computing environments are highly heterogeneous, particularly in the
> telecom, aerospace, and financial domains. Thus, until Windows NT
> becomes stable enough to run "bet your business" backend server
> applications it doesn't seem that DCOM has much chance to catch on in
> serious distributed computing systems.
>
> I'd be curious to hear opinions from folks working in these and other
> domains.
I think there is more involved. It's not just that NT first has to become a
more reliable and higher performance OS, it's also that heterogeneity will
*never* go away. If you insist on a middleware platform that can be sourced
from only one vendor, it follows that you will *never* integrate all your
heterogeneous systems. That's because it doesn't make sense for a big
vendor like MS to provide implementations for some fringe platform that
isn't used in large numbers, such as QNX (no slur on QNX here -- I just
use it as an example of something that probably wouldn't be worth the
attention of a big vendor).
CORBA, on the other hand, has the advantage that it is open. This makes
it feasible for a company to target a niche market and offer a
special-purpose ORB for that market, even though big vendors wouldn't
touch it. As the customer, you win because you get your middleware on
absolutely anything that's worthy of attracting at least a little
attention. Besides, there is open source, so you can (if you are
determined enough) port an ORB to the platform you need support for.
That's not a feasible option with DCOM. (It is interesting to note that
CORBA is supported on more *Microsoft* platforms than DCOM...)
I expect that DCOM will do very well in a different area, namely, where you
have a well-controlled, all-MS environment, as is typical for many office
environments. There, you can run DCOM over a LAN and use it to, say,
embed a spreadsheet from "over there" into a Word document "over here".
With their excellent tool support and slick GUI integration, I expect this
will work very well and be successful.
To this day, I am still looking for even a single showcase application with
DCOM that is anything like large-scale, mission-critical, or heterogeneous.
(I can't find a showcase that meets even one of these criteria, let alone
all three.) I'd be pleased to learn that something like this is happening,
but I'm not holding my breath...
Cheers,
Michi.
Copyright 1998 Michi Henning. All rights reserved.
Thien Nguyen
and Andreas Vogel on the topic
(http://www.clbooks.com/interviews/COMvsCORBA.html).
Eventhough, I am not convinced that DCOM is a superior model, Roger
Sessions pointed out a numbers of CORBA issues that I hope to see more
experience CORBA developers address them here (I'll try my best to
summarize what I think are Roger Session's points):
1) CORBA does not address scalability.
2) The courting of Java (i.e. Enterprise Java Beans) is a bad news.
3) "... API on COM/DCOM is getting simpler,..., where as on CORBA side
is getting much mor complex ..."
4) "... CORBA components don't have the ability to support multiple
interface ... and that a weakness of the model"
My purpose is to understand the issues, not to start a fight. Thanks
for any comments.
Thien Nguyen
Douglas C. Schmidt wrote:
>
> > Michi Henning wrote:
> >
> > Not until hell freezes over, I suspect. MS are doing their damndest
> > to make DCOM the OO middleware platform of choice.
>
> Speaking of which, is it just me, or has anyone else noticed that DCOM
> doesn't seem to be catching on very fast in the world of distributed
> computing? Perhaps I'm just working in the wrong domains, e.g.,
> telecom, aerospace, and financial systems, but it's been my experience
> over the past year that CORBA is really taking hold, whereas DCOM
> hasn't. For instance, all the telecommunications companies, e.g.,
> Sprint, Nortel, Lucent, Nokia, Motorola, Bellcore, GTE, AT&T, are in
> the midst of deploying CORBA-based systems, as are aerospace companies
> like Raytheon, Hughes, Boeing, and Lockheed.
> ...
Bill Janssen
Speaking of which, is it just me, or has anyone else noticed that DCOM
doesn't seem to be catching on very fast in the world of distributed
computing?
I think I've noticed this too, Doug. But it may just be an artifact
of where I pay attention.
Bill
--
Bill Janssen <jan...@parc.xerox.com> (650) 812-4763 FAX: (650) 812-4777
Xerox Palo Alto Research Center, 3333 Coyote Hill Rd, Palo Alto, CA 94304
URL: ftp://ftp.parc.xerox.com/pub/ilu/misc/janssen.html
Bill Janssen
Besides, there is open source, so you can (if you are
determined enough) port an ORB to the platform you need support for.
That's not a feasible option with DCOM. (It is interesting to note that
CORBA is supported on more *Microsoft* platforms than DCOM...)
We're planning on doing an Open Source implementation of DCOM for our
ILU platform in 1999 (available 4Q99). Current plans are to have it
speak DCOM wire protocols and MIDL, but use CORBA language mappings
(extended as appropriate for DCOM concepts like pointers not in
CORBA).
Technically, Michi, I think there's no real difference between DCOM
and CORBA, except that the technical model of DCOM is actually a bit
cleaner and less rapidly fluctuating -- but that's standard for a
single-vendor solution.
Bill Janssen
[Roger Sessions says:]
1) CORBA does not address scalability.
2) The courting of Java (i.e. Enterprise Java Beans) is a bad news.
3) "... API on COM/DCOM is getting simpler,..., where as on CORBA side
is getting much mor complex ..."
4) "... CORBA components don't have the ability to support multiple
interface ... and that a weakness of the model"
IMO, he makes a number of good points in (2), (3) and (4).
(4) I've long held that this is a basic weakness of the IDL
inheritance model. Kind of a pointless restriction, too.
(3) Well, I'm not sure that DCOM is getting simpler, but CORBA is sure
as shooting getting more complex, with the addition of OBV. What's
more, 20% of the adopted specifications for CORBA always seem to be
broken; as soon as we fix one up (which seems to take about a year
after adoption, longer for more complicated ones), another broken one
is adopted. What's more, the submissions keep churning even the fixed
adopted specs so that they keep changing.
(2) The emphasis on Java, and turning CORBA into RMI-complex, seems
misplaced to me. Java has a few shortcomings, most due to its origins
as a language for smart toasters. Despite having many good features
(garbage collection, built-in threads, dynamic loading, separate
interfaces and implementation, strong typing), the language itself
suffers from a paucity of mechanisms to support good programming. The
only real mechanism one has is the object system, and that's crippled
by being single-inheritance (which helps if you're trying to fit the
interpreter into a toaster, but is a major drag if you're trying to
write real programs). This lack of mechanism (again, simpler to fit
into a smart toaster with few mechanisms) causes hacks (well, let's
call them `patterns') which are reflected in systems like EJB, which
is essentially just a collection of conventions for defining classes,
conventions which are not (cannot be) enforced by the language.
Reflecting those same limitations into CORBA results in an
unnecessarily weak model at the CORBA level.
Bill Janssen
I seriously doubt that CORBA is on Microsoft's list of "things to
include with IE" in the near future. Using CORBA would require
providing a component that is based on a public standard that Microsoft
doesn't control, and that is certainly not in Microsoft's interests...
I thought the recent court order in San Jose forced MS to distribute
the full JDK package, including the Sun ORB, to be compliant. Doesn't
that include Java in the IE?
Bill Janssen
flaw in OMG IDL inheritance. The problem is that if two interface
types both have methods with the same name, they cannot both be used
as ancestors of another interface type. This basically means that all
IDL inheritance trees must be planned in toto, instead of being able
to combine interface types arbitrarily, as is possible with DCOM.
Now, DCOM doesn't call it inheritance (they reserve that for a
single-inheritance structure they use in their MIDL), but it amounts
to the same thing. Or would, if OMG IDL didn't have that problem.
Jonathan Biggar
>
> In article <74sfuo$qb8$1...@blue.hex.net> cbbr...@news.hex.net (Christopher Browne) writes:
>
> I seriously doubt that CORBA is on Microsoft's list of "things to
> include with IE" in the near future. Using CORBA would require
> providing a component that is based on a public standard that Microsoft
> doesn't control, and that is certainly not in Microsoft's interests...
>
> I thought the recent court order in San Jose forced MS to distribute
> the full JDK package, including the Sun ORB, to be compliant. Doesn't
> that include Java in the IE?
I don't think so. From my memory of the SJ Mercury news article,
Microsoft has to fix the Java they are shipping to be compatible with
Sun's version, but does not have to accept any additions that Sun is
making. This means that M$ can stick with JDK 1.1 and never upgrade to
JDK 1.2, which includes the ORB.
--
Jon Biggar
Floorboard Software
j...@floorboard.com
j...@biggar.org
Michi Henning
> Relating DCOM vs. CORBA, I came accross a debate between Roger Session
> and Andreas Vogel on the topic
> (http://www.clbooks.com/interviews/COMvsCORBA.html).
>
> Eventhough, I am not convinced that DCOM is a superior model, Roger
> Sessions pointed out a numbers of CORBA issues that I hope to see more
> experience CORBA developers address them here (I'll try my best to
> summarize what I think are Roger Session's points):
>
> 1) CORBA does not address scalability.
Yes, that's what he says. However, he never substantiates that claim.
There are some mutterings about "object pooling" and "stateless objects"
but that's about it. For what it's worth, several ORBs have supported
both for years, and the POA specification explicitly enshrines these
ideas in the spec.
I have personally worked on systems that scale very well indeed (several
million objects in a single server process, with a request rate of around
700 requests per second). And that does not require exotic hardware or
huge amounts of memory.
Anyone who claims that "CORBA does not scale" makes about as much sense
as someone who says that "Cars don't go fast". The statement is so general
as to be totally meaningless.
> 2) The courting of Java (i.e. Enterprise Java Beans) is a bad news.
Is it? Why?
> 3) "... API on COM/DCOM is getting simpler,..., where as on CORBA side
> is getting much mor complex ..."
Yes. Claims but no examples or substantiation. I'm having a very hard
time swallowing the claim that DCOM APIs are simpler. To me, it seems
the opposite is true.
> 4) "... CORBA components don't have the ability to support multiple
> interface ... and that a weakness of the model"
He is right if he says that an object reference has exactly one most
derived type. However, at the implementation level, you can have a single
programming language instance incarnate more than one interface simultaneously
(although I would argue that this isn't all that useful). So, in the sense
that you cannot ask a "CORBA object" with a specific identity for a specific
interface, Sessions is right. You could build the same functionality with
a trader, but that's not as nice as built-in platform support.
However, the component spec that's in the works also addresses multiple
interfaces, so I expect this restriction won't be around for too much longer.
Christopher Browne
<sch...@tango.cs.wustl.edu> wrote:
>In trying to figure out what's going on here, it strikes me that
>Microsoft has a "chicken and egg" problem getting DCOM to be the
>middleware platform of choice. For instance, DCOM is not suited for
>heterogeneous systems, yet almost all non-trivial distributed
>computing environments are highly heterogeneous, particularly in the
>telecom, aerospace, and financial domains. Thus, until Windows NT
>becomes stable enough to run "bet your business" backend server
>applications it doesn't seem that DCOM has much chance to catch on in
>serious distributed computing systems.
I would think that the way of popularizing it is via having the overall
set of add-ons that MSFT is gradually adding into the system, notably:
- Their version of Sybase, as a data store, and
- Their Message Queuing/Transaction system
They're not likely to sell this real heavily to big enterprises doing
big jobs. But if it's 'good enough' for building departmental
applications, and of course has pretty GUI stuff to go along with that,
the visible "toy applications" may be sufficient to get managers not
aware enough to know better to think it's good enough for bigger
applications. This is essentially what got MSFT "in the door" on most
of the other areas in which they have become dominant.
To this end, I think it's real important for CORBA implementations to
start examining the notion of adding the transaction service and
whichever persistent object service emerges. None of the free ones
offer either service; it's pretty fortunate if one gets both the naming
and trader services.
--
"In my opinion MS is a lot better at making money than it is at making
good operating systems." -- Linus Torvalds
cbbr...@ntlug.org- <http://www.hex.net/~cbbrowne/lsf.html>
Timothy Docker
jan...@parc.xerox.com (Bill Janssen) writes:
> 4) "... CORBA components don't have the ability to support multiple
> interface ... and that a weakness of the model"
>
> IMO, he makes a number of good points in (2), (3) and (4).
I don't get this. How is supporting multiple interfaces difference to
inheriting from more than one interface (ie CORBA's existing multiple
inheritance)?
--------------------------------------------------------------
Tim Docker ti...@macquarie.com.au
Quantative Applications Division
Macquarie Bank
Michi Henning
> Technically, Michi, I think there's no real difference between DCOM
> and CORBA, except that the technical model of DCOM is actually a bit
> cleaner and less rapidly fluctuating -- but that's standard for a
> single-vendor solution.
Hmmm... I'm not a DCOM guru, but from what I've learned, there are technical
differences that seem to matter. Here are few that come to mind (and bear
in mind that I may well put my foot in here because I'm not a guru):
- The language bindings expose the programmer to marhshaling
artifacts, such as BSTR. This seems unnecessarily complex.
In addition, there seems to be a NUL-terminated string as
well, in effect leading to two different string concepts.
- My understanding is that a dynamic call (the analog of a DII call)
is possible only if an object provides IDispatch. However, that
is not automatically the case for all objects. Rather, I have
to anticipate that my objects may need to be called dynamically
at some point and build them accordingly. In CORBA, any object
can be invoked dynamically for free.
- From what I've seen, there does not appear to be something like
a DSI (although I may have missed it).
- Language transparency seems to suffer in a number of places. For
example, not all types provided by MIDL can be used with automation
servers. In particular, user-defined constructed types don't work.
So, when I write the IDL, I have to either stick to primitive
types only, or accept that my IDL cannot be used from certain
languages, such as Visual Basic.
- In order to get an interface handle, the client must supply
a machine name. What does that mean for object or server migration?
- There is no support for exceptions. Instead, I am reduced to
32-bit error code. This is substantially weaker than CORBA's model.
For one, I cannot add an arbitrary amount of data to my error
indications. Second, error handling is not neatly integrated into
the native exception handling mechanism, which makes reliable
and elegant error handling a good deal harder.
- Apparently, DCOM with Java relies an some of the MS-specific
extensions they added to the Java VM. With the recent court
ruling, I'm not sure what that means for developers. Presumably,
MS will have to make changes to the way DCOM works with Java?
- For C++, MS have added a number of extensions to their C++ compiler
specifically to support COM. I'm having serious concerns about
a platform that requires changes to a standardized language, no
matter how desirable or convenient these changes may be.
- My impression is that while I get polymorphism at the interface
level, I don't get polymorphism at the implementation level because
DCOM maps each interface to an unrelated C++ type. That's at least
inconvenient, if not actually harmful.
- The COM factory approach has me worried. I first create an object
and then initialize it. CORBA factories do this a lot better,
because I can set them up such that it is impossible to ever
hold a handle to an unitialized object.
- The "six minutes fits all" philosophy doesn't make the grade.
Granted, DCOM gives me distributed GC, which is a lot better than
no GC at all. On the other hand, the arbitrary six minute rule
is almost certainly wrong almost all of the time. I may have objects
where I cannot tolerate having them kick around for six minutes
before they are reaped -- I may need to reclaim the resources within
seconds. Yet, there are other objects that I may not want to be
reaped for hours or days. I would have thought that the GC strategy
should be at least customizable depending on the needs of my
application.
- In the absence of large-scale and mission-critical applications,
I am still doubtful about the scalability of DCOM's GC. At least
theoretically, I'm worried about the overhead of GC for large
systems. I know that the protocol uses quite a few optimizations
to minimize the cost of GC, such as piggy-backing and grouping
of ping messages. But I am still skeptical, and there does not
appear to be any large-scale proof that this actually works
as adverized.
- In order to send pings, the client-side run time must be
multi-threaded because the the application code may not be willing
or able to relinquish the thread of control to the run time.
This is a severe restriction for some environments.
- MIDL is a lot more complex than IDL, to the point where I am
supposed to use tools to create it. In addition, MIDL mixes
a number of implementation aspects with interface definitions.
We just discussed in another thread that this is undesirable
for a number of reasons.
So, these are a few of the technical arguments I can think of off the top
of my head. Given that I don't know all that much about DCOM, I may well
have got some of these wrong (if so, someone educate me please!) On the other
hand, there are probably quite a few I don't know about because I'm not
expert enough.
Apart from technical concerns, I also have quite a few non-technical ones,
but I'll leave these for another time ;-)
Michi Henning
> In article <367575...@statsci.com> Thien Nguyen <th...@statsci.com> writes:
>
> [Roger Sessions says:]
> 1) CORBA does not address scalability.
> 2) The courting of Java (i.e. Enterprise Java Beans) is a bad news.
> 3) "... API on COM/DCOM is getting simpler,..., where as on CORBA side
> is getting much mor complex ..."
> 4) "... CORBA components don't have the ability to support multiple
> interface ... and that a weakness of the model"
>
> IMO, he makes a number of good points in (2), (3) and (4).
>
> (4) I've long held that this is a basic weakness of the IDL
> inheritance model. Kind of a pointless restriction, too.
I agree in that multiple interfaces are useful for system evolution.
However, I don't agree that it is a pointless restriction. I've spent
quite a few hours thinking about versioning for IDL, and the most obviously
attractive approach, namely, the DCE one, creates so many semantic problems
that my head hurts every time I think about it...
But yes -- multiple interfaces in some form would be useful. Getting them
to neatly mesh with the inheritance is another matter altogether...
> (3) Well, I'm not sure that DCOM is getting simpler, but CORBA is sure
> as shooting getting more complex, with the addition of OBV.
Well, be fair -- DCOM doesn't have any such thing as OBV. It's hardly
surprising that extra features add extra complexity. That's not to say that
I'm a great proponent of OBV -- in my opinion, OBV was a step in the wrong
direction.
> What's
> more, 20% of the adopted specifications for CORBA always seem to be
> broken; as soon as we fix one up (which seems to take about a year
> after adoption, longer for more complicated ones), another broken one
> is adopted. What's more, the submissions keep churning even the fixed
> adopted specs so that they keep changing.
Yes. There seems to be a direct correlation between the eagerness of
individuals to see their work enshrined in a specification and their degree
of incompetence in developing said specification :-(
It's also highly embarrassing for the OMG to have things adopted that turn
out to be complete fantasy material. I'm still hoping that the new adoption
rules will go a long way towards preventing further embarrassment.
> (2) The emphasis on Java, and turning CORBA into RMI-complex, seems
> misplaced to me.
Agree. CORBA isn't Java RMI and never was meant to be. What you are seeing
there is the Java hype in action: "If it ain't like Java I don't wanna know
about it." That's one my main criticisms of OBV. How the hell to you
dynamically ship behavior (i.e. code) across the wire when you have a COBOL
program at the other end that can't even do dynamic linking?
Still, despite the harsh words above, I still think CORBA has an awful lot
going for it. It's by far the most versatile and easy to use RPC platform
we've ever seen (yes, I know RMI is easy too, but it won't work with C++,
COBOL, C, Smalltalk, Ada, etc.) And when you think about it, CORBA is the
first time that we are seeing wide-spread acceptance of distributed systems
technology in what are traditionally conservative IT environments, such
as banks or insurance companies. DCE was meant to do this, but never got
anywhere because of its complexity. CORBA seems to have done better as
far as market penetration is concerned.
We also have a large number of real applications that are used to solve
real and mission-critical problems. There is proof that it works. As far
as I'm concerned, a bird in the hand is better than two on the roof...
Finally, getting back to dear old Roger. Let's not forget that he has
a huge axe to grind and has a very bruised ego after the POS debacle.
I'd hardly call myself unbiased either, but Roger Sessions makes myself
look like a beginner when it comes to bias...
Michi Henning
>
> jan...@parc.xerox.com (Bill Janssen) writes:
>
> > 4) "... CORBA components don't have the ability to support multiple
> > interface ... and that a weakness of the model"
> >
> > IMO, he makes a number of good points in (2), (3) and (4).
>
> I don't get this. How is supporting multiple interfaces difference to
> inheriting from more than one interface (ie CORBA's existing multiple
> inheritance)?
A single implementation object in DCOM can support multiple unrelated
interfaces at run time. The client can ask an object what interfaces it
supports. The difference is that with DCOM, the multiple interfaces do
not need to be related to each other. You don't need multiple inheritance
(or any other artifact at the IDL level) to support the feature. Moreover,
the client is aware that a single object has multiple interfaces because
the object retains the same identity for all these interfaces. In CORBA,
object identity is not visible to the client because identity is buried
inside the opaque reference to the object and, in fact, identity is a
concept that is controlled by the server.
I'm not sure I like this aspect of DCOM, though, because it imposes a
notion of identity on the application. In CORBA, I get more freedom in
deciding exactly what object identity should mean. And of course, I can
map multiple references of different types to be handled by the same
servant if I want to -- it's just that clients don't know whether that
is what I've done. The advantage is that I can change my implementation
at any time without breaking clients. With DCOM, I don't see how that
would be possible. It seems that DCOM has a much weaker notion than CORBA
of separating interface and implementation.
Michi Henning
> The problem is that CORBA inheritance is severely limited by a design
> flaw in OMG IDL inheritance. The problem is that if two interface
> types both have methods with the same name, they cannot both be used
> as ancestors of another interface type. This basically means that all
> IDL inheritance trees must be planned in toto, instead of being able
> to combine interface types arbitrarily, as is possible with DCOM.
>
> Now, DCOM doesn't call it inheritance (they reserve that for a
> single-inheritance structure they use in their MIDL), but it amounts
> to the same thing. Or would, if OMG IDL didn't have that problem.
You'd have to admit though that coming up with a disambiguation mechanism for
multiple inheritance isn't such a big problem. I believe it wouldn't affect
anything on the wire or in the ORB run time. Instead, it could be handled
purely at the language mapping level.
Michi Henning
> I don't think so. From my memory of the SJ Mercury news article,
> Microsoft has to fix the Java they are shipping to be compatible with
> Sun's version, but does not have to accept any additions that Sun is
> making. This means that M$ can stick with JDK 1.1 and never upgrade to
> JDK 1.2, which includes the ORB.
Hmmm... Interesting. How long can they resists pressure to got to JDK 1.2
though? Is it really a feasible long-term option to never support newer
version of the JDK?
Rajeev Arora
on their CORBA development activity.
Discussions about Netscape's CORBA support are found at
news://secnews.netscape.com in the netscape.dev.corba newsgroup.
Netscape DevEdge CORBA FAQ is found at:
http://developer.netscape.com/support/faqs/index.html?content=champions/corba.html
... and like Michi, I am also based in the Aussie-land downunder.
Cheers,
Rajeev
--
Rajeev Arora ----------------------+---------------------------------+
Client-Server Archiect, IBM GSA ! Netscape DevEdge CORBA Champion !
Ph +61 3 9693-4615 Fax 9663-4216 ! http://developer.netscape.com/ !
-----------------------------------+---------------------------------+
Author "Special Edition Using Enterprise Java" (http://www.que.com/) !
covering Java-CORBA Application Development, JDBC and Java RMI !
-----------------------------------+---------------------------------+
Principal, SystemSmiths, 3 Clarinda Court, Vermont South. Melbourne !
Victoria 3133. Australia. Phone/Fax: +61 3 9803-2133 !
---------- http://www.systemsmiths.com.au/ --------------------------+
Rajeev Arora
Support in firewalls.
A number of CORBA products have mechanisms to work with firewalls in
secure fashion. Security mechanisms like GIOP proxies and SSL support
are available. The CORBA firewall RFP established the baseline against
which firewalls and therefore CORBA applications over the Internet
(across trust boundaries) can interoperate.
OTOH, all you can find on DCOM through firewalls at Microsoft site is a
paper by a post-graduate student.
I will be presenting a tutorial --- Enhancing Corporate Firewalls for
Java (CORBA, RMI and EJB) at the forthcoming JavaAus99 conference being
held in Sydney.
Checkout http://www.dstc.edu.au/events/javaus99/
Rajeev
sst...@nyx.net
>
> Relating DCOM vs. CORBA, I came accross a debate between Roger Session
> and Andreas Vogel on the topic
> (http://www.clbooks.com/interviews/COMvsCORBA.html).
Great debate.
> 1) CORBA does not address scalability.
RS should check CNN web site backend, powered by ORB. How
many hits per day?
RS is a coauthor of Persistence Object Service (POS) that
should have provided, coupled with some other services, a
foundation for distributed object transactions. "D" in ACID
acronym stands for "durable", and that is what persistence
service failed to provide. It's a joke that the coauthor of
unimplementable persistence service specs (recently tossed
out) complains about OMG rubber stamping daydream
specifications.
Several posters complained about OBV; while I'm not fond
about the specification (particularly the introduction of the
"valuetype" keyword which is IMO redundant), OBV is a
foundation for several things like persistence, ACID
transactions, object replication and multihop agents.
Another entertaining thing is a "NT will dominate the
market" idea. I've seen a few companies lately that
migrate from NT to Unix. It'll be fun.
I find this RS quote most interesting:
I think that Andreas raised a really
good point, that when you're looking at
CORBA, you can't look at CORBA. You've
got to look at implementations. That's
a very important point to pick up on.
Because basically, their standard is so
nebulous that every different
implementation has their own things that
you have to do to take advantage of it.
So what you really want to do is not
look at Microsoft versus the OMG, but
look at Microsoft versus Visiigenic, or
Microsoft versus Iceberg. And that
becomes a much, much weaker situation
for the CORBA folks. There is no kind
of unified architecture they can put out
there against Microsoft.
In my view, the best way to answer such claims is to have a
working counterexample; we took JDK 2 (Sun) and OmniORB2.6.1
(ORL) yesterday, and they work without a glitch. Two
languages, two OSes, and it works like a dream.
sbs
--
Life is a journey.
Enjoy the ride.
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Gerald Brose
>
> On 14 Dec 1998, Bill Janssen wrote:
>
> > The problem is that CORBA inheritance is severely limited by a design
> > flaw in OMG IDL inheritance. The problem is that if two interface
> > types both have methods with the same name, they cannot both be used
> > as ancestors of another interface type. This basically means that all
> > IDL inheritance trees must be planned in toto, instead of being able
> > to combine interface types arbitrarily, as is possible with DCOM.
> >
> > Now, DCOM doesn't call it inheritance (they reserve that for a
> > single-inheritance structure they use in their MIDL), but it amounts
> > to the same thing. Or would, if OMG IDL didn't have that problem.
>
> You'd have to admit though that coming up with a disambiguation mechanism for
> multiple inheritance isn't such a big problem. I believe it wouldn't affect
> anything on the wire or in the ORB run time. Instead, it could be handled
> purely at the language mapping level.
Well, it's certainly no problem to come up with an algorithm. There is
one for the problem outlined above in the Java Language Specification.
The actual problem is that IDL name resolution, which is the reason for
the above restriction, is prescribed in the central CORBA IDL chapter
and thus cannot (and should not, IMHO) simply be redefined in an ad hoc
way by language mappings. Why not adopt the Java solution and adjust
IDL name resolution?
Regards, Gerald Brose.
--
Gerald Brose, Mail: br...@inf.fu-berlin.de
FU Berlin (for PGP key see:) http://www.inf.fu-berlin.de/~brose
Institut f. Informatik Ph-one: (++49-30) 838-75112
Berlin, Germany Ph-ax: (++49-30) 838-75109
Michi Henning
> Well, it's certainly no problem to come up with an algorithm. There is
> one for the problem outlined above in the Java Language Specification.
> The actual problem is that IDL name resolution, which is the reason for
> the above restriction, is prescribed in the central CORBA IDL chapter
> and thus cannot (and should not, IMHO) simply be redefined in an ad hoc
> way by language mappings. Why not adopt the Java solution and adjust
> IDL name resolution?
Gerald, I don't understand -- I don't think this is an IDL-related problem
at all. If an interface multiply inherits operations with the same name,
as far as the interface is concerned, there is nothing unusual happening.
The derived interface simply has two operations.
interface A {
void op(in long p);
};
interface B {
string op(out boolean b);
}
interface D : A, B {
// Conceptually, D has
// void op(in long p);
// string op(out boolean b);
};
The problem I see is that the operations in the base interface may have
the same signature:
interface A {
void op(in long p);
};
interface B {
void op(in long p);
}
interface D : A, B {
// Conceptually, D has only a single
// void op(in long p);
};
The problem really appears to be at the implemtation level. When I want
to invoke op() on a D reference, how do I specify which op() I mean,
especially in the case where an operation is multiply inherited with
identical signatures.
For languages that don't have the concept of disambiguation of multiple
inheritance, this becomes difficult (but not impossible) to map. The real
issue I see is that ambiguous multiple inheritance also opens the door
to overloading:
interface A {
void op(in long p);
};
interface B {
string op(in long p);
}
interface D : A, B {
// Conceptually, D has now has two operations:
// void op(in long p);
// string op(in long p);
};
That's where mapping this becomes really messy if you don't have overloading
support in the target language.
But, as far as I can see, these issues are (mostly) language mapping issues.
Thinking about it a bit more though, you would have to make changes
on the wire as well because the operation name is no longer guaranteed to
uniquely identify the correct operation. But that could be done in a fairly
non-intrusive manner. For example, you could send A::op and B::op as the
operation name on the wire. The main problem I see is how to map it
into languages such as C.
ro...@objectwatch.com
> Finally, getting back to dear old Roger. Let's not forget that he has
> a huge axe to grind and has a very bruised ego after the POS debacle.
> I'd hardly call myself unbiased either, but Roger Sessions makes myself
> look like a beginner when it comes to bias...
I don't think I have an axe to grind. Its true that I was disappointed with
the outcome of the POS specification. It was something I cared a great deal
about, and felt that our ideas of persistence were hurt by the OMG political
process. But I continued to work very hard for the OMG for two years after
the Persistence specification was completed, including preparing and teaching
portions of the OMG's CORBA academy.
Actually, my feelings that the OMG was going in the wrong direction came as a
result of planning my fourth book. Wiley had asked me to do a book on COM and
DCOM, and I wanted to do another book on CORBA. I told them I didn't know
anything about COM/DCOM, and believed in the CORBA technology. I finally
agreed to spend some time investigating COM/DCOM. I didn't get interested
until I ran into MTS. I found MTS intriguing, because it combined two areas
of my interest, components and transaction processing monitors. At that time,
the OMG had yet to even consider this possibility.
So it was really my investigation of MTS that convinced me Microsoft was ahead
of CORBA. It had nothing to do with the POS. What is interesting to me is that
to this day, CORBA has yet to answer MTS. They may do so with the Component
Specification of CORBA 3.0, but this looks like it is in trouble. For more
information on the status of CORBA 3.0, see my latest newsletter at
http://www.objectwatch.com/issue17.htm.
But I still look fondly on my days with the OMG. It was a great organization,
with some great people involved. I hope they can get their act together to
once again play an important role in this fast moving technology area. But
over the last few years, things have been moving increasingly slowly within
the OMG, and the results have been less than stellar, in my opinion.
Sorry to get involved in this long defense of my character. Usually I resist
the temptation to defend myself, and try to let my writing speak for itself.
Attacking me personally does nothing to answer the issues I raise. I can't
resist pointing out that in all the years I wrote on behalf of the OMG and
against Microsoft, Microsoft never once attacked me personally. Now that I
have "switched sides", the OMG has rarely done anything other than attack me
personally. I suspect we could all learn a lot from each other if we would
worry less about sides and more about technologies.
Best wishes for the new year,
Roger Sessions
Gerald Brose
>
> On Wed, 16 Dec 1998, Gerald Brose wrote:
>
> > Well, it's certainly no problem to come up with an algorithm. There is
> > one for the problem outlined above in the Java Language Specification.
> > The actual problem is that IDL name resolution, which is the reason for
> > the above restriction, is prescribed in the central CORBA IDL chapter
> > and thus cannot (and should not, IMHO) simply be redefined in an ad hoc
> > way by language mappings. Why not adopt the Java solution and adjust
> > IDL name resolution?
>
> Gerald, I don't understand -- I don't think this is an IDL-related problem
> at all.
Sorry for muddling up things and not being precise. I was talking about
inheritance at the interface level only, not about implementations.
At the interface level, no problems arise when an interface inherits
the same operation (with the same signature) from two base interfaces -
but IDL does not permit it (p. 3-18 in Corba 2.2) and IDL compilers
reject cases like
module O {
interface A {
void op( in long l );
};
interface B {
void op( in long l );
};
interface C : A, B{
};
};
In my opinion, this should be allowed as there will simply only be one
implementation of op(). In effect, such an interface design unifies the
two operations. Now as for implementation inheritance, that's a
different
story and could, as you pointed out, handled in language mappings.
The other issue that you raised in this context, overloading of
operation
names, does indeed require changes on the wire.
> For languages that don't have the concept of disambiguation of multiple
> inheritance, this becomes difficult (but not impossible) to map. The real
> issue I see is that ambiguous multiple inheritance also opens the door
> to overloading:
>
> interface A {
> void op(in long p);
> };
>
> interface B {
> string op(in long p);
> }
>
> interface D : A, B {
> // Conceptually, D has now has two operations:
> // void op(in long p);
> // string op(in long p);
> };
>
> That's where mapping this becomes really messy if you don't have overloading
> support in the target language.
[...]
> Thinking about it a bit more though, you would have to make changes
> on the wire as well because the operation name is no longer guaranteed to
> uniquely identify the correct operation. But that could be done in a fairly
> non-intrusive manner. For example, you could send A::op and B::op as the
> operation name on the wire. The main problem I see is how to map it
> into languages such as C.
A::op and B::op would only work if we allowed only a limited form
of operation overloading that would just suffice to disambiguate
between multiply inherited operations. For full overloading of
operation names even within one interface that would not do.
You would have to transmit the complete operation signature, e.g.
something like "op(I)V" for an operation "void op(in long l)".
Perhaps we would end up encoding even in/out-ness , so it's
probably a good thing there's no overloading in the first place ;-).
Best regards, Gerald.
Michi Henning
>
> > Finally, getting back to dear old Roger. Let's not forget that he has
> > a huge axe to grind and has a very bruised ego after the POS debacle.
> > I'd hardly call myself unbiased either, but Roger Sessions makes myself
> > look like a beginner when it comes to bias...
>
> I don't think I have an axe to grind. Its true that I was disappointed with
> the outcome of the POS specification. It was something I cared a great deal
> about, and felt that our ideas of persistence were hurt by the OMG political
> process.
"Disappointed with the outcome"? Roger, you were one of the main authors
of the POS. That specification was later found to be unimplementable
fantasy material. I notice that didn't stop you from writing a book about
it, though.
You don't think you have an axe to grind? I find that hard to believe
considering how much effort you devote toward rubbishing the OMG. In one
of your newsletters, you shift blame for the POS from yourself (one of
the authors) to the OMG for accepting that specification. I agree -- the
OMG technology adoption process must take part of the blame for adopting
a spec that is nonsense. But I don't see how that abrogates you from the
the part you played in foisting this thing on the rest of the CORBA
community in the first place.
> Actually, my feelings that the OMG was going in the wrong direction came as a
> result of planning my fourth book. Wiley had asked me to do a book on COM and
> DCOM, and I wanted to do another book on CORBA. I told them I didn't know
> anything about COM/DCOM, and believed in the CORBA technology. I finally
> agreed to spend some time investigating COM/DCOM. I didn't get interested
> until I ran into MTS. I found MTS intriguing, because it combined two areas
> of my interest, components and transaction processing monitors. At that time,
> the OMG had yet to even consider this possibility.
Really? I remember reading the transaction specification 4 years ago.
> So it was really my investigation of MTS that convinced me Microsoft was ahead
> of CORBA.
Given your track record, forgive me for being doubtful about your
qualifications to judge or investigate the relative merits of CORBA and DCOM.
> But I still look fondly on my days with the OMG. It was a great organization,
> with some great people involved. I hope they can get their act together to
> once again play an important role in this fast moving technology area.
I don't see what belittling an organization like the OMG achieves here.
By implication, the OMG is not "playing an important role in this fast moving
technology area". Making a claim like that is simply ludicrous. DCOM or no
DCOM, the OMG clearly is playing an important role in this space. Or are
you suggesting that an industry consortium with 800+ member companies
is not playing an important role? If so, these 800+ companies must be awfully
misguided...
Besides, there are facts to consider too. Why don't we compare notes as
to the deployed number of mission-critical applications using DCOM and
CORBA? By my count, CORBA has several hundred documented cases plus I don't
know how many undocumented ones. I have yet to find even a single DCOM
application that meets the criteria of being mission-critical, large-scale,
and heterogeneous.
Wells Fargo Bank have based their Internet banking application on CORBA.
Boeing are using CORBA for their spare parts support for planes.
CNN have tied their web site together using CORBA. The IRIDIUM global
satellite network uses CORBA for their ground stations.
These companies are building applications on CORBA that are critical to
their success. They rely on technology defined and published by the OMG.
Please, if you want to claim that that the OMG are no longer playing an
important role in this space, at least state how you reach that conclusion.
> So it was really my investigation of MTS that convinced me Microsoft was ahead
> of CORBA.
Well, in face of the available evidence, that is a strange conclusion to
reach. Of course, the absence of showcase applications for DCOM may not
mean anything or all the companies who've built CORBA applications could
be misguided, but somehow, that strikes me as unlikely.
> But
> over the last few years, things have been moving increasingly slowly within
> the OMG, and the results have been less than stellar, in my opinion.
Really. What specifically are you referring to? If you were to actually
state why results are "less than stellar", we might have something to
discuss. As is, all I see from you are assertions without substantiation,
something that is pervasive in your newsletters as well.
> Sorry to get involved in this long defense of my character. Usually I resist
> the temptation to defend myself, and try to let my writing speak for itself.
> Attacking me personally does nothing to answer the issues I raise. I can't
> resist pointing out that in all the years I wrote on behalf of the OMG and
> against Microsoft, Microsoft never once attacked me personally. Now that I
> have "switched sides", the OMG has rarely done anything other than attack me
> personally.
Well, if you were to spread fewer unsubstantiated and inaccurate claims
about CORBA, I suspect no-one would have any interest in attacking you.
> I suspect we could all learn a lot from each other if we would
> worry less about sides and more about technologies.
Well, let's worry about technologies then. Why don't you come up with
a technology list that demonstrates the relative merits? We can then discuss
the issues based on technical data instead of rethoric.
Rudolf Schreiner
> A number of CORBA products have mechanisms to work with firewalls in
> secure fashion. Security mechanisms like GIOP proxies and SSL support
> are available.
I agree that IIOP is a quite firewall friendly protocol. But setting up
firewalls for real world applications is still quite tricky.
> The CORBA firewall RFP established the baseline against
> which firewalls and therefore CORBA applications over the Internet
> (across trust boundaries) can interoperate.
I'm not that happy with the RFP. GIOP level proxies are almost useless
because you need authentication and encryption between client and
server. SOCKS is fine for the client side. But the proxification of IORs
at the server side is tricky. It worked fine for simple tests but
I'm not sure that it is a viable solution for very complex real world
systems. I'm running here now a transparent TCP level proxy (no
proxification of the IOR necessary) and an ORB with SSL or Kerberos.
What we need for the future is an integration of security service and
firewalls.
Rudi
Mark Harrison
>
> doesn't seem to be catching on very fast in the world of distributed
> computing?
The main reason may be the availability of the software.
For large-scale applications, the first tendency is to buy
large boxes, such as high-end Sun or HP servers.
Since DCOM does not seem to be readily available for these
boxes, it is immediately ruled out.
DCOM seems to be doing well in "intranet" style applications.
Mark.
ma...@usai.asiainfo.com
Mark Harrison at AsiaInfo Computer Networks,
Beijing, China
Mark Harrison
>Or are
>you suggesting that an industry consortium with 800+ member companies
>is not playing an important role? If so, these 800+ companies must be
awfully
>misguided...
To be fair, at least some of those companies are members because at
one time being a member was the only way you could get books such
as the COSS.
Roger Sessions
think?)
>Back then, there were about 500 members. Granted, there may have been
>companies who joined purely to get access to the documentation. On the
>other hand, at the latest count, there are nearly 400 member companies
>with voting rights. I strongly doubt that these companies are paying for
>a voting membership just so they can read the documentation...
Actually, I wonder why they are paying for a voiting membership. You might
find it amusing to see how many of those 400 companies cared about the
Component Specification enough to even bother registering to vote. The
Component Specification is the most important specification to come out of
the OMG in the last 3 year (assuming it ever comes out). Why don't you look
on the OMG web site and see how many of your 400 "voting" member companies
cared enough to even bother sending in a single piece of Email that would
have given them the right to vote on this critical specification.
I would give you the answer, but of course, you couldn't trust me, because I
am too biased. So look it up yourself. The answer is at
http://www.omg.org/techprocess/meetings/schedule/CORBA_Component_Model_RFP.h
tml
Best wishes,
Roger
----
Roger Sessions, President, ObjectWatch, Inc.
Training and Consulting in Distributed Component Applications
ro...@objectwatch.com 512/258-4922
Michi Henning
> Michi Henning wrote in message ...
> >Or are
> >you suggesting that an industry consortium with 800+ member companies
> >is not playing an important role? If so, these 800+ companies must be
> awfully
> >misguided...
>
> To be fair, at least some of those companies are members because at
> one time being a member was the only way you could get books such
> as the COSS.
Hmmm... That was quite a long time ago though (more than three years, I think?)
Back then, there were about 500 members. Granted, there may have been
companies who joined purely to get access to the documentation. On the
other hand, at the latest count, there are nearly 400 member companies
with voting rights. I strongly doubt that these companies are paying for
a voting membership just so they can read the documentation...
Cheers,
Michi Henning
> Actually, I wonder why they are paying for a voiting membership. You might
> find it amusing to see how many of those 400 companies cared about the
> Component Specification enough to even bother registering to vote. The
> Component Specification is the most important specification to come out of
> the OMG in the last 3 year (assuming it ever comes out). Why don't you look
> on the OMG web site and see how many of your 400 "voting" member companies
> cared enough to even bother sending in a single piece of Email that would
> have given them the right to vote on this critical specification.
>
> I would give you the answer, but of course, you couldn't trust me, because I
> am too biased. So look it up yourself. The answer is at
> http://www.omg.org/techprocess/meetings/schedule/CORBA_Component_Model_RFP.h
> tml
By my count, there are 52 member companies on the voting list. Among them
are names such as Alcatel, BellSouth, Boeing, British Telecom,
Digital Equipment, Ericsson, Fujitsu, Hewlett-Packard, ICL, IBM, Lucent
Technologies, Microsoft, NCR, Netscape, Nortel, Novell, Oracle, Silicon
Graphics, Sybase, Tandem, Telefonica, The Open Group, Unisys, and Xerox.
Proof positive that the OMG no longer plays an important role in this
important technology area?
How many companies get to vote on DCOM or COM+ to make sure their interests
are represented adequately?
Bill Janssen
Thinking about it a bit more though, you would have to make changes
on the wire as well because the operation name is no longer guaranteed to
uniquely identify the correct operation. But that could be done in a fairly
non-intrusive manner. For example, you could send A::op and B::op as the
operation name on the wire.
Or, as we've discussed before, the repository ID of A or B, along with "op".
The main problem I see is how to map it into languages such as C.
Not a big deal -- A_op() and B_op(), much as C++ is A::op() and B::op().
The real problem is posed by crippled languages like Java, which lack most
common customization technologies.
Bill Janssen
> The main problem I see is how to map it into languages such as C.
>
> Not a big deal -- A_op() and B_op(), much as C++ is A::op() and B::op().
Only one glitch here -- there are cases where this becomes ambiguous:
Yep. There are better ways of doing the language mappings than the
standard one adopted by the OMG. In ILU, we chose to go with the
non-optimal CORBA mapping anyway for the sake of standards
compatibility. See
ftp://ftp.parc.xerox.com/pub/ilu/2.0a13/manual-html/manual_25.html#SEC599
for Mike Spreitzer's comments, and a concrete proposal, on this.
> The real problem is posed by crippled languages like Java, which lack most
> common customization technologies.
Gee, do I detect some tarnish on the once shiny surface? ;-)
A great deal of that shine was marketing hype, don't forget. Though
Java incorporates a number of good ideas (separate interfaces,
Unicode, automatic storage management, threads), the programming
elements of the language are minimal (presumably due to its early
target of smart toasters, or perhaps more accurately, set-top boxes).
Where Java is not being used for embedded systems or applet
applications, this minimality is not really useful, and will have
unfortunate negative effects on business measurements such as
time-to-market. The absence of multiple inheritance is really
unfortunate.
Michi Henning
> In article <Pine.HPX.4.05.981217...@bobo.triodia.com> Michi Henning <mi...@triodia.com> writes:
>
> Thinking about it a bit more though, you would have to make changes
> on the wire as well because the operation name is no longer guaranteed to
> uniquely identify the correct operation. But that could be done in a fairly
> non-intrusive manner. For example, you could send A::op and B::op as the
> operation name on the wire.
>
> Or, as we've discussed before, the repository ID of A or B, along with "op".
Yes, that would be better.
> The main problem I see is how to map it into languages such as C.
>
> Not a big deal -- A_op() and B_op(), much as C++ is A::op() and B::op().
Only one glitch here -- there are cases where this becomes ambiguous:
module A {
module B {
interface C {
void op();
};
};
};
and:
module A_B {
interface C {
void op();
};
};
However, in practice, I suspect that won't be a problem and you could
probably live with this, at least for C.
> The real problem is posed by crippled languages like Java, which lack most
> common customization technologies.
Gee, do I detect some tarnish on the once shiny surface? ;-)
Cheers,
Michi Henning
> Where Java is not being used for embedded systems or applet
> applications, this minimality is not really useful, and will have
> unfortunate negative effects on business measurements such as
> time-to-market. The absence of multiple inheritance is really
> unfortunate.
I agree. Add lack of parameterized types to that -- I think I miss those
more than MI.