IDL representation for XML
Ari Shapiro
I would like to replace the statically-defined structures in the IDL for
my CORBA application with a more flexible (albeit potentially slower)
XML interface.
In other words, today the application contains definitions such as the
following:
struct PurchaseOrder {
wstring PONumber;
wstring SupplierName;
long quantity;
double price;
};
If I could define format for XML within IDL, I could transfer XML data
in CORBA. This will allow me to change my PurchaseOrder structure
without changing the IDL. Of course, the client will need to interpret
the XML, but the gain in flexibility is tremendous.
If I define structures such as:
struct XMLAttribute {
wstring name;
wstring value;
};
struct XMLNode {
wstring nodeValue;
sequence<XMLAttribute> attributes;
sequence<XMLNode> children;
};
then I need to instantiate many objects even for the simplest XML tree.
To avoid instantiating too many objects, I could parse the XML on the
server and transfer that information to the client as raw binary data (a
la 'octet'), but this implies the same XML parser and implementation
language on the client.
Any suggestions?
Ari Shapiro
shapi...@yahoo.com
Michi Henning
> If I could define format for XML within IDL, I could transfer XML data
> in CORBA. This will allow me to change my PurchaseOrder structure
> without changing the IDL. Of course, the client will need to interpret
> the XML, but the gain in flexibility is tremendous.
Hmmm... Is it really? Suppose you replace
void some_op(in Type1 p1, in Type2 p2);
with
void someop(in wstring xml_string);
You can now define a DTD such that you can pass a pair of Type1 and Type2
values as an XML string some_op(). Now, if the data types change,
you can update things without recompiling the IDL. So far, so good.
But what next? You now need to update the client and the server to
use a different DTD, so they can parse the updated XML types.
So, I'm not exactly sure what you've gained so far -- both client and
server will need updating.
Another question that comes to mind is what happens if the XML string
passed to someop() is malformed (doesn't parse). The receiver of the
string now must handle this somehow. The details of how it does this
don't matter -- the point is that you will get some sort of run-time error.
In other words, the above IDL transformation to XML turns a compile-time
error into a run-time error.
Depending on your requirements, this may be fine; but be aware that the
system is now less type safe than with strongly-typed interfaces.
> To avoid instantiating too many objects, I could parse the XML on the
> server and transfer that information to the client as raw binary data (a
> la 'octet'), but this implies the same XML parser and implementation
> language on the client.
Well, what do you expect? There must be some contract between client and
server as to the shape and meaning of the data they exchange. Whether
that contract is provided by IDL or a DTD is largely irrelevant. By and
large, all such transformations will ever achieve is to trade
compile-time type safety against run-time type safety. The often-made
leap is that, somehow, this means that clients and servers
won't need to be relinked or recompiled. In practice, that rarely turns
out to be true, because even though you can now handle different data
values that are typed at run time, you still need new semantics in both
client and server as to what to do with that new data; this rarely happens
without requiring recompilation, unless you are completely meta-data driven
(which again is rare, because even in meta-data, there are typically
no semantics, only syntax).
The only time I have seen such trade-offs pay off is for applications
that are completely free of semantics (other than hardwired semantics that
are fixed for all time). An example would be a MIB browser that allows
get/set operations on agents and is completely meta-data driven. In that
case, the loose typing really is a gain because the browser is essentially
brainless and all the semantics are supplied by the user. In other words,
such a browser *is* an example where a change in meta-data is sufficient
to reconfigure the application. But, overall, such applications are rare.
Putting this differently, you can achieve something very similar to what
you suggest by using:
void someop(in any param);
You can now pack anything you like into the any parameter, and interpret
it at run time using DynAny. That's not all that different from using XML.
> If I define structures such as:
>
> struct XMLAttribute {
> wstring name;
> wstring value;
> };
>
> struct XMLNode {
> wstring nodeValue;
> sequence<XMLAttribute> attributes;
> sequence<XMLNode> children;
> };
>
> then I need to instantiate many objects even for the simplest XML tree.
Hmmm... Structures aren't objects (at least not in the CORBA sense of object).
instead, they are values. If you define the structures as shown and instantiate
a tree of such structures, sending the outermost structure will marshal
the entire tree.
Cheers,
Michi.
--
Michi Henning +61 7 3236 1633
Object Oriented Concepts +61 4 1118 2700 (mobile)
PO Box 372 +61 7 3211 0047 (fax)
Annerley 4103 mi...@ooc.com.au
AUSTRALIA http://www.ooc.com
Oliver Geisser
Ari Shapiro <shapi...@yahoo.com> schrieb in im Newsbeitrag: 3806C540...@yahoo.com...
> What would be the best way to define a standard XML interface in IDL?
>
> I would like to replace the statically-defined structures in the IDL for
> my CORBA application with a more flexible (albeit potentially slower)
> XML interface.
>
> In other words, today the application contains definitions such as the
> following:
>
> struct PurchaseOrder {
> wstring PONumber;
> wstring SupplierName;
> long quantity;
> double price;
> };
>
> If I could define format for XML within IDL, I could transfer XML data
> in CORBA. This will allow me to change my PurchaseOrder structure
> without changing the IDL. Of course, the client will need to interpret
> the XML, but the gain in flexibility is tremendous.
I had the same idea. But beware of the extra complexity mixing to "worlds".
You can get the best of the two worlds but you can also get the worse.
> If I define structures such as:
>
> struct XMLAttribute {
> wstring name;
> wstring value;
> };
>
> struct XMLNode {
> wstring nodeValue;
> sequence<XMLAttribute> attributes;
> sequence<XMLNode> children;
> };
>
> then I need to instantiate many objects even for the simplest XML tree.
Idea: Use the W3C DOM spec - it's allready defined in IDL. Then
you can remote access the DOM tree. But that will have a bad performance.
But you can rewrite the spec to use valuetypes (you will need an CORBA
2.3 ORB for that) and use the DOM implementing classes on both sides,
server and client. You can find sourcecode for DOM implementing classes
in many open-source XML parsers. You can use these classes as a base
for the valuetype implementing classes that you will need.
> To avoid instantiating too many objects, I could parse the XML on the
> server and transfer that information to the client as raw binary data (a
> la 'octet'), but this implies the same XML parser and implementation
> language on the client.
You can also transfer XML over a a binary stream (read/write octets)
and parse the XML on the client.
--
Oliver Geisser
CE Computer Equipment AG
Developement
Jonathan Biggar
>
> What would be the best way to define a standard XML interface in IDL?
I believe that the OMG just (or is just about to) issued an RFP for a
standard representation of XML data in OMG IDL. This would include the
ability to pick apart the XML-structured data, examine it, and
reassemble it however you like.
This will solve you problem, if you can wait about two years for it. :-)
--
Jon Biggar
Floorboard Software
j...@floorboard.com
j...@biggar.org
Bruce Blackshaw
Michi Henning wrote:
> [snip]
>
> Orthogonal to the above is the issue of static versus dynamic type safety.
> Something like XML (or any, or octet sequences) permit you to relax
> static type safety. What this gains you is extensibility and flexibility
> of the data that travels across the network, which in turn opens up
> versioning or evolution mechanisms that are harder to come up with in a
> statically and strongly typed system. The downside is that clients
> and servers have to do a lot more work at run time, namely, interpret the
> data. This is both less efficient and more dangerous (because mismatches
> in the client-server contract are harder to avoid in the first place and
> often difficult to handle when they happen).
In my experience of using XML with CORBA (sending XML structures as CORBA
strings), I certainly noticed this. The XML parser I was using incurred
considerable overhead. When I implemented the equivalent set of interfaces using
CORBA structs, I noticed quite a speed difference.
Another point is that often more code needs to be written to build and
dissassemble your XML. With Java, CORBA structs can be directly used in your
code, and I found my non-XML implementation was far less code and a lot cleaner.
Bruce Blackshaw
London, UK
Bill Janssen
Taking this concept further, if a general MS COM marshaller could also
package calls in the same XML format then COM and Corba system could play
together.
The key is ``the same XML format''. SOAP is basically DCOM protocol
data units (messages) encoded into XML. It's not the same as CORBA
encoded into XML would be.
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
Ara Kassabian
types) and XML have their places in a distributed architecture. By its nature,
IDL is intended to be rigid (the sole loophole being the any type). XML lies
somewhere between an any and an IDL struct. Because of the schema checking, it
affords many of the advantages of an IDL struct. On the other hand, since the
schema is encapsulated inside the XML document, it is less rigid than an IDL
struct.
Using XML in place of an any has a number of advantages:
1. An "any" can only contain datatypes that are known at compile time. DynAny
fixes this, but IMHO the necessary machinery is complicated and cumbersome. In
addition, DynAny is not supported by all ORBs. XML does not suffer from this
restriction.
2. Type checking is done at runtime. Therefore, the schema can evolve without
needing to change the IDL interface. This is a great advantage if one is
planning to upgrade only the server portion of one's system.
3. In my experience, I have found the implementation of the any datatype to be
buggy. For example, I ran into several bugs with any in Orbix 2.3 (many were
fixed in later patch releases). XML parsers appear to be less error prone,
particularly if one restricts oneself to relatively simple DTD hierarchies.
4. Although Michi correctly points out that there is a performance penalty due
to the need to parse the XML document at runtime, I must point out that "any" is
the most expensive data type to have in your IDL. Even so, I do not think the
penalty is that great so long as one does not abuse the technology (for example,
if every argument ot an IDL operation is an XML document, there clearly will be
performance issues).
Using XML instead of an IDL struct can also have a number of advantages:
1. Whereas the IDL struct externalizes the internal structure of the data, an
XML document encapsulates it inside the DTD. For example, many IDL interfaces
have a "getData" type operation, whose purpose is to return the data in a CORBA
object back to the client for display in some GUI. If one chooses to pass the
data back as an IDL struct, then one is breaking encapsulation in some sense,
since the internal structure of the object is in the IDL for all to see.
2. An XML document is more flexible than an IDL struct from a lifecycle point of
view. If it becomes necessary to change one of the members of the IDL struct
after the system has gone into production (or to add a member, let us say) the
IDL has to be updated and both client and server need to be recompiled. If the
data is sent as an XML document, it may be possible to only change the server or
to phase in the upgrade of the clients over a period of time (typically,
upgrading clients is a much more laborious process than upgrading the server).
Using XML has another advantage as well, in some situations: An XML document,
coupled with an XSL document, can be used to produce HTML. This could be used in
a client to directly create the GUI representation of the data with little
custom coding. All that is needed is a COTS component (JavaBean or COM control)
that is able to marry the XSL to the XML and render the resulting HTML. Used
intelligently, this can lead to very flexible GUIs, defined and updatable at
runtime with no need to update the client code.
This all being said, there clearly are times where an IDL struct is called for.
There may also be times when an IDL union is more appropriate. In general,
however, if I find myself needing a "chameleon" data type in my IDL, or if I
need to return a CORBA object's data to a client, I frequently choose to use
XML.
--------------------------------------------------------------------------------
----------------
Ara Kassabian
TechOne, Inc.
7677 Oakport Road
Oakland, CA 94621
http://www.techone.com
a...@techone.com
Note: The opinions expressed here are the author's own and do
not necessarily reflect those of TechOne, Inc.
--------------------------------------------------------------------------------
----------------
Bruce Blackshaw <bruce.b...@REMOVE.saudibank.THIS.com> wrote in message
news:380AD08A...@REMOVE.saudibank.THIS.com...
Michi Henning
> 2. Type checking is done at runtime. Therefore, the schema can evolve without
> needing to change the IDL interface. This is a great advantage if one is
> planning to upgrade only the server portion of one's system.
As I've said before, I think that argument is a red herring. The implication
of it appears to be that I can upgrade the server and change the data that
is exchanged via an interface without also having to upgrade the client.
That strikes me as patently naive. If the data has changed, how would an
old client suddenly and magically understand the new data? As I mentioned
previously, this only works if the client is truly thin, that is, implements
no semantics that depend on the data whatsoever.
> 3. In my experience, I have found the implementation of the any datatype to be
> buggy. For example, I ran into several bugs with any in Orbix 2.3 (many were
> fixed in later patch releases). XML parsers appear to be less error prone,
> particularly if one restricts oneself to relatively simple DTD hierarchies.
Well, Orbix has a long history of broken any implementations. Generalizing
from Orbix to other ORBs is probably inappropriate. I know a number of ORBs
that have had rock-solid any support for years. And, listening to a collegue
of mine who is something of an XML expert, I'm told that XML parsers all
parse a language not entirely unlike XML... In other words, the current state
of XML parsers appears to be rather sad, with different semantics provided by
different implementations. Naturally, that doesn't mean that there is
anything wrong with XML as such, only that current parser implementations
are less than perfect.
> 4. Although Michi correctly points out that there is a performance penalty due
> to the need to parse the XML document at runtime, I must point out that "any" is
> the most expensive data type to have in your IDL. Even so, I do not think the
> penalty is that great so long as one does not abuse the technology (for example,
> if every argument ot an IDL operation is an XML document, there clearly will be
> performance issues).
Someone else in this group (sorry, I forget who) mentioned a factor of 5
difference in performance. I'd call that a rather severe penalty (although,
as parsers mature, I would expect that penalty to decrease somewhat).
Note though that XML is by its nature a very verbose language. The additional
bandwidth consumed by XML may make its use impossible in bandwidth-restricted
environments, such as WANs.
> 1. Whereas the IDL struct externalizes the internal structure of the data, an
> XML document encapsulates it inside the DTD. For example, many IDL interfaces
> have a "getData" type operation, whose purpose is to return the data in a CORBA
> object back to the client for display in some GUI. If one chooses to pass the
> data back as an IDL struct, then one is breaking encapsulation in some sense,
> since the internal structure of the object is in the IDL for all to see.
No, I don't think this argument holds. The structure I return need not at
all reflect the internal structure of the object. And, even if it did, it
wouldn't matter because I can change the implementation of the object without
touching its interface.
> 2. An XML document is more flexible than an IDL struct from a lifecycle point of
> view. If it becomes necessary to change one of the members of the IDL struct
> after the system has gone into production (or to add a member, let us say) the
> IDL has to be updated and both client and server need to be recompiled. If the
> data is sent as an XML document, it may be possible to only change the server or
> to phase in the upgrade of the clients over a period of time (typically,
> upgrading clients is a much more laborious process than upgrading the server).
Again, that's something I don't understand. Suddenly, the client gets an
additional piece of data. What on earth will it do with it? At best, it
can ignore it; at worst, it will crash or get otherwise confused.
I do not believe that extensibility is something that XML has and IDL has not.
Rather, IDL can be just as extensible if you design for it. For example,
the versioning problem can be tackled quite well by trading for an interface
of the desired version. This allows me to add as many versions of an interface
as I need, but without any need to weaken static type safety.
People keep saying that IDL can't be versioned. Yes, that is true (the only
versioning in IDL itself is by derivation), but it doesn't mean that I can't
build systems with IDL that can't be versioned.
> Using XML has another advantage as well, in some situations: An XML document,
> coupled with an XSL document, can be used to produce HTML. This could be used in
> a client to directly create the GUI representation of the data with little
> custom coding. All that is needed is a COTS component (JavaBean or COM control)
> that is able to marry the XSL to the XML and render the resulting HTML. Used
> intelligently, this can lead to very flexible GUIs, defined and updatable at
> runtime with no need to update the client code.
Yes. That I would see as a really nice feature. However, it works only
if the client is essentially devoid of semantics (i.e. truly "thin"); as
soon as any processing is required on the client-side data, you can't upgrade
without updating the client code.
> This all being said, there clearly are times where an IDL struct is called for.
> There may also be times when an IDL union is more appropriate. In general,
> however, if I find myself needing a "chameleon" data type in my IDL, or if I
> need to return a CORBA object's data to a client, I frequently choose to use
> XML.
Nothing wrong with that and, no, I don't hate XML. It's just that suddenly,
XML is being touted as another silver bullet. Let's face it, languages
that include metadata have been around for a long time. They haven't been
a silver bullet in the past, and they won't be one in the future...
alfred...@my-deja.com
> On Sat, 23 Oct 1999, it was written:
>
> > 2. An XML document is more flexible than an IDL struct from a
lifecycle point of
> > view. If it becomes necessary to change one of the members of the
IDL struct
> > after the system has gone into production (or to add a member, let
us say) the
> > IDL has to be updated and both client and server need to be
recompiled. If the
> > data is sent as an XML document, it may be possible to only change
the server or
> > to phase in the upgrade of the clients over a period of time
(typically,
> > upgrading clients is a much more laborious process than upgrading
the server).
>
Michi Henning <mi...@ooc.com.au> wrote:
> Again, that's something I don't understand. Suddenly, the client gets
an
> additional piece of data. What on earth will it do with it? At best,
it
> can ignore it; at worst, it will crash or get otherwise confused.
Don't worry, Michi, any good XML parser will not crash
when an unknown tag is encountered. This argument is
just a red herring. We all know poorly written CORBA will
crash as well.
It is very useful for servers to support multiple versions
of clients without having to redeploy them. For example, a new
version of a server may add several new informational-only fields
or attributes to structs that new clients may want, and older
clients simply do not care about. XML handles this effortlessly.
Consider how newly defined tags and attributes in HTML 4 web pages
are merely ignored by HTML 3 browsers. Do not underestimate the
power of this subtle feature.
The thought that someone in this newsgroup wondered aloud
how much better the world would be if CORBA formed the
very fabric of the Internet instread of HTML is laughable.
The Internet would never have gotten off the ground if not
for the forgiving flexability and backwards compatability
that HTML provides. Sure, it's verbose and uses much more
bandwidth than IIOP - so what? It works very well and
it does not suffer from the brittleness and redeployment
annoyances of modified CORBA/IIOP interfaces.
>
> I do not believe that extensibility is something that XML has and IDL
has not.
> Rather, IDL can be just as extensible if you design for it. For
example,
> the versioning problem can be tackled quite well by trading for an
interface
> of the desired version. This allows me to add as many versions of an
interface
> as I need, but without any need to weaken static type safety.
>
> People keep saying that IDL can't be versioned. Yes, that is true (the
only
> versioning in IDL itself is by derivation), but it doesn't mean that I
can't
> build systems with IDL that can't be versioned.
Sure, anything is possible, but it does not mean it is simple.
People like simple. XML is simple. CORBA/IIOP is very brittle
to simple additions such as adding a new member to a struct.
In XML this is handled effortlessly - and most importantly older
clients continue to function - as is.
Sent via Deja.com http://www.deja.com/
Before you buy.
Serban Tatu
alfred...@my-deja.com wrote:
> The thought that someone in this newsgroup wondered aloud
> how much better the world would be if CORBA formed the
> very fabric of the Internet instread of HTML is laughable.
> The Internet would never have gotten off the ground if not
> for the forgiving flexability and backwards compatability
> that HTML provides. Sure, it's verbose and uses much more
> bandwidth than IIOP - so what? It works very well and
> it does not suffer from the brittleness and redeployment
> annoyances of modified CORBA/IIOP interfaces.
I don't get the above paragraph. How does HTML compare to IIOP? You are
probably talking about HTTP. But then, what kind of "backwards
compatibility" does HTTP offer? There are only two versions of it that I
have seen used. Again, you are probably confusing it with HTML.
Another thing: the fact that you encountered badly-evolving CORBA designs
does not warrant such harsh terms as "laughable" to describe efforts such as
the HTTP-NG.
Thanks,
Serban
Christopher B. Browne
<alfred...@my-deja.com> posted:
>> On Sat, 23 Oct 1999, it was written:
>Michi Henning <mi...@ooc.com.au> wrote:
>> Again, that's something I don't understand. Suddenly, the client gets
>>an additional piece of data. What on earth will it do with it? At best,
>>it can ignore it; at worst, it will crash or get otherwise confused.
>
>when an unknown tag is encountered. This argument is
>just a red herring. We all know poorly written CORBA will
>crash as well.
If XML-based applications consisted solely of an XML parser, *and nothing
else,* then your contention would have merit. (Paralleling the notion
that CORBA systems consist of an ORB, and nothing else...)
But the parser is *only one component.* It's pretty useless to have
something that merely parses input, and does nothing with it, right?
The code that interprets the semantics of what got parsed is as
vulnerable to "additional data" as it's written to be. That is true
whether we're talking about XML or CORBA.
--> If the system allocates extra memory to store the data that gets
ignored because the application doesn't know how to cope with it,
and then neglects to deallocate it when it goes away, this parallels
complexities of memory allocation in CORBA.
--> If the new data is really critical to the semantics of the message
being passed, while the system may not "crash," it's rather unlikely
that it will "do the right thing." This suggests that neither XML
nor CORBA are, in and of themselves, solutions to the "changing
protocols" problem.
>It is very useful for servers to support multiple versions
>of clients without having to redeploy them. For example, a new
>version of a server may add several new informational-only fields
>or attributes to structs that new clients may want, and older
>clients simply do not care about. XML handles this effortlessly.
>Consider how newly defined tags and attributes in HTML 4 web pages
>are merely ignored by HTML 3 browsers. Do not underestimate the
>power of this subtle feature.
... And if the IDL for a particular protocol provides some
informational-only elements, it may not be terribly difficult to deploy
this even with older clients. It would probably be implemented by using
DII so that the client "interprets" the data and does not require a
fixed IDL for a particular protocol.
Alternatively, it may make sense to attach hooks to methods that
optionally allow attaching extra elements that the client can examine
or ignore at will.
XML does not provide *clear* superiority in this manner.
>The thought that someone in this newsgroup wondered aloud
>how much better the world would be if CORBA formed the
>very fabric of the Internet instread of HTML is laughable.
>The Internet would never have gotten off the ground if not
>for the forgiving flexability and backwards compatability
>that HTML provides. Sure, it's verbose and uses much more
>bandwidth than IIOP - so what? It works very well and
>it does not suffer from the brittleness and redeployment
>annoyances of modified CORBA/IIOP interfaces.
... And *you* seem to be missing the point, thinking that a
particular language is "the fabric of the Internet."
HTML is *not* the "fabric of the Internet."
The things that form the "fabric of the Internet" include such
things as:
a) TCP/IP physical layers;
b) TCP and UDP protocols for data transfer;
c) Protocol layers such as SMTP, NNTP, NTP, HTTP, and IIOP.
XML has no entrance into those layers; it is not useful in networked
applications with those other layers. Ditto for HTML. Both are
application layers that sit many levels away from the physical fabric
of Internet networking hardware, and are *at least* one layer away from
the protocols via which data is transmitted across the Internet.
>> I do not believe that extensibility is something that XML has and IDL
>has not.
>> Rather, IDL can be just as extensible if you design for it. For
>example,
>> the versioning problem can be tackled quite well by trading for an
>interface
>> of the desired version. This allows me to add as many versions of an
>interface
>> as I need, but without any need to weaken static type safety.
>>
>> People keep saying that IDL can't be versioned. Yes, that is true (the
>only
>> versioning in IDL itself is by derivation), but it doesn't mean that I
>can't
>> build systems with IDL that can't be versioned.
>
>Sure, anything is possible, but it does not mean it is simple.
>People like simple. XML is simple. CORBA/IIOP is very brittle
>to simple additions such as adding a new member to a struct.
>In XML this is handled effortlessly - and most importantly older
>clients continue to function - as is.
CORBA might be argued to correspond to XML; there is *no* correspondence
between XML and IIOP, as the latter is a data communications protocol
that is better compared to HTTP or RPC or DCOM.
Lumping it all together and calling it "brittle" in comparison with XML
is silly. With XML, you have no transmission protocol, which implies
that it, in comparison, is not "less brittle;" in comparison, it is not
a useful network protocol because it does not include any network protocol
specification.
--
"The best design is not predicated on how brain-dead you can be and
still operate it." -- David C. Wright
cbbr...@ntlug.org- <http://www.hex.net/~cbbrowne/corba.html>
Don Box
news:y1ag0z8...@watson.parc.xerox.com...
> In article <memo.1999101...@jonhughes.compulink.co.uk>
jonh...@compulink.cix.co.uk (Jon Hughes) writes:
>
> Taking this concept further, if a general MS COM marshaller could also
> package calls in the same XML format then COM and Corba system could
play
> together.
>
> The key is ``the same XML format''. SOAP is basically DCOM protocol
> data units (messages) encoded into XML. It's not the same as CORBA
> encoded into XML would be.
I disagree. SOAP is very much NOT DCOM in XML. SOAP is much closer to IIOP
than DCOM. Consistent with CORBA/IIOP style, the SOAP wire protocol simply
specs out how to invoke a method against an endpoint/object. Unlike DCOM,
SOAP does not specify an activation protocol, multi-protocol negotiation or
distributed GC. True, SOAP specs out multi-reference data (like DCE, RMI and
more recent vintages of CORBA), but this to me does not make it DCOM-esque.
Just my 2 cents,
DB
http://www.develop.com/soap/soapfaq.xml
Don Box
"Jon Hughes" <jonh...@compulink.cix.co.uk> wrote in message
news:memo.1999101...@jonhughes.compulink.co.uk...
> In article <Pine.HPX.4.05.99101...@bobo.triodia.com>,
> mi...@ooc.com.au (Michi Henning) wrote:
>
> Your views make a lot of sense to me but I am interested to hear your
> thoughts on the converse of Ari Shapir's suggestion i.e. implementing a
> general mechanism that intercepts Corba interface calls at the client side
> and marshalling these via a Message Queue network in some XML notation.
>
> Obviously there is a big performance hit with this design but the
> objective would be to decouple client and server in the time dimension.
>
> Taking this concept further, if a general MS COM marshaller could also
> package calls in the same XML format then COM and Corba system could play
> together.
This is exactly the approach taken by SOAP. Check out
http://www.develop.com/soap for more info.
Don Box
"Michi Henning" <mi...@ooc.com.au> wrote in message
news:Pine.HPX.4.05.991017...@bobo.triodia.com...
> On Sat, 16 Oct 1999, Jon Hughes wrote:
>
> In general, there are several ways to get interoperability in a
heterogeneous
> distributed system:
>
> 1) Put all the functionality at the server side and create
> a standard protocol to access that functionality.
[snip]
>
> 2) Put the functionality wherever you like and control the execution
> environment of both client and server, with some standard
> protocol between them.
[snip]
>
> 3) Don't bother with a distribution platform and rely on a common
> protocol only.
>
> That's the TCP/IP approach (or basically the approach taken by
> every "standard" protocol, possibly application-level, such
> as telnet, CMIP, etc...) The upside is that you only have to
> impose minimal restrictions on the execution environments of
> client and server (they only need a protocol stack) and that,
> for application-level protocols, you can make things more
> efficient by tailoring the protocol to the application's needs,
> instead of using a single, one-size-fits all protocol.
>
> The downsides are many, mainly that you no longer have something
> that easily supports heterogeneous networking. You basically
> rewrite or port the source code for every deployment environment.
> And, of course, the "platform" doesn't give you a lot of help
> in this case, other than a raw communciations facility.
However, if the protocol is sufficiently ubiquitous there will already be
lots of support plumbing in place. In the case of HTTP, there is Apache,
Kiva, IIS, WebLogic, WebSphere, etc. In the case of XML, there are probably
3-5 times as many XML parsers as there are ORB products, and no one (to the
best of my knowledge) is charging money for them. Additionally, no one is
claiming that XML or HTTP are for homogeneous networking.
To me, not having your communications substrate impose a programming
environment is a feature, not a bug (yes, this is me saying this).
DB
http://www.develop.com/dbox
http://www.develop.com/soap/soapfaq.xml
Ara Kassabian
The main point that I was trying to get across was this: IDL is rigid and that
is often very good. XML is very flexible and that is also often very good.
Neither is a silver bullet. However, the combination can be extremely powerful
because the two technologies complement each other.
--------------------------------------------------------------------------------
----------------
Ara Kassabian
TechOne, Inc.
7677 Oakport Road
Oakland, CA 94621
http://www.techone.com
a...@techone.com
Note: The opinions expressed here are the author's own and do
not necessarily reflect those of TechOne, Inc.
--------------------------------------------------------------------------------
----------------
Christopher B. Browne <cbbr...@news.brownes.org> wrote in message
news:slrn81465a....@godel.brownes.org...
Don Box
> On Sat, 23 Oct 1999, Don Box wrote:
>
> > However, if the protocol is sufficiently ubiquitous there will already
be
> > lots of support plumbing in place. In the case of HTTP, there is Apache,
> > Kiva, IIS, WebLogic, WebSphere, etc. In the case of XML, there are
probably
> > 3-5 times as many XML parsers as there are ORB products, and no one (to
the
> > best of my knowledge) is charging money for them. Additionally, no one
is
> > claiming that XML or HTTP are for homogeneous networking.
>
> big difference. In particular, an XML parser provides only a minute
fraction
> of the functionality of an ORB, so the comparison is misleading, IMO.
Actually, I was implying that an HTTP server + XML parser ~= ORB. Sorry if
it came off otherwise. Additionally, most programming environments have
reasonable HTTP client support too.
> > To me, not having your communications substrate impose a programming
> > environment is a feature, not a bug (yes, this is me saying this).
>
> Hmmm... The example I cited was "raw" protocols, such as TCP/IP, or
> application-level protocols, such as telnet. With these, you have to do
> an awful lot of coding to get anywhere. This is the case for all
approaches
> that rely on protocol-only standards. The protocol may shield you from
> basic things, such as byte ordering, but that's about it.
>
> However, to write applications, you need more than just a protocol. You
need
> language bindings
I disagree. HTTP/HTML took off without a standard language mapping. XML took
off without a language binding too.
> (otherwise there is no source code portability between different vendors),
I think source portability between vendors is highly overrated when it comes
to programming environments - EJB is a great example of this. Yes, the
programmatic interfaces are fairly consistent, but the QoS that each
container delivers is radically different, rendering source portability
fairly useless.
> and you need higher-level abstractions, otherwise
> applications get bogged down in implementing things such as location
> transparency, server transparency, naming, and so on.
Ahhh, but look at what happened with CORBA. Folks went spec-happy and wound
up with DCE all over again. I think that the success of things like Java
Servlets and Active Server Pages is due largely to their simplicity - they
provide a basic communication/invocation mechanism with truly ubiquitous
support. You don't here lots of servlet developers clamoring for Trader,
Naming, Persistence, Lifecycle, Externalization, etc.
> My conjecture is that protocol-only approaches are no longer appropriate
> for modern applications because they require too much work.
With the advent of Java servlets (with or without XML), I no longer buy this
argument. I don't think most of the world buys it anymore either. It's a
scary fact, but the Hunter book on Servlets outsells your CORBA book and my
COM book by a large ratio. We've been discarded Michi ;-) ;-)
> The are
> appropriate only in unusual cases, such as as when portability doesn't
matter
> or you choose to code directly to the protocol to squeeze the last 3%
> of performance. For most applications, such considerations don't apply and
> ease of development is what matters. That's why platforms such as CORBA
and
> DCOM are popular. It also explains why DCE failed as an application
platform:
> the abstraction level wasn't high enough, meaning that writing DCE
> applications was too complex and and time consuming to be viable.
Ahh, but DCOM offers only slightly more than HTTP + XML in terms of services
or semantics.Also, if you look at the traffic on this list, it certainly
appears that the core ORB stuff gets used fairly heavily and that the
layered services get less attention from many developers.
Cheers,
DB
http://www.develop.com/dbox
Michi Henning
> However, if the protocol is sufficiently ubiquitous there will already be
> lots of support plumbing in place. In the case of HTTP, there is Apache,
> Kiva, IIS, WebLogic, WebSphere, etc. In the case of XML, there are probably
> 3-5 times as many XML parsers as there are ORB products, and no one (to the
> best of my knowledge) is charging money for them. Additionally, no one is
> claiming that XML or HTTP are for homogeneous networking.
This statement implicitly equates an XML parser to an ORB. There is a very
big difference. In particular, an XML parser provides only a minute fraction
of the functionality of an ORB, so the comparison is misleading, IMO.
> To me, not having your communications substrate impose a programming
> environment is a feature, not a bug (yes, this is me saying this).
Hmmm... The example I cited was "raw" protocols, such as TCP/IP, or
application-level protocols, such as telnet. With these, you have to do
an awful lot of coding to get anywhere. This is the case for all approaches
that rely on protocol-only standards. The protocol may shield you from
basic things, such as byte ordering, but that's about it.
However, to write applications, you need more than just a protocol. You need
language bindings (otherwise there is no source code portability between
different vendors), and you need higher-level abstractions, otherwise
applications get bogged down in implementing things such as location
transparency, server transparency, naming, and so on.
My conjecture is that protocol-only approaches are no longer appropriate
for modern applications because they require too much work. The are
appropriate only in unusual cases, such as as when portability doesn't matter
or you choose to code directly to the protocol to squeeze the last 3%
of performance. For most applications, such considerations don't apply and
ease of development is what matters. That's why platforms such as CORBA and
DCOM are popular. It also explains why DCE failed as an application platform:
the abstraction level wasn't high enough, meaning that writing DCE
applications was too complex and and time consuming to be viable.
Cheers,
Michi Henning
> Actually, I was implying that an HTTP server + XML parser ~= ORB. Sorry if
What's the ~= operator do? Bitwise not? If so, I don't see how the
bitwise not of HTTP + XML would be like CORBA. On the other hand, ~=
could mean assignment with the inverted bits of the ORB, but I doubt
that "HTTP server + XML parser" is an l-value :-)
> > Hmmm... The example I cited was "raw" protocols, such as TCP/IP, or
> > application-level protocols, such as telnet. With these, you have to do
> > an awful lot of coding to get anywhere. This is the case for all
> approaches
> > that rely on protocol-only standards. The protocol may shield you from
> > basic things, such as byte ordering, but that's about it.
> >
> > However, to write applications, you need more than just a protocol. You
> need
> > language bindings
>
> I disagree. HTTP/HTML took off without a standard language mapping. XML took
> off without a language binding too.
They also do an awful lot less than an ORB. Quite likely, that's why. And
the fact that something takes off doesn't mean that it's good or desirbale,
only that it's popular; there is a big difference. (Once upon a time,
we wrote assembly code, used troff for word processing, etc. We did it
because they were the only tools available, not because they were the
best possible or most desirable tools.)
> I think source portability between vendors is highly overrated when it comes
> to programming environments - EJB is a great example of this. Yes, the
> programmatic interfaces are fairly consistent, but the QoS that each
> container delivers is radically different, rendering source portability
> fairly useless.
I acknowledge that problem. CORBA suffers from that too, especially in
the services area. However, looking at a POA ORB, you truly get very good
source portability. And I do know quite a few customers who appreciate
source portability *a lot*.
> > and you need higher-level abstractions, otherwise
> > applications get bogged down in implementing things such as location
> > transparency, server transparency, naming, and so on.
>
> Ahhh, but look at what happened with CORBA. Folks went spec-happy and wound
> up with DCE all over again. I think that the success of things like Java
> Servlets and Active Server Pages is due largely to their simplicity - they
> provide a basic communication/invocation mechanism with truly ubiquitous
> support. You don't here lots of servlet developers clamoring for Trader,
> Naming, Persistence, Lifecycle, Externalization, etc.
Actually, I am not aware of many CORBA applications that do not use either
naming or trader, as well as both persistence and life cycle. Let's face it --
applications aren't very interesting as a rule if they forget everything
once you switch off the server, and they are also not very interesting if
you cannot create and remove objects. And, for any system of halfway
interesting size, naming or trading become essential, otherwise you can't
find your objects. The event and notification services are used a lot
too, as are security and OTS. DCE failed to provide many of these and
suffered the consequences. And the level of complexity of DCE is *much*
higher than that of CORBA. I've written DCE applications in the past
and I remember what a mess it was...
> > My conjecture is that protocol-only approaches are no longer appropriate
> > for modern applications because they require too much work.
>
> With the advent of Java servlets (with or without XML), I no longer buy this
> argument. I don't think most of the world buys it anymore either.
I don't think so. It is not feasible or desirable to have a protocol-only
approach for every application that needs to do something halfway
sophisticated. There are far too many other problems that need solving
in practice, and application developers need help with those.
> It's a
> scary fact, but the Hunter book on Servlets outsells your CORBA book and my
> COM book by a large ratio. We've been discarded Michi ;-) ;-)
Well, it happens to the best of us eventually :-)
> > It also explains why DCE failed as an application
> platform:
> > the abstraction level wasn't high enough, meaning that writing DCE
> > applications was too complex and and time consuming to be viable.
>
> Ahh, but DCOM offers only slightly more than HTTP + XML in terms of services
> or semantics.
Well, maybe that explains the lack of case studies and success stories
for large systems. No doubt, DCOM gets plenty of use on a small scale,
but I've honestly had a very hard time finding large deployments using DCOM.
(I came across one that was fairly serious a while ago at a conference.
That was the first one I found in nearly four years of looking...)
> Also, if you look at the traffic on this list, it certainly
> appears that the core ORB stuff gets used fairly heavily and that the
> layered services get less attention from many developers.
I don't think that's true, at least for the core services. Naming, trading,
events, notification, security, OTS, persistence... All these are important
and I see them used a lot. [ Yes, the query service or POS are probably
something one can do without :-) ]
It all depends on the industry and application area you are in. For example,
both the JIDM CMIP/CORBA bridge and the Telecom Logging Service are getting
a lot of attention in the telco world, and similar comments apply to quite
a few of the other domain-oriented services that the OMG have defined.
Don Box
>
> > Actually, I was implying that an HTTP server + XML parser ~= ORB. Sorry
if
>
> What's the ~= operator do? Bitwise not? If so, I don't see how the
> bitwise not of HTTP + XML would be like CORBA. On the other hand, ~=
> could mean assignment with the inverted bits of the ORB, but I doubt
> that "HTTP server + XML parser" is an l-value :-)
Sorry for the "just-in-time notation coining". I meant "approximately
equivalent to" with the emphasis on "approximately".
> > > Hmmm... The example I cited was "raw" protocols, such as TCP/IP, or
> > > application-level protocols, such as telnet. With these, you have to
do
> > > an awful lot of coding to get anywhere. This is the case for all
> > approaches
> > > that rely on protocol-only standards. The protocol may shield you from
> > > basic things, such as byte ordering, but that's about it.
> > >
> > > However, to write applications, you need more than just a protocol.
You
> > need
> > > language bindings
> >
> > I disagree. HTTP/HTML took off without a standard language mapping. XML
took
> > off without a language binding too.
>
> They also do an awful lot less than an ORB. Quite likely, that's why.
Hmmmm... more than an orb core? Both do:
a) Parameter marshaling. (XML-ization vs. IDL/IR-driven CDL-ization).
b) Server-side dispatching to user-defined code.
(CGI/mod_xxx/isapi/servlet/asp vs. POA)
These two are core, and are augmented by:
c) Rudimentary lifecycle management (both based on client-independent
passivation).
d) Rudimentary concurrency management.
As for "value-added" services, both add:
e) Transactions (ejb/asp vs. ots)
f) Security (https + OS dacls + ejb/mts roles vs. corba sec.)
We can disagree about the relative quality/elegance/utility of these
functions, but what do I get from an ORB that isn't offset by:
g) Hoards of bright developers working on a freely available,
cross-platform, widely deployed HTTP daemon (Apache).
h) Hoards of support engineers/system administrators familiar with popular
HTTP daemons (apache, iis).
i) Firewall/proxy support.
Please don't say type safety - proper use of XML over HTTP can yield type
safety comparable to IDL + CDL.
> And
> the fact that something takes off doesn't mean that it's good or
desirbale,
> only that it's popular; there is a big difference.
Unfortunately, popularity is a major factor in technology (see VHS vs. Beta,
Windows 3.x vs. MacOS). Popularity cannot make something good. Unpopularity
can make something undesirable however, if for no other reason that the
effects of a free market economy.
> (Once upon a time,
> we wrote assembly code, used troff for word processing, etc. We did it
> because they were the only tools available, not because they were the
> best possible or most desirable tools.)
Agreed. However, as we both know, many tools/languages were invented to
"help" developers and no one tool/language ever won. To think that the world
will move to CORBA or DCOM (or HTTP) is somewhat naive. That being said, I
think that the combination of HTTP and XML offer a reasonable alternative to
CORBA and DCOM for a large number of deployment scenarios - protocol-wise.
>
> > I think source portability between vendors is highly overrated when it
comes
> > to programming environments - EJB is a great example of this. Yes, the
> > programmatic interfaces are fairly consistent, but the QoS that each
> > container delivers is radically different, rendering source portability
> > fairly useless.
>
> I acknowledge that problem. CORBA suffers from that too, especially in
> the services area. However, looking at a POA ORB, you truly get very good
> source portability. And I do know quite a few customers who appreciate
> source portability *a lot*.
Of course - it's something we all want. And certainly solutions like
Servlets, apache modules, XML DOMs, SAX give us that on the HTTP side. The
beauty of the HTTP (and XML) story is that many APIs have flourished around
a single protocol - to me that is a feature. As long as I gen/parse the
packets correctly, I have the freedom to choose radically different
runtime/apis rather than having to converge on a single programming
standard. Wire-level interop is mandatory. Source-level/in-memory-level
interop is optional.
> > > and you need higher-level abstractions, otherwise
> > > applications get bogged down in implementing things such as location
> > > transparency, server transparency, naming, and so on.
> >
> > Ahhh, but look at what happened with CORBA. Folks went spec-happy and
wound
> > up with DCE all over again. I think that the success of things like Java
> > Servlets and Active Server Pages is due largely to their simplicity -
they
> > provide a basic communication/invocation mechanism with truly ubiquitous
> > support. You don't here lots of servlet developers clamoring for Trader,
> > Naming, Persistence, Lifecycle, Externalization, etc.
>
> Actually, I am not aware of many CORBA applications that do not use either
> naming or trader,
Ahhh but look at an IOR and you see why. HTTP-based apps leverage URIs and
DNS for naming functionality. Trader-style needs to be crufted by hand
however, although this is certainly doable (one could even wrap access to a
CORBA trader daemon behind HTTP of one was so inclined).
> as well as both persistence and life cycle.
HTTP programmers typically use databases for persistence - this is both good
and bad however it is not mandated by the protocol, just by a common need to
interop with existing information in an organization.
>Let's face it --
> applications aren't very interesting as a rule if they forget everything
> once you switch off the server,
Agreed, especially if your server switches itself off all by itself from
time to time ;-) ;-)
> and they are also not very interesting if
> you cannot create and remove objects.
Disagreed ;-) If we are talking about admin, then yes, it is important to
be able to adminster a server and install/uninstall/configure server-based
applications. No question. If we are talking about managing server-side
sessions, again, we agree that this is important. If we are talking about
allowing arbitrary creation/deletion of language-level objects in a server
daemon, then I think we disagree. DCOM is often denegrated by CORBA folks
for mandating this. I have come to agree with the CORBA folks on this (if
you counter by defending RMI/DCOM-style pinging then we need to stop to
avoid confusing folks on this list).
> And, for any system of halfway
> interesting size, naming or trading become essential, otherwise you can't
> find your objects.
Naming certainly, however, URLs have served folks fairly well. A fair amount
of engineering has been invested into making DNS names (and even IP
addresses) sharable by multiple server boxes. As for identifying
"instances", the URL does have some space after the first forward slash for
such things.
> The event and notification services are used a lot
> too, as are security and OTS.
HTTP doesn't mean you don't get to use security and transactions (in fact,
most HTTP-based apps do). I agree, however, that a lot of folks working with
HTTP right now wish they had callbacks to do eventing/notification-style
stuff. The solutions are inelegant due to the client->server bias of HTTP
support infrastructure (proxies/firewalls) and to a much lesser degree the
protocol itself.
> DCE failed to provide many of these and
> suffered the consequences. And the level of complexity of DCE is *much*
> higher than that of CORBA.
I think DCE failed more due to complexity than due to lack of services,
don't you? However, I think that same complexity lives on in both CORBA and
DCOM. Both imply non-trivial cognitive overhead due to the surface area of
their respective runtimes, which limits the number of developers that can
really grok the technology. Folks on this list (like the DCOM list on discus
s.microsoft.com) represent the minority of developers - we're the
enthusiasts. The great unwashed just look at our technologies and wonder why
they can't send std::vector or java.util.Vector as a method parameter
-( ;-(
>
> > > My conjecture is that protocol-only approaches are no longer
appropriate
> > > for modern applications because they require too much work.
> >
> > With the advent of Java servlets (with or without XML), I no longer buy
this
> > argument. I don't think most of the world buys it anymore either.
>
> I don't think so. It is not feasible or desirable to have a protocol-only
> approach for every application that needs to do something halfway
> sophisticated. There are far too many other problems that need solving
> in practice, and application developers need help with those.
Which is why the free-market rushes to fill that void with plumbing like
Servlets, Apache, ASP, etc.
>
> > > It also explains why DCE failed as an application
> > platform:
> > > the abstraction level wasn't high enough, meaning that writing DCE
> > > applications was too complex and and time consuming to be viable.
I think DCE failed because:
a) It was too early
b) The IDL was too C-like and flexible, especially wrt pointers.
c) Handle management was too flexible and folks couldn't deal with the
choices.
d) OSs of the time weren't ready with things like threads or security
(setuid/chmod doesn't count ;-))
e) One couldn't easily find freely available plumbing for their
programming environment of choice.
f) The proportion of consumers that could make DCE calls was fairly
small, making it a backend solution.
g) It was too early (this one is important).
DCE was doomed. CORBA and DCOM came at a much better time in history,
however, they have both been marginalized as client->server protocols by
HTTP. Netscape and Microsoft both tried to make CORBA/DCOM the dominant
protocols of the Internet and both gave up. Because they both gave up, the
supporting firewall infrastructure never adapted to these protocols and they
are relegated to server->server communications. We can argue about the
technical merits of this reality, but I think we both agree that it is a
reality, yes? I think where we really disagree (correct me if I am wrong) is
the relative importance of the server-side protocol stack and supporting
runtime once we come across an HTTP gateway such as Apache or IIS. I think
that you believe a unified runtime and programming model (a la POA) is
important. I believe that the world doesn't want this and prefers relative
chaos. Why else do technologies like Servlets, EJB, COM+ etc. continue to
exist in the face of the "one true answer" that the OMG handed down years
ago?
> > Ahh, but DCOM offers only slightly more than HTTP + XML in terms of
services
> > or semantics.
>
> Well, maybe that explains the lack of case studies and success stories
> for large systems. No doubt, DCOM gets plenty of use on a small scale,
> but I've honestly had a very hard time finding large deployments using
DCOM.
> (I came across one that was fairly serious a while ago at a conference.
> That was the first one I found in nearly four years of looking...)
Hey, MS only has "evangelists". OMG has "PR Specialists" ;-)
We've had this conversation before. In NT-dominant shops, people choose
COM/DCOM/MTS/COM+. In cross-platform shops, people choose CORBA/IIOP over
DCOM consistently (for good reasons). However, for mainstream server apps,
folks have rejected CORBA and DCOM as client->server access protocols and
adopted HTTP. Are there internal IT apps that use DCOM or CORBA? Yes. Will
telcos switch to DCOM or HTTP anytime soon? No. However, there are a ton of
developers who don't write telephone switches or flight control systems and
for them, HTTP is often a more suitable solution than DCOM or CORBA.
Cheers,
DB
http://www.develop.com/dbox
Ara Kassabian
am starting to come around more and more to Don's position. I am working for a
large CORBA shop and I can tell you that, at least here, only the core ORB, the
Naming Service and (in some cases) OTS are used with any degree of frequency.
Neither POS nor Lifecycle are used except as design patterns (if that). "Bare"
MQ is preferred over either the Event or the Notification services. The Trader
service is nowhere to be seen. Maybe other shops are different. It may also be
that enterprise-ready CORBA services are a relatively new thing, so large
organizations are slow to use them.
However, speaking from the point of view of the "down in the trenches" manager,
who has to consider support and implementation issues in addition to pure
architectural isses, I must say that HTTP + JSP/servlets + one or more of XML,
HTML, EJB and other "mainstream" Internet technologies (like LDAP, etc.) offers
a number of advantages from the point of view of implementation and product
support:
1. IT support personnel are much more familiar with setting up and maintaining a
Web server than they are at supporting CORBA systems.
2. Internal organization firewalls can get in the way of CORBA servers while the
HTTP port is left open as a matter of course.
3. There are many more COTS load balancing/fault tolerance products for HTTP
servers than for CORBA servers (and, yes, I know you can use the NS/Trader
services to implement load balancing, but many aspects of client-side failover
must still be programmed by hand in a CORBA system).
4. SSL implementations must be implemented by buying ORB add-ons for most
commercial ORB products, while HTTPS comes "for free" with most Web servers.
5. CORBA Security services are either not available or not well integrated into
existing security mechanisms (which frequently consist of the rudimentary
username/password). For that reason, the security part of all the systems that I
have implemented have all been based on custom, username/password based
solutions (again, other people's experience may be different).
6. The time-to-production of many "vanilla" HTML/HTTP is quite a bit shorter
than that of a CORBA system--primarily due to the wide availability of helper
products for such applications. In my experience, 60-80% of internal products
are "vanilla": e-mail, database retrieval and data integration, etc. It is only
the remaining 20-40% that are complicated enough and critical enough that they
simply could not be done in HTTP/HTML.
Please understand: I am not putting down CORBA. After all, it is my
bread-and-butter and how I make my money. I am just pointing out that, at this
point in time, there is still a substantial learning curve to get over from the
point of view of maintainability and supportability.
--------------------------------------------------------------------------------
----------------
Ara Kassabian
TechOne, Inc.
7677 Oakport Road
Oakland, CA 94621
http://www.techone.com
a...@techone.com
Note: The opinions expressed here are the author's own and do
not necessarily reflect those of TechOne, Inc.
--------------------------------------------------------------------------------
----------------
Don Box <db...@develop.com> wrote in message
news:7v16vj$rag$1...@holly.prod.itd.earthlink.net...
Bill Janssen
The main point that I was trying to get across was this: IDL is rigid and that
is often very good. XML is very flexible and that is also often very good.
Neither is a silver bullet. However, the combination can be extremely powerful
because the two technologies complement each other.
Actually, XML is no more flexible than IDL is. It's just differently
flexible. In that sense, you're right -- the two technologies
complement each other. That's why it's great that CORBA passes XML
documents as parameters quite nicely, so that you can use XML-based
parameters where necessary.
Bill Janssen
"Bill Janssen" <jan...@parc.xerox.com> wrote in message
> SOAP is basically DCOM protocol data units (messages) encoded into XML.
I disagree. SOAP is very much NOT DCOM in XML.
Well, things might have changed (though I doubt it). I'm basing my
evaluation on SOAP specs I saw 3Q98. You're right in that some of the
DCOM specifics are not spelled out, but I presume that's because SOAP
is really (as you say) only part of the story: how to invoke a method
against an endpoint, a description of a wire protocol. I'd assume
that the normal DCOM machinery would be used for the other elements
you mention (activation, distributed GC, etc.).
Bear in mind that that I like DCOM, technically. I still think it's
got a better design, technically, than CORBA. It would be a shame if
SOAP, in addition to providing a laughably inefficient wire protocol,
blew the systems engineering that already exists.
Don Box
> In article <7utd8m$a5m$1...@holly.prod.itd.earthlink.net> "Don Box"
<db...@develop.com> writes:
>
> "Bill Janssen" <jan...@parc.xerox.com> wrote in message
> > SOAP is basically DCOM protocol data units (messages) encoded into
XML.
>
> I disagree. SOAP is very much NOT DCOM in XML.
>
> Well, things might have changed (though I doubt it). I'm basing my
> evaluation on SOAP specs I saw 3Q98.
The current SOAP spec shares very little with the original SOAP spec which
was drafted in 1Q98. That one definitely read like "DCOM in XML" however
none of the "DCOM-esque" aspects of that version of SOAP still exist. Why
you would doubt that the spec would change after 18 months escapes me
however.
> You're right in that some of the
> DCOM specifics are not spelled out, but I presume that's because SOAP
> is really (as you say) only part of the story: how to invoke a method
> against an endpoint, a description of a wire protocol. I'd assume
> that the normal DCOM machinery would be used for the other elements
> you mention (activation, distributed GC, etc.).
Not to sound like a broken record, but SOAP doesn't mandate or prohibit
folks from layering that stuff on top of SOAP. My personal hope is that SOAP
gets folks to live without distributed GC, but that's just one man's dream
;-)
> Bear in mind that that I like DCOM, technically. I still think it's
> got a better design, technically, than CORBA. It would be a shame if
> SOAP, in addition to providing a laughably inefficient wire protocol,
SOAP specs method invocation over HTTP using XML as the DEFAULT marshaling
protocol. One could quite easily use CDR, NDR, Java Serialization, or some
other syntax (wbxml from WAP comes to mind). To me, the most important
aspect of SOAP is the standardization of HTTP headers. XML is just one
syntax one could use. Implementing NDR would be trivial on NT given the
built-in support from the OS. Ditto for Java serialization in any JVM.
> blew the systems engineering that already exists.
I personally think a lot of the baggage DCOM and RMI (and to a lesser degree
CORBA) bring to a protocol could be lost without severe side-effects. Once
you factor in things like EJB, MTS and MOM, the argument for letting classic
OO programming mandate a protocol makes even less sense.
Martin v.Loewis
Don Box <db...@develop.com> wrote:
>Not to sound like a broken record, but SOAP doesn't mandate or prohibit
>folks from layering that stuff on top of SOAP. My personal hope is that SOAP
>gets folks to live without distributed GC, but that's just one man's dream
>;-)
The impression that SOAP spec gives that it allows easy interoperability
between "architectures". Base on your comments, it seems that this is a
non-goal, though: If people put distributed GC, and QueryInterface calls
on top of it, they already assume that the world inherits from IUnknown.
That won't give you interoperability to non-COM applications. But then, if
you have to use COM on top of SOAP anyway (or CORBA, for that matter), what
is the purpose of SOAP, then? It would be certainly more convenient for
application developers to use the language bindings provided by COM and
CORBA, wouldn't it?
Same goes for marshalling. If you say XML is just one choice (where others
are CDR, NDR, and RMI wire formats): Isn't that an interoperability
nightmare? If my SOAP-for-Java decides to use RMI, it still won't
interoperate with my SOAP-aware LISP ORB (even if they share the same
CDL spec), would it?
Puzzled,
Martin
Don Box
news:7v4tkv$6fj$1...@news.cs.tu-berlin.de...
> In article <7v2sr9$hld$1...@holly.prod.itd.earthlink.net>,
> Don Box <db...@develop.com> wrote:
> >Not to sound like a broken record, but SOAP doesn't mandate or prohibit
> >folks from layering that stuff on top of SOAP. My personal hope is that
SOAP
> >gets folks to live without distributed GC, but that's just one man's
dream
> >;-)
>
> The impression that SOAP spec gives that it allows easy interoperability
> between "architectures". Base on your comments, it seems that this is a
> non-goal, though:
Wow. Sorry if I gave you that impression.
> If people put distributed GC, and QueryInterface calls
> on top of it, they already assume that the world inherits from IUnknown.
I disagree. SOAP is about method invocation. Period. We anticipate that
folks will layer all kinds of proprietary one-off stuff on top of it, just
as they do today with COM and CORBA. That's all I was saying.
> That won't give you interoperability to non-COM applications.
Actually, having distributed GC or protocol negotiation via casts is not
specific to COM (rmi has both fwiw, as does dce to a limited degree). Along
those lines, it is quite possible in SOAP to provide protocol negotiation in
a way that interops with SOAP implementations that do not know about them.
All of this being said, SOAP doesn't require/mandate/sanction any of this.
When carried to the next degree, your argument could be extended to assume
that allowing folks to define user-defined interfaces inherently stops
interop. This is not the case.
> But then, if
> you have to use COM on top of SOAP anyway (or CORBA, for that matter),
what
> is the purpose of SOAP, then?
SOAP is a protocol. Period. Various companies (Iona, RogueWave,
DevelopMentor, UserLand, and Microsoft) are building SOAP support into
various ORB/web-server architectures. You don't "have to" use anything to do
soap. Some folks will use strcat/strtok and sockets. Others will use
off-the-shelf XML parsers and HTTP software such as apache/libwww. Still
others will use the SOAP support built into their ORB. The beauty of XML-RPC
technologies (such as SOAP) is that they don't attempt to solve world
hunger. Rather, they just define a minimal protocol that you can generate
and consume however you want, leveraging tons of existing software (such as
Apache and XML parsers) rather than defining yet another object runtime
system (a la EJB, POA or COM+).
> It would be certainly more convenient for
> application developers to use the language bindings provided by COM and
> CORBA, wouldn't it?
Convenient yes, however, not mandatory. Both observations are equally
important.
> Same goes for marshalling. If you say XML is just one choice (where others
> are CDR, NDR, and RMI wire formats): Isn't that an interoperability
> nightmare?
This is an HTTP-ism. Technically, SOAP is the application of the mime
content type "text/xml-SOAP" to HTTP. However, one could easily build
transfer syntax negotiation on top of this leveraging current HTTP practice.
This is no different than say an ORB product using IIOP to bootstrap and
then negotiating a more optimized protocol after the first method
invocation.
> If my SOAP-for-Java decides to use RMI, it still won't
> interoperate with my SOAP-aware LISP ORB (even if they share the same
> CDL spec), would it?
If your SOAP implementation talked RMI, then it wouldn't be using SOAP. If,
however, during the first method call, your SOAP implementation discovered
that the other end could also speak some other protocol, then technically
they could continue the conversation using something else, but again, that
is not SOAP. That would be something someone would layer over SOAP, probably
using either HTTP headers or SOAP headers (which are semantically close to
GIOP service contexts or DCOM ORPCTHIS/THAT).
> Puzzled,
> Martin
Sorry if my posts have confused you,
DB
http://www.develop.com/dbox
Bill Janssen
> Well, things might have changed (though I doubt it). I'm basing my
> evaluation on SOAP specs I saw 3Q98.
The current SOAP spec shares very little with the original SOAP spec which
was drafted in 1Q98. That one definitely read like "DCOM in XML" however
none of the "DCOM-esque" aspects of that version of SOAP still exist. Why
you would doubt that the spec would change after 18 months escapes me
however.
Sorry, Don, you're right. I'll take a look at the current spec and
comment on that.
Michi Henning
> Sorry for the "just-in-time notation coining". I meant "approximately
> equivalent to" with the emphasis on "approximately".
I was only half serious. But I still don't think that HTTP + XML comes
anywhere near CORBA in terms of functionality. CORBA does a lot more than
that.
> a) Parameter marshaling. (XML-ization vs. IDL/IR-driven CDL-ization).
> b) Server-side dispatching to user-defined code.
> (CGI/mod_xxx/isapi/servlet/asp vs. POA)
>
> These two are core, and are augmented by:
>
> c) Rudimentary lifecycle management (both based on client-independent
> passivation).
> d) Rudimentary concurrency management.
I think the emphasis should be on rudimentary here. In addition, the
difficulty of retaining state on the server side with HTTP gets in the way
big time.
There are lots of things missing though: location transparency, server
migration, server activation on demand, servant activation, flexible
life cycle management for servants, threading models, etc. And I haven't
said anything about services yet...
> We can disagree about the relative quality/elegance/utility of these
> functions, but what do I get from an ORB that isn't offset by:
>
> g) Hoards of bright developers working on a freely available,
> cross-platform, widely deployed HTTP daemon (Apache).
> h) Hoards of support engineers/system administrators familiar with popular
> HTTP daemons (apache, iis).
> i) Firewall/proxy support.
HTTP isn't RPC. I thought people would have found out the hard way by now...
Hordes of developers working on Apache are going to make a great Apache
server, no doubt. But that doesn't necessarily reduce my development time
or enable me to easily intergrate across languages, operating systems,
and hardware platforms.
> Please don't say type safety - proper use of XML over HTTP can yield type
> safety comparable to IDL + CDL.
I don't think I ever claimed that XML wasn't type safe. I did say, however,
that it trades static type safety against run-time type safety. That's
not always a good trade-off, depending on the situation. As a rule, I prefer
statically type safe interfaces (as do a good many other people). With
CORBA, you can choose whether you want to have things typed statically
or dynamically.
Performance is also an issue. A recent conversation with a fellow developer
here indicates that during a switch from a CORBA/IIOP implementation to
an XML-based transport, performance dropped by a factor of 50! This may
not be a representative figure, but I have anecdotal evidence from a number
of sources now who all claim that XML is *much* slower. (Not surprising,
considering how it throws bandwidth around, not to mention all the work
that needs to be done at run time.)
> However, as we both know, many tools/languages were invented to
> "help" developers and no one tool/language ever won. To think that the world
> will move to CORBA or DCOM (or HTTP) is somewhat naive. That being said, I
> think that the combination of HTTP and XML offer a reasonable alternative to
> CORBA and DCOM for a large number of deployment scenarios - protocol-wise.
Well, I'm not saying that HTTP and XML are useless or nonsense. But I am
saying that they are not a general CORBA or DCOM replacement, just as
CORBA or DCOM aren't HTTP and XML replacements. They do different things
in different ways. I think the trick is to choose the one that is appropriate
for what I want to do, not to run around blindly shouting "X is better than Y."
People keep looking for such messages, unfortunately, no matter that they
inevitably turn out to be wrong in at least half the number of cases...
> Of course - it's something we all want. And certainly solutions like
> Servlets, apache modules, XML DOMs, SAX give us that on the HTTP side. The
> beauty of the HTTP (and XML) story is that many APIs have flourished around
> a single protocol - to me that is a feature. As long as I gen/parse the
> packets correctly, I have the freedom to choose radically different
> runtime/apis rather than having to converge on a single programming
> standard. Wire-level interop is mandatory. Source-level/in-memory-level
> interop is optional.
Right. That may be true for you. However, go and sell that story to a large
customer who is sitting on many million dollars worth of software development
effort and is forced to switch platforms for some reason. They are decidedly
unimpressed when you tell them that they can go and rewrite all their code...
Source code portability is *important* to a lot of people.
> Ahhh but look at an IOR and you see why. HTTP-based apps leverage URIs and
> DNS for naming functionality. Trader-style needs to be crufted by hand
> however, although this is certainly doable (one could even wrap access to a
> CORBA trader daemon behind HTTP of one was so inclined).
The INS spec introduced corbaname URLs. Something like
corbaname:myhost.mydomain/somename
gets me to my object.
> > as well as both persistence and life cycle.
>
> HTTP programmers typically use databases for persistence - this is both good
> and bad however it is not mandated by the protocol, just by a common need to
> interop with existing information in an organization.
Huh? I think we missed each other. CORBA doesn't mandate anything about
how to do persistence in the protocol. However, it does offer a way that
makes it easy to persistify objects in a database if that's what you want.
That's better than having to craft SQL queries together or traversing
on-disk data structures explicitly in the code.
> Agreed, especially if your server switches itself off all by itself from
> time to time ;-) ;-)
What's that supposed to mean? CORBA offers transparent server activation
and deactivation (I think DCOM does too?) That's a damn sight better than
DCE, which expected every server to be up all the time. Or are you talking
about crashing servers? If so, I'm sure I can write a server that crashes
in any language and using any platform... ;-)
> > and they are also not very interesting if
> > you cannot create and remove objects.
>
> Disagreed ;-) If we are talking about admin, then yes, it is important to
> be able to adminster a server and install/uninstall/configure server-based
> applications. No question. If we are talking about managing server-side
> sessions, again, we agree that this is important. If we are talking about
> allowing arbitrary creation/deletion of language-level objects in a server
> daemon, then I think we disagree. DCOM is often denegrated by CORBA folks
> for mandating this. I have come to agree with the CORBA folks on this (if
> you counter by defending RMI/DCOM-style pinging then we need to stop to
> avoid confusing folks on this list).
I'm not sure I follow you. I am not aware of any interesting system that
doesn't require life cycle management for persistent objects. After all,
what good is a document database if you can't add and remove documents?
I don't see where pinging comes into this (and we can have an argument
about that separately ;-)
> Naming certainly, however, URLs have served folks fairly well. A fair amount
> of engineering has been invested into making DNS names (and even IP
> addresses) sharable by multiple server boxes. As for identifying
> "instances", the URL does have some space after the first forward slash for
> such things.
Yes. On the other hand, I would say that URL's have been spectacularly
subfunctional. Pretty much no way to move anything without breaking things.
Again, I believe that URLs are another expression of the syndrome of
"well, it sucks, but it's the only thing going". If we had URNs (which
are much closer to CORBA IORs than URLs), no-one would be using URLs...
> > DCE failed to provide many of these and
> > suffered the consequences. And the level of complexity of DCE is *much*
> > higher than that of CORBA.
>
> I think DCE failed more due to complexity than due to lack of services,
> don't you?
I'm not sure. I think it was a combination of both. The complexity was
certainly a major factor. But the lack of location, server, and protocol
transparency are killer issues for large systems.
> However, I think that same complexity lives on in both CORBA and
> DCOM. Both imply non-trivial cognitive overhead due to the surface area of
> their respective runtimes, which limits the number of developers that can
> really grok the technology. Folks on this list (like the DCOM list on discus
> s.microsoft.com) represent the minority of developers - we're the
> enthusiasts. The great unwashed just look at our technologies and wonder why
> they can't send std::vector or java.util.Vector as a method parameter
> -( ;-(
Yes, there is a price to pay for all the power, no-one denies that. However,
I strongly claim that all the power isn't possible without the complexity.
In other words, by the time you've made HTTP + XML do all the things
developers need for real-life systems, HTTP + XML will be just as complex;
it's inevitable. What annoys me is that catch-cry of "look at how easy
this is!", with no-one crying "yes, and did you notice how little it can do?"
> > I don't think so. It is not feasible or desirable to have a protocol-only
> > approach for every application that needs to do something halfway
> > sophisticated. There are far too many other problems that need solving
> > in practice, and application developers need help with those.
>
> Which is why the free-market rushes to fill that void with plumbing like
> Servlets, Apache, ASP, etc.
Busily adding more complexity. And, please, don't tell me that ASP is simple!
> DCE was doomed. CORBA and DCOM came at a much better time in history,
> however, they have both been marginalized as client->server protocols by
> HTTP.
It depends on where you look. There are plenty of systems that are built
with CORBA and that you wouldn't dream of building with HTTP. Of course,
the converse is just as true. There are systems that are better built
with HTTP. If you are talking in terms of numbers, no doubt, there are
more HTTP-based systems around that CORBA or DCOM ones. On the other hand,
the web explosion resurrected the old hammer and nail syndrom: if all
you have is HTTP, everything looks like a foot...
> Netscape and Microsoft both tried to make CORBA/DCOM the dominant
> protocols of the Internet and both gave up.
Actually, I disagree with that. I'm not aware that either company ever
wanted to ursurp the Internet set of protocols, or that the OMG tried
to do that either. Instead, CORBA has a quite clearly defined charter,
namely to provide an open OO platform for distributed heterogeneous systems.
CORBA does that extremely well, IMO, and I am not aware of anything else
that comes anywhere near CORBA's degree of easy when I want to integrate
Palm Pilots, mainframes, PCs, multiple operating systems, legacy apps, etc.
> Because they both gave up, the
> supporting firewall infrastructure never adapted to these protocols and they
> are relegated to server->server communications. We can argue about the
> technical merits of this reality, but I think we both agree that it is a
> reality, yes?
I agree to the extent that CORBA was slow to deal with the firewall issue
and that, as a result, vendors were slow to adapt. The firewall spec is
out now so, hopefully, that bottleneck will be eliminated.
> I think where we really disagree (correct me if I am wrong) is
> the relative importance of the server-side protocol stack and supporting
> runtime once we come across an HTTP gateway such as Apache or IIS. I think
> that you believe a unified runtime and programming model (a la POA) is
> important.
Yes, I think that this is certainly important. More than the programming
model though, I think CORBA's value lies in how easy it is to solve
what until very recently was a very difficult (and usually intractable)
problem, namely how to write robust heterogeneous distributed applications.
> I believe that the world doesn't want this and prefers relative
> chaos. Why else do technologies like Servlets, EJB, COM+ etc. continue to
> exist in the face of the "one true answer" that the OMG handed down years
> ago?
I think in part it is because of the Web/Java craze and the hammer and
nail syndrome. People are forever looking for the one true answer, and
there simply isn't one. In their misguided search for the one true answer,
they con themselves into believing that they have found it in technology X
and promptly proceed to use technology X for all sorts of things it is
ill suited for. Partly, that's human nature, and I don't see it changing
any time soon, if ever. Partly, it is sheer ignorance...
> We've had this conversation before. In NT-dominant shops, people choose
> COM/DCOM/MTS/COM+. In cross-platform shops, people choose CORBA/IIOP over
> DCOM consistently (for good reasons).
That sounds like a very solid choice to me and, in fact, that is the choice
I've continously been advocating.
> However, for mainstream server apps,
> folks have rejected CORBA and DCOM as client->server access protocols and
> adopted HTTP. Are there internal IT apps that use DCOM or CORBA? Yes. Will
> telcos switch to DCOM or HTTP anytime soon? No.
Don't bet too much on that. CORBA use in telcos is big and growing at
a furious pace.
> However, there are a ton of
> developers who don't write telephone switches or flight control systems and
> for them, HTTP is often a more suitable solution than DCOM or CORBA.
Sure. If all I want is a simple interface to some back-end functionality,
by all means, use HTTP and cgi-bin. That's what they are good for.
I never said that HTTP is bad per se. What I am saying is that HTTP is
getting abused and shoe-horned into doing all sorts of things it is
singularly ill-suited for (like stateful interactions). Why on earth
insist on using such a poor tool when there are better ones around?
Why on earth use something that requires a new TCP/IP connection for
every tiny interaction? This is insanely expensive (not to mention that
the cgi-bin contortions you have to go through simply suck).
And I still don't understand why I would want to use XML for RPC. As
a protocol, it's about the worst possible choice you could make
(unless you have plenty of time to wait and plenty of money to pay
for the wasted bandwidth).
Cheers,
Michi.
Michi Henning
> Actually, having distributed GC or protocol negotiation via casts is not
> specific to COM (rmi has both fwiw, as does dce to a limited degree). Along
> those lines, it is quite possible in SOAP to provide protocol negotiation in
> a way that interops with SOAP implementations that do not know about them.
> All of this being said, SOAP doesn't require/mandate/sanction any of this.
Doesn't that mean that if I care about interoperability, the only way
to achieve it is by using the lowest common denominator approach? (Or building
all additional functionality myself so that I can control it?)
That's precisely what I was alluding to in my earlier post. If the platform
doesn't do something for me, people will invent mutually incompatible
ways of solving the problem. That means not only that they are wasting time
in building infrastructure, but then, to top it off, they can't interoperate.
> SOAP is a protocol. Period. Various companies (Iona, RogueWave,
> DevelopMentor, UserLand, and Microsoft) are building SOAP support into
> various ORB/web-server architectures. You don't "have to" use anything to do
> soap. Some folks will use strcat/strtok and sockets. Others will use
> off-the-shelf XML parsers and HTTP software such as apache/libwww. Still
> others will use the SOAP support built into their ORB. The beauty of XML-RPC
> technologies (such as SOAP) is that they don't attempt to solve world
> hunger. Rather, they just define a minimal protocol that you can generate
> and consume however you want, leveraging tons of existing software (such as
> Apache and XML parsers) rather than defining yet another object runtime
> system (a la EJB, POA or COM+).
So, how does this differ in principle from a TCP/IP socket? OK, you get
a somewhat higher level of abstraction, such that byte ordering and such
like is taken care of. But we are still faced with something that does
marshaling and a bit of type checking, and very little else. What's the
point? Why would I want to use this as a comms protocol?
> > It would be certainly more convenient for
> > application developers to use the language bindings provided by COM and
> > CORBA, wouldn't it?
>
> Convenient yes, however, not mandatory. Both observations are equally
> important.
CORBA and COM aren't mandatory. You can choose not to use either ;-)
And I'm getting back to the previous argument. Language bindings and
source portability are important. They make life easier and provide
protection against vendor lock-in.
> > Same goes for marshalling. If you say XML is just one choice (where others
> > are CDR, NDR, and RMI wire formats): Isn't that an interoperability
> > nightmare?
>
> This is an HTTP-ism. Technically, SOAP is the application of the mime
> content type "text/xml-SOAP" to HTTP. However, one could easily build
> transfer syntax negotiation on top of this leveraging current HTTP practice.
> This is no different than say an ORB product using IIOP to bootstrap and
> then negotiating a more optimized protocol after the first method
> invocation.
But the fact remains: unless everyone agrees to speak XML over SOAP, they
won't be able to make even that first method call to negotiate anything.
Cheers,
Michi.
Don Box
news:Pine.LNX.4.20.99102...@styx.triodia.com...
> On Mon, 25 Oct 1999, Don Box wrote:
>
> > Sorry for the "just-in-time notation coining". I meant "approximately
> > equivalent to" with the emphasis on "approximately".
>
> I was only half serious. But I still don't think that HTTP + XML comes
> anywhere near CORBA in terms of functionality. CORBA does a lot more than
> that.
>
> > a) Parameter marshaling. (XML-ization vs. IDL/IR-driven CDL-ization).
> > b) Server-side dispatching to user-defined code.
> > (CGI/mod_xxx/isapi/servlet/asp vs. POA)
> >
> > These two are core, and are augmented by:
> >
> > c) Rudimentary lifecycle management (both based on client-independent
> > passivation).
> > d) Rudimentary concurrency management.
>
> I think the emphasis should be on rudimentary here. In addition, the
> difficulty of retaining state on the server side with HTTP gets in the way
> big time.
How is it any different than with POA? I just reread the POA chapter from
your (and Steve's) most excellent book and I didn't see anything that
couldn't easily be adapted to run with HTTP. When reading the lifecycle
chapter, I was stunned at how similar your evictor solution was to how folks
solve things in the HTTP case. In both HTTP and IIOP, one simply maps an
arbitrary cookie to server-side state. In both HTTP and IIOP, one has to use
heuristics to reclaim server-side resources due to the lack of distributed
GC. In both HTTP and IIOP, TCP connection lifetime has virtually no impact
on server-side state management.
The primary difference is not in the protocol but in the supporting runtime.
In CORBA, you build your state management in terms of the POA. In HTTP, you
use query strings, HTTP cookies, or POST-data-based cookies using your
server-side plumbing of choice (ASP, servlets, etc). The similarities
between HTTP and IIOP far outweigh the differences.
> There are lots of things missing though: location transparency,
How is a URL any different than an IOR? Both have host names embedded in
them. Both can be acquired from some middleman "naming service."
> server
> migration,
If you are talking about the LOCATION_FORWARD, how is this any different
than an HTTP 3xx status response?
> server activation on demand,
> servant activation,
Hmmmm... IIS and servlets both crank up code dynamically at the first
request to a given "poa".
> flexible
> life cycle management for servants,
ASP and servlets have a different model than the poa, but certainly if you
look at what's possible under ASP via IObjectControl/IClassFactory, I think
almost anything you can do with a POA can be done with MTS/COM+ context
inside of ASP.
> threading models, etc.
MTS/COM+ inside of ASP are AT LEAST as flexible as the minimal controls that
POA offers under 2.2. If there is a new policy under 2.3, then maybe they
are closer.
> And I haven't
> said anything about services yet...
Nor have I ;-) ;-)
> > We can disagree about the relative quality/elegance/utility of these
> > functions, but what do I get from an ORB that isn't offset by:
> >
> > g) Hoards of bright developers working on a freely available,
> > cross-platform, widely deployed HTTP daemon (Apache).
> > h) Hoards of support engineers/system administrators familiar with
popular
> > HTTP daemons (apache, iis).
> > i) Firewall/proxy support.
>
> HTTP isn't RPC. I thought people would have found out the hard way by
now...
Michi. I like you as a person and really respect your work. Please tell me 3
ways in which HTTP isn't semantically an RPC protocol minus a marshaling
syntax. I''ve struggled with this one long and hard, and I am hard pressed
to find major differences between HTTP and GIOP/IIOP (modulo parameter
marshaling of course).
> Hordes of developers working on Apache are going to make a great Apache
> server, no doubt. But that doesn't necessarily reduce my development time
> or enable me to easily intergrate across languages, operating systems,
> and hardware platforms.
It depends on how you define "easily." I agree that the current state of the
practice has folks implementing more RPC-gunk than they would like. However,
I am confident that this will get considerably easier within 3-9 months.
> > Please don't say type safety - proper use of XML over HTTP can yield
type
> > safety comparable to IDL + CDL.
>
> I don't think I ever claimed that XML wasn't type safe. I did say,
however,
> that it trades static type safety against run-time type safety.
God I hate to sound like I am reflexively disagreeing with you, but here
goes.
XML is no more or less "static" in its type safety than CDR. If, however,
the XML is generated "by hand" using a DOM or strcat, then yes, it is not
statically type safe. However, if SteveV's (or BillG's) pluggable orb
marshals to XML instead of CDR or NDR, is the type safety any less static? I
don't think so.
> That's
> not always a good trade-off, depending on the situation.
Agreed (whew, that felt good).
> As a rule, I prefer
> statically type safe interfaces (as do a good many other people).
As do I for a large body of applications. SOAP (or I) are not advocating
anything to the contrary, btw.
> With
> CORBA, you can choose whether you want to have things typed statically
> or dynamically.
Ditto for SOAP.
> Performance is also an issue. A recent conversation with a fellow
developer
> here indicates that during a switch from a CORBA/IIOP implementation to
> an XML-based transport, performance dropped by a factor of 50! This may
> not be a representative figure, but I have anecdotal evidence from a
number
> of sources now who all claim that XML is *much* slower. (Not surprising,
> considering how it throws bandwidth around, not to mention all the work
> that needs to be done at run time.)
I recently did some benchmarking and was suprised at the wide gap of
performance between parsers. In preliminary tests with MODERATE data types
and a good XML parser, I've been getting respectable performance that was no
where near 50 times slower than DCOM or CORBA. Yes, I think if I am sending
an 8MB array of shorts, CDR/NDR will be considerably faster, but that isn't
the norm (although yes I know it occurs). That being said, I would way
rather transfer multi-megabyte datasets using HTTP with a reasonable mime
type, since the ISAPI infrastructure under IIS gives me a great deal of
flexibility in terms of handling the i/o asynchronously and in chunks. With
CORBA (or DCOM), I believe my server cannot touch the first element of an
[in] sequence/array until the last element has been unmarshaled. Ditto for
[out] params on the client.
> > However, as we both know, many tools/languages were invented to
> > "help" developers and no one tool/language ever won. To think that the
world
> > will move to CORBA or DCOM (or HTTP) is somewhat naive. That being said,
I
> > think that the combination of HTTP and XML offer a reasonable
alternative to
> > CORBA and DCOM for a large number of deployment scenarios -
protocol-wise.
>
> Well, I'm not saying that HTTP and XML are useless or nonsense. But I am
> saying that they are not a general CORBA or DCOM replacement, just as
> CORBA or DCOM aren't HTTP and XML replacements.
I am not either. I am simply stating that HTTP + XML has many of the same
characteristics as IIOP protocol-wise.
> They do different things
> in different ways. I think the trick is to choose the one that is
appropriate
> for what I want to do, not to run around blindly shouting "X is better
than Y."
Agreed.
> People keep looking for such messages, unfortunately, no matter that they
> inevitably turn out to be wrong in at least half the number of cases...
Thank God, otherwise we'd all be out of a job ;-)
> > Of course - it's something we all want. And certainly solutions like
> > Servlets, apache modules, XML DOMs, SAX give us that on the HTTP side.
The
> > beauty of the HTTP (and XML) story is that many APIs have flourished
around
> > a single protocol - to me that is a feature. As long as I gen/parse the
> > packets correctly, I have the freedom to choose radically different
> > runtime/apis rather than having to converge on a single programming
> > standard. Wire-level interop is mandatory. Source-level/in-memory-level
> > interop is optional.
>
> Right. That may be true for you. However, go and sell that story to a
large
> customer who is sitting on many million dollars worth of software
development
> effort and is forced to switch platforms for some reason. They are
decidedly
> unimpressed when you tell them that they can go and rewrite all their
code...
> Source code portability is *important* to a lot of people.
I never said it wasn't. My point was that for heterogeneous groups of
developers to interop, all that is needed is a wire protocol. One thing I
hate about both DCOM and CORBA is that for you to talk to me via either
protocol, I wind up inflicting a runtime + API on your code based on what
was right for me, not necessarily for you. Yes, I know, folks can generate
DCOM and IIOP packets by hand, but given the choice between handcrafting
HTTP/XML, DCOM or IIOP, I would way rather write the code to deal with the
former, as (a) it is considerably simpler and (b) there are numerous free
runtimes that I can leverage if I choose to.
>
> > Ahhh but look at an IOR and you see why. HTTP-based apps leverage URIs
and
> > DNS for naming functionality. Trader-style needs to be crufted by hand
> > however, although this is certainly doable (one could even wrap access
to a
> > CORBA trader daemon behind HTTP of one was so inclined).
>
> The INS spec introduced corbaname URLs. Something like
>
> corbaname:myhost.mydomain/somename
>
> gets me to my object.
Exactly. And why on earth was INS needed? What was wrong with Naming +
Trader? And does INS break location transparency any less than HTTP URLs?
> > > as well as both persistence and life cycle.
> >
> > HTTP programmers typically use databases for persistence - this is both
good
> > and bad however it is not mandated by the protocol, just by a common
need to
> > interop with existing information in an organization.
>
> Huh? I think we missed each other. CORBA doesn't mandate anything about
> how to do persistence in the protocol.
It may not mandate it, but there has been no shortage of CORBA specs for
doing persistence. Hey, even some COM guys have written them in the past ;-)
;-)
> However, it does offer a way that
> makes it easy to persistify objects in a database if that's what you want.
> That's better than having to craft SQL queries together
I disagree. Look at EJB entity beans and the wide variance in performance
levels. A lot of EJB folks blow off entities and just use JDBC. The same is
true on the MTS/COM+ side.
> > Agreed, especially if your server switches itself off all by itself from
> > time to time ;-) ;-)
>
> What's that supposed to mean?
This was a joke relating back to a conversation we once had about the
relative reliability of various operating systems.
> > > and they are also not very interesting if
> > > you cannot create and remove objects.
> >
> > Disagreed ;-) If we are talking about admin, then yes, it is important
to
> > be able to adminster a server and install/uninstall/configure
server-based
> > applications. No question. If we are talking about managing server-side
> > sessions, again, we agree that this is important. If we are talking
about
> > allowing arbitrary creation/deletion of language-level objects in a
server
> > daemon, then I think we disagree. DCOM is often denegrated by CORBA
folks
> > for mandating this. I have come to agree with the CORBA folks on this
(if
> > you counter by defending RMI/DCOM-style pinging then we need to stop to
> > avoid confusing folks on this list).
>
> I'm not sure I follow you. I am not aware of any interesting system that
> doesn't require life cycle management for persistent objects. After all,
> what good is a document database if you can't add and remove documents?
Seriously, Michi, the lifecycle service is just a bloody interface with a
create and remove method. This is not exactly rocket science.
> I don't see where pinging comes into this (and we can have an argument
> about that separately ;-)
>
When I was discussing lifecycle, I was using the term similarly to the way
your book reads, that is, lifecycle of in-memory representations (servants).
That's all.
> > Naming certainly, however, URLs have served folks fairly well. A fair
amount
> > of engineering has been invested into making DNS names (and even IP
> > addresses) sharable by multiple server boxes. As for identifying
> > "instances", the URL does have some space after the first forward slash
for
> > such things.
>
> Yes. On the other hand, I would say that URL's have been spectacularly
> subfunctional. Pretty much no way to move anything without breaking
things.
How are URLs + HTTP 3xx status codes different than IORs?
> Again, I believe that URLs are another expression of the syndrome of
> "well, it sucks, but it's the only thing going". If we had URNs (which
> are much closer to CORBA IORs than URLs), no-one would be using URLs...
Sure, URNs have the advantage of not having location built into them, but
look at INS. Why are they being spec'ed? I think the user community is
fairly schizo on this one. They bitch and moan about hard-coding ANYTHING to
a particular server, yet they often don't like the level of indirection
needed to break the dependency. Or am I missing something?
Ahh, however no one is trying to mandate an API, runtime or set of
higher-order services here. To me, that's the critical difference. With
SOAP, a runtime is optional. You can use the runtime of your choice (POA,
COM+/MTS, ASP, Servlets, EJB, CGI, etc).
> What annoys me is that catch-cry of "look at how easy
> this is!", with no-one crying "yes, and did you notice how little it can
do?"
Agreed. At least two major software companies that I know of are notorious
for this.
> > > I don't think so. It is not feasible or desirable to have a
protocol-only
> > > approach for every application that needs to do something halfway
> > > sophisticated. There are far too many other problems that need solving
> > > in practice, and application developers need help with those.
> >
> > Which is why the free-market rushes to fill that void with plumbing like
> > Servlets, Apache, ASP, etc.
>
> Busily adding more complexity. And, please, don't tell me that ASP is
simple!
It depends on what you compare ASP to. Is ASP simpler than [D]COM or CORBA?
Yes, by a long shot. Is it more complex than HTML? Yes. However, the body of
folks using ASP is truly staggering, and JSP/servlets are catching up.
>
> > DCE was doomed. CORBA and DCOM came at a much better time in history,
> > however, they have both been marginalized as client->server protocols by
> > HTTP.
>
> It depends on where you look. There are plenty of systems that are built
> with CORBA and that you wouldn't dream of building with HTTP. Of course,
> the converse is just as true. There are systems that are better built
> with HTTP. If you are talking in terms of numbers, no doubt, there are
> more HTTP-based systems around that CORBA or DCOM ones. On the other hand,
> the web explosion resurrected the old hammer and nail syndrom: if all
> you have is HTTP, everything looks like a foot...
Or how about "if all you can reliably get to interop between organizations
and sites is HTTP, ..."
> > Netscape and Microsoft both tried to make CORBA/DCOM the dominant
> > protocols of the Internet and both gave up.
>
> Actually, I disagree with that. I'm not aware that either company ever
> wanted to ursurp the Internet set of protocols, or that the OMG tried
> to do that either.
Jesus, look at Orfali's Intergalactic Object Web stuff! FWIW, the net is
littered with fun quotes from MS, Netscape and OMG folks. Especially around
1996. AltaVista is your friend here (try "IIOP Internet").
> Instead, CORBA has a quite clearly defined charter,
> namely to provide an open OO platform for distributed heterogeneous
systems.
> CORBA does that extremely well, IMO, and I am not aware of anything else
> that comes anywhere near CORBA's degree of
> easy
I take the word "easy" with a grain of salt here. Again, a lot of folks look
at the stuff in your book (and my book) and run screaming to low-tech
solutions like CGI.
> when I want to integrate
> Palm Pilots, mainframes, PCs, multiple operating systems, legacy apps,
etc.
And is HTTP not adaptable to these platforms? In either case, one cannot
just sprinkle the magic CORBA or HTTP pixie dust on the app and suddenly it
uses the protocol. In either case, someone is going to be churning out
protocol-specific (or runtime-specific) code.
>
> > Because they both gave up, the
> > supporting firewall infrastructure never adapted to these protocols and
they
> > are relegated to server->server communications. We can argue about the
> > technical merits of this reality, but I think we both agree that it is a
> > reality, yes?
>
> I agree to the extent that CORBA was slow to deal with the firewall issue
> and that, as a result, vendors were slow to adapt. The firewall spec is
> out now so, hopefully, that bottleneck will be eliminated.
However, two things have to happen first: (a) the ORB vendors need to
support it (that's the easy one) and (b) system/network admins have to agree
to allow it on their networks. I am not sure whether new firewall/proxy
plumbing is needed or not, but if to, there's your (c).
> > I think where we really disagree (correct me if I am wrong) is
> > the relative importance of the server-side protocol stack and supporting
> > runtime once we come across an HTTP gateway such as Apache or IIS. I
think
> > that you believe a unified runtime and programming model (a la POA) is
> > important.
>
> Yes, I think that this is certainly important. More than the programming
> model though, I think CORBA's value lies in how easy it is to solve
> what until very recently was a very difficult (and usually intractable)
> problem, namely how to write robust heterogeneous distributed
applications.
Who's saying "look how easy it is" now? We both know that technologies like
CORBA/DCOM/MTS only help deal with the first 10-20%. After than, you're more
or less on your own to design your application protocol hoping that you've
factored in things like concurrency, failure recovery, scalability,
availability, etc. Oh, and then you need to implement it!
> > I believe that the world doesn't want this and prefers relative
> > chaos. Why else do technologies like Servlets, EJB, COM+ etc. continue
to
> > exist in the face of the "one true answer" that the OMG handed down
years
> > ago?
>
> I think in part it is because of the Web/Java craze and the hammer and
> nail syndrome. People are forever looking for the one true answer, and
> there simply isn't one. In their misguided search for the one true answer,
> they con themselves into believing that they have found it in technology X
> and promptly proceed to use technology X for all sorts of things it is
> ill suited for. Partly, that's human nature, and I don't see it changing
> any time soon, if ever. Partly, it is sheer ignorance...
Agreed. Before XML it was Java. Before Java it was Design Patterns.
Sometimes I feel like I work in the fashion industry. At least we get to eat
rich food and drink as much beer as we can stand without having to worry
about loosing our waif-like "programmer's figure" ;-) ;-)
> > We've had this conversation before. In NT-dominant shops, people choose
> > COM/DCOM/MTS/COM+. In cross-platform shops, people choose CORBA/IIOP
over
> > DCOM consistently (for good reasons).
>
> That sounds like a very solid choice to me and, in fact, that is the
choice
> I've continously been advocating.
>
> > However, for mainstream server apps,
> > folks have rejected CORBA and DCOM as client->server access protocols
and
> > adopted HTTP. Are there internal IT apps that use DCOM or CORBA? Yes.
Will
> > telcos switch to DCOM or HTTP anytime soon? No.
>
> Don't bet too much on that. CORBA use in telcos is big and growing at
> a furious pace.
I think you misread my post. I am aware that telcos are one of the primary
customers of CORBA. I am also aware that the state of the phone system in
the US has gone to hell in the past 8 years or so, but I blame that more on
the breakup of AT&T than on technology choices.
> > However, there are a ton of
> > developers who don't write telephone switches or flight control systems
and
> > for them, HTTP is often a more suitable solution than DCOM or CORBA.
>
> Sure. If all I want is a simple interface to some back-end functionality,
> by all means, use HTTP and cgi-bin. That's what they are good for.
> I never said that HTTP is bad per se. What I am saying is that HTTP is
> getting abused and shoe-horned into doing all sorts of things it is
> singularly ill-suited for (like stateful interactions). Why on earth
> insist on using such a poor tool when there are better ones around?
> Why on earth use something that requires a new TCP/IP connection for
> every tiny interaction? This is insanely expensive (not to mention that
> the cgi-bin contortions you have to go through simply suck).
HTTP/1.1 defaults to connection keep-alive, and earlier products supported
it too. Also, there are a variety of ways to not spawn a
process-per-request. IIS almost never spawns processes or threads. Apache
can work in much the same way and is getting even better.
>
> And I still don't understand why I would want to use XML for RPC. As
> a protocol, it's about the worst possible choice you could make
> (unless you have plenty of time to wait and plenty of money to pay
> for the wasted bandwidth).
Name one other protocol that provides the same functionality that doesn't
have at least one major industry player poo-pooing it. Last time I checked,
no major industry player is standing on the sidelines with XML. For whatever
reason, XML has electrified the industry and there is nothing you or I can
do to change that.
Michi Henning
> > I think the emphasis should be on rudimentary here. In addition, the
> > difficulty of retaining state on the server side with HTTP gets in the way
> > big time.
>
> How is it any different than with POA? I just reread the POA chapter from
> your (and Steve's) most excellent book and I didn't see anything that
> couldn't easily be adapted to run with HTTP. When reading the lifecycle
> chapter, I was stunned at how similar your evictor solution was to how folks
> solve things in the HTTP case. In both HTTP and IIOP, one simply maps an
> arbitrary cookie to server-side state.
I do see a difference: the cookie in CORBA is encapsulated in object
references by the server. Object references encapsulate everything else and
are opaque. Even on the server side, the cookie (aka object ID) is available
to the server only withing the context of an executing request on the
corresponding object. HTTP solutions don't encapsulate anything.
> In both HTTP and IIOP, one has to use
> heuristics to reclaim server-side resources due to the lack of distributed
> GC. In both HTTP and IIOP, TCP connection lifetime has virtually no impact
> on server-side state management.
Yes.
> The primary difference is not in the protocol but in the supporting runtime.
> In CORBA, you build your state management in terms of the POA. In HTTP, you
> use query strings, HTTP cookies, or POST-data-based cookies using your
> server-side plumbing of choice (ASP, servlets, etc). The similarities
> between HTTP and IIOP far outweigh the differences.
I don't think so. Where are the policies I can attach to IORs? Where
is the in-built and transparent security? Where is the transaction context
propagation?
> > There are lots of things missing though: location transparency,
>
> How is a URL any different than an IOR? Both have host names embedded in
> them. Both can be acquired from some middleman "naming service."
To the best of my knowledge, there is no equivalent mechanism to an
implementation repository that will transparently forward all invocations
to wherever the server is currently running, and will continue to do
so without further intervention as the server changes location.
> > server
> > migration,
>
> If you are talking about the LOCATION_FORWARD, how is this any different
> than an HTTP 3xx status response?
Is 3xx as flexible and automatic as an IMR?
> > server activation on demand,
> > servant activation,
>
> Hmmmm... IIS and servlets both crank up code dynamically at the first
> request to a given "poa".
>
>
> > flexible
> > life cycle management for servants,
>
> ASP and servlets have a different model than the poa, but certainly if you
> look at what's possible under ASP via IObjectControl/IClassFactory, I think
> almost anything you can do with a POA can be done with MTS/COM+ context
> inside of ASP.
Hmmm... Previously, we were talking about HTTP + XML. Now you've thrown
ASP, servlets, MTS, and COM+ into the mix. Can we agree to keep talking
about the same thing?
> > threading models, etc.
>
> MTS/COM+ inside of ASP are AT LEAST as flexible as the minimal controls that
> POA offers under 2.2. If there is a new policy under 2.3, then maybe they
> are closer.
I never talked about either MTS or COM+, but about HTTP + XML. Why bring
MTS and COM+ into the picture?
> Michi. I like you as a person and really respect your work. Please tell me 3
> ways in which HTTP isn't semantically an RPC protocol minus a marshaling
> syntax. I''ve struggled with this one long and hard, and I am hard pressed
> to find major differences between HTTP and GIOP/IIOP (modulo parameter
> marshaling of course).
Don, you claimed that HTTP + XML is approximately the same as an ORB.
I claimed that HTTP + XML is not as functional as an ORB. Now you are
asking me where the difference is between HTTP and IIOP. At some level
of abstration, there is little difference. However, that wasn't the
original question we were discussing, was it?
> > Hordes of developers working on Apache are going to make a great Apache
> > server, no doubt. But that doesn't necessarily reduce my development time
> > or enable me to easily intergrate across languages, operating systems,
> > and hardware platforms.
>
> It depends on how you define "easily." I agree that the current state of the
> practice has folks implementing more RPC-gunk than they would like. However,
> I am confident that this will get considerably easier within 3-9 months.
Don, you can't have it both ways. Previously, you argued that HTTP + XML
is just as functional as CORBA. Now you are saying that people have
to do more RPC-gunk that is desirable. Doesn't that fly in the face
or the previous assertion you made, namely that HTTP + XML is as
functional as CORBA? Doesn't it also fly in the face of the assertion
that an on-the-wire common protocol is all that is necessary and that
platforms aren't the right thing? What will we have once the RPC-gunk
is removed from teh HTTP + XML approach? Another platform?
> > I don't think I ever claimed that XML wasn't type safe. I did say,
> however,
> > that it trades static type safety against run-time type safety.
>
> God I hate to sound like I am reflexively disagreeing with you, but here
> goes.
>
> XML is no more or less "static" in its type safety than CDR. If, however,
> the XML is generated "by hand" using a DOM or strcat, then yes, it is not
> statically type safe. However, if SteveV's (or BillG's) pluggable orb
> marshals to XML instead of CDR or NDR, is the type safety any less static? I
> don't think so.
Again, you argued previously that HTTP + XML is as functional as CORBA.
Now you are saying that an ORB could generate stubs that marshal using XML.
But what are we going to have then? Another ORB, or another programming
platform if it isn't CORBA. You would again have to generate the XML
marshaling from something like OMG IDL or MIDL, which implies that
there must be a defined API, which implies the programming platform you
claimed wasn't necessary, no?
> I recently did some benchmarking and was suprised at the wide gap of
> performance between parsers. In preliminary tests with MODERATE data types
> and a good XML parser, I've been getting respectable performance that was no
> where near 50 times slower than DCOM or CORBA. Yes, I think if I am sending
> an 8MB array of shorts, CDR/NDR will be considerably faster, but that isn't
> the norm (although yes I know it occurs). That being said, I would way
> rather transfer multi-megabyte datasets using HTTP with a reasonable mime
> type, since the ISAPI infrastructure under IIS gives me a great deal of
> flexibility in terms of handling the i/o asynchronously and in chunks.
Well, for wide-area applications, bandwidth is an issue. XML is very generous
indeed with bandwidth (and, if I had had it my way, IIOP would use far
fewer bytes per request than it does now; but at least it isn't as
liberal with bandwidth as XML).
> With
> CORBA (or DCOM), I believe my server cannot touch the first element of an
> [in] sequence/array until the last element has been unmarshaled. Ditto for
> [out] params on the client.
Yes. But that's inherent in the synchronous RPC paradigm. There is no
way to let go of the thread of control until after the data has been
unmarshaled into memory, otherwise the synchronous nature of the call
breaks down.
In practice, I don't see this as a problem, unless you insist on using
synchronous RPC for streaming media (and of course, synchronous RPC
simply isn't suitable for that).
> > Well, I'm not saying that HTTP and XML are useless or nonsense. But I am
> > saying that they are not a general CORBA or DCOM replacement, just as
> > CORBA or DCOM aren't HTTP and XML replacements.
>
> I am not either. I am simply stating that HTTP + XML has many of the same
> characteristics as IIOP protocol-wise.
Sure. There are similar characteristics. But, as I said, previously, we
were talking about HTTP + XML ~= ORB. Now you are saying that
HTTP + XML ~= IIOP. These are two very different statements, and arguments
that apply to one don't necessarily apply to the other.
> > They are
> decidedly
> > unimpressed when you tell them that they can go and rewrite all their
> code...
> > Source code portability is *important* to a lot of people.
>
> I never said it wasn't. My point was that for heterogeneous groups of
> developers to interop, all that is needed is a wire protocol. One thing I
> hate about both DCOM and CORBA is that for you to talk to me via either
> protocol, I wind up inflicting a runtime + API on your code based on what
> was right for me, not necessarily for you.
Unless I misunderstand what you said above, by the time HTTP + XML will
have crafter the additional bits of functionality on that developers want,
it will be just as much of a platform as DCOM or CORBA.
> Yes, I know, folks can generate
> DCOM and IIOP packets by hand, but given the choice between handcrafting
> HTTP/XML, DCOM or IIOP, I would way rather write the code to deal with the
> former, as (a) it is considerably simpler and (b) there are numerous free
> runtimes that I can leverage if I choose to.
Well, actually, I would think that handcrafting either is silly. Protocols
are meant to be driven through APIs. After all, if the handcrafting were
simpler, we wouldn't need networking APIs, telnet, ftp, etc.
> > The INS spec introduced corbaname URLs. Something like
> >
> > corbaname:myhost.mydomain/somename
> >
> > gets me to my object.
>
> Exactly. And why on earth was INS needed? What was wrong with Naming +
> Trader? And does INS break location transparency any less than HTTP URLs?
INS solves the bootstrapping problem of where to get the first object
reference from. A URL-style IOR can be used to configure an entire ORB
to resolve to a controlled set of initial references. Those references
are provided by a bootstrap server that can be configured to return whatever
is needed.
INS breaks location transparency to the extent that it permits you to
specify a location for the bootstrap server. That's unavoidable because
you have to have some fixed point to start with. However, that location
can be completely hidden from clients. Clients need not deal with URL-style
IORs (but can if they want to).
As a general IOR replacement, URL-style IORs are not recommended because
they suffer some of the same problems as other URLs: if the thing
at the other end moves, things break, and things like protocol details and
addressing information are no longer encapsulated. (However, you can
point a URL-style IOR at an implementation repository and leverage the
location forward mechanism; that helps with the server migration problem.)
> > Huh? I think we missed each other. CORBA doesn't mandate anything about
> > how to do persistence in the protocol.
>
> It may not mandate it, but there has been no shortage of CORBA specs for
> doing persistence. Hey, even some COM guys have written them in the past ;-)
> ;-)
The persistence specifications hav enothing to do with the protocol, and
there is nothing mandatory about them. I can choose to use a PSS to implement
persistence of my objects, or I can use a homegrown solution. Either way,
no-one knows except the server implementer because the object implementation
is completely hidden behind its interface. There is not a single bit
at the protocol level that would even vaguely relate to object persistence
in CORBA.
> > However, it does offer a way that
> > makes it easy to persistify objects in a database if that's what you want.
> > That's better than having to craft SQL queries together
>
> I disagree. Look at EJB entity beans and the wide variance in performance
> levels. A lot of EJB folks blow off entities and just use JDBC. The same is
> true on the MTS/COM+ side.
JDBC isn't exactly a high-level interface. Besides, I can use JDBC to create
persistent CORBA objects just as I can use JDBC for any other kind of DB
access.
> > I'm not sure I follow you. I am not aware of any interesting system that
> > doesn't require life cycle management for persistent objects. After all,
> > what good is a document database if you can't add and remove documents?
>
> Seriously, Michi, the lifecycle service is just a bloody interface with a
> create and remove method. This is not exactly rocket science.
I never said it was. Personally, I think that the life cycle service is
mostly useless (and we say as much in our book).
> > I don't see where pinging comes into this (and we can have an argument
> > about that separately ;-)
> >
>
> When I was discussing lifecycle, I was using the term similarly to the way
> your book reads, that is, lifecycle of in-memory representations (servants).
> That's all.
Crossed wires then. I was talking about life cycle of the abstract object
in this case.
> > Yes. On the other hand, I would say that URL's have been spectacularly
> > subfunctional. Pretty much no way to move anything without breaking
> things.
>
> How are URLs + HTTP 3xx status codes different than IORs?
I honestly don't know whether that is as flexible as an implementation
repository. Maybe someone can help to reduce my ignorance level?
> Sure, URNs have the advantage of not having location built into them, but
> look at INS. Why are they being spec'ed? I think the user community is
> fairly schizo on this one. They bitch and moan about hard-coding ANYTHING to
> a particular server, yet they often don't like the level of indirection
> needed to break the dependency. Or am I missing something?
No, I don't think so. After all, the required location information
has to come from somewhere. If it isn't in the addressing handle (URL, or
IOR, or whatever), then it has to come from somewhere else, which implies
a level of indirection.
> > I strongly claim that all the power isn't possible without the complexity.
> > In other words, by the time you've made HTTP + XML do all the things
> > developers need for real-life systems, HTTP + XML will be just as complex;
> > it's inevitable.
>
> Ahh, however no one is trying to mandate an API, runtime or set of
> higher-order services here. To me, that's the critical difference. With
> SOAP, a runtime is optional. You can use the runtime of your choice (POA,
> COM+/MTS, ASP, Servlets, EJB, CGI, etc).
So, what have I gained then by using SOAP. It will be hidden below an ORB,
COM+, or whatever. That means that I don't see it, so why would I care
whether it's SOAP or something else? In fact, why invent SOAP when there
are plenty of RPC protocols around already?
> > What annoys me is that catch-cry of "look at how easy
> > this is!", with no-one crying "yes, and did you notice how little it can
> do?"
>
> Agreed. At least two major software companies that I know of are notorious
> for this.
Only two? I would have said several hundred... ;-)
> > Actually, I disagree with that. I'm not aware that either company ever
> > wanted to ursurp the Internet set of protocols, or that the OMG tried
> > to do that either.
>
> Jesus, look at Orfali's Intergalactic Object Web stuff!
I have to admit that I never bothered to read it in detail (too high-level
for my taste).
> FWIW, the net is
> littered with fun quotes from MS, Netscape and OMG folks. Especially around
> 1996. AltaVista is your friend here (try "IIOP Internet").
Hang on a minute -- prior to IIOP, there wasn't anything that could
integrate heterogeneous distributed apps. And quite clearly, IIOP was
a major corner stone of CORBA's success because it provided interoperability.
That's useful and valuable. No-one ever said that IIOP would replace
ftp, http, CMIP, or whatever. What people did say was that, for the first
time, we had a general purpose RPC protocol that was widely supported
by many vendors, open, flexible enough to do a lot of things, and available
on lots of platforms. To the best of my knowledge, IIOP still holds that
position today. HTTP is the only other sort of general protocol I know
of that can make the same claim but, as I said earlier, using HTTP directly
for RPC is about as comfortable as using IIOP directly for RPC -- only
masochists do it.
And, by the sounds of things, SOAP will do about the same things as IIOP.
So why bother and not just use IIOP?
> > CORBA does that extremely well, IMO, and I am not aware of anything else
> > that comes anywhere near CORBA's degree of
>
> > easy
>
> I take the word "easy" with a grain of salt here. Again, a lot of folks look
> at the stuff in your book (and my book) and run screaming to low-tech
> solutions like CGI.
That's right. And then they build low-tech applications that don't scale,
are hard to port, don't evolve easily, etc. The complexity in CORBA (which
is admittedly there) isn't just there for fun. You get functionality in
return. You can choose to ignore the functionality, in which case CORBA
will make you suffer (because the complexity without the functionality
isn't worth it). I see this soft of thing quite often in development
teams where every parameter is of type sequence<octet>...
On the other hand, you can use the platform to help you do your job, in
which case the complexity pays off.
Of course, I choose to avoid the complexity altogether and use CGI. That's
a valid choice. But then I should also be aware of the doors that I am
closing by making that choice. A simple CGI-based solution has natural
limits as to how far you can push it.
I firmly believe that it is impossible to avoid the complexity without
losing the functionality. You can't have your cake and eat it too...
> > when I want to integrate
> > Palm Pilots, mainframes, PCs, multiple operating systems, legacy apps,
> etc.
>
> And is HTTP not adaptable to these platforms? In either case, one cannot
> just sprinkle the magic CORBA or HTTP pixie dust on the app and suddenly it
> uses the protocol. In either case, someone is going to be churning out
> protocol-specific (or runtime-specific) code.
Yes. No magic wands there. But it's a damn sight easier to use CORBA than
to use raw HTTP, just as it is easier to use DCOM than raw sockets...
> > Yes, I think that this is certainly important. More than the programming
> > model though, I think CORBA's value lies in how easy it is to solve
> > what until very recently was a very difficult (and usually intractable)
> > problem, namely how to write robust heterogeneous distributed
> applications.
>
> Who's saying "look how easy it is" now? We both know that technologies like
> CORBA/DCOM/MTS only help deal with the first 10-20%. After than, you're more
> or less on your own to design your application protocol hoping that you've
> factored in things like concurrency, failure recovery, scalability,
> availability, etc. Oh, and then you need to implement it!
Yes. And that necessity will never go away, SOAP or no SOAP. It's in the
nature of the beast: do complex things and you will have complex problems.
A platform can take most of the grunt work out of building a distributed
app; it can't do you thinking for you.
> Agreed. Before XML it was Java. Before Java it was Design Patterns.
> Sometimes I feel like I work in the fashion industry. At least we get to eat
> rich food and drink as much beer as we can stand without having to worry
> about loosing our waif-like "programmer's figure" ;-) ;-)
Yes, thin as reeds as we both are :-)
> HTTP/1.1 defaults to connection keep-alive, and earlier products supported
> it too. Also, there are a variety of ways to not spawn a
> process-per-request. IIS almost never spawns processes or threads. Apache
> > And I still don't understand why I would want to use XML for RPC. As
> > a protocol, it's about the worst possible choice you could make
> > (unless you have plenty of time to wait and plenty of money to pay
> > for the wasted bandwidth).
>
> Name one other protocol that provides the same functionality that doesn't
> have at least one major industry player poo-pooing it.
I'm pretty sure that certain players would love to poo-poo XML too, if only
they could get away with it.
> Last time I checked,
> no major industry player is standing on the sidelines with XML. For whatever
> reason, XML has electrified the industry and there is nothing you or I can
> do to change that.
You may be right. "Electrified" is probably the right word. The corresponding
shock reaction from all that electricity will arrive with a delay, when
people realize that they yet again have fallen prey to the silver bullet
syndrome. There is nothing wrong with XML; there is a lot wrong with
trying to make it do all things.
Cheers,
Michi.
Don Box
news:Pine.LNX.4.20.99102...@styx.triodia.com...
>
> > > I think the emphasis should be on rudimentary here. In addition, the
[snip]
In reading your last response, you were correct in pointing out that we have
lost the distinction between protocols and runtimes. Rather than continue
the previous 24 hour request/response cycle (and you say that CGI is slow
;-)), let me see if I can summarize my points so that we have some hope of
figuring out where we actually disagree (based on the last response, I think
we agree more than we disagree). Along the way, I will try to address issues
you brought up in your last reply.
Point 1: HTTP by itself is functionally equivalent to IIOP without a
marshaling protocol such as CDR.
Both support framing and transmission of requests and responses.
Both support extensible "service contexts" through which one can layer
additional services (e.g., tx).
Both have stringifiable endpoint IDs (URLs vs. IORs) that contain both
TCP/IP endpoints, arbitrary server-side demux, and extensible properties.
Both require request headers to contain stringified "Method" names to add a
per-invocation demux field.
Both allow servers to reply with redirect PDUs to support migration.
Both support layered authentication and encryption.
Both are supported by a lot of different software vendors.
When combined with octet sequences to support arbitrary mime types, anything
that could be done with HTTP could be done with IIOP (assuming the plumbing
software supported it).
When combined with a marshaling protocol (e.g., CDR, NDR, XML), anything
that could be done with IIOP could be done with HTTP (assuming the plumbing
software supported it).
Point 2: XML is a functional superset of CDR (or NDR).
Both support cross-platform representation of fairly arbitrary types.
Both support serialized type information to describe anticipated protocol
streams (IDL vs. XML Schema/DTD/etc).
Only XML supports annotating arbitrary streams with optional information
without affecting the underlying schema (e.g., use of namespace-qualified
elements/attributes).
XML easily supports multi-reference data (see ID/IDREF). In the past CDR did
not, but I think OBV may have added it, so the two may be equivalent here.
Point 3: IIOP (sans CDR) is technically superior to HTTP as an RPC protocol
in several ways
IIOP supports typed service contexts, in HTTP they are just untyped text.
IIOP headers are more compact than HTTP headers.
IIOP doesn't support transfer syntaxes other than CDR, but one can emulate
mime-style easily enough at the protocol level to make this a non-issue.
IORs are more structured than URLs (not necessarily more functional).
IORs can be larger than URLs and therefore can contain more extension goo.
Point 4: CDR is considerably more compact than XML in UTF-8.
This one is self-explanatory.
Point 5: HTTP and XML have thrived despite the "goodness" of IIOP/CDR.
Technical superiority rarely impacts success in most industries (perfection
is the enemy of the good).
The Internet routinely chooses low-tech protocols.
Folks routinely complain about the downsides of any technology that they
adopt, HTTP/XML are no exception.
The current firewall/proxy fabric of the Internet doesn't support IIOP
The current vendor solutions rely on IIOP tunnelling and do not interop (to
the best of my knowledge).
It is uncertain at best/unlikely at worst that the firewall/proxy fabric of
the Internet will adapt to the new OMG spec for IIOP-friendly firewalls.
Point 6: The Internet marketplace routinely chooses wire protocols, not
programming environments/interfaces
TCP/IP, HTTP, SMTP, FTP, NNTP, SNMP, TELNET, HTML, XML had no MANDATORY api
or runtime.
All but TCP/IP and XML had no SUGGESTED api.
TCP/IP had sockets, but has thrived in the face of TLI/XTI, WinSock2,
java.net.Socket, etc.
XML has the DOM, but many folks choose SAX instead + the Level 1 DOM is too
weak to do a lot of interesting things, so every vendor extends it in
proprietary ways.
Vendors abhor a vacuum and will provide API/runtime support appropriate to
their development platform (e.g., java.net.URLConnection/Servlets,
WinInet/ISAPI/ASP, libwww/Apache Modules).
Point 7: No protocol that has been tied to an api or runtime environment has
become ubiquitous in the Internet marketplace.
OSI (like DCE) tried to specify the entire experience and folks rejected it
as being to much to swallow.
Historically, protocols that are tied to an API/runtime tend not to get
wide-spread support without that API/runtime.
RMI didn't succeed because it mandated the Java language + the JVM as a
runtime.
DCOM didn't succeed because it mandated CoXXX as an API +
OLE32.DLL/RPCRT4.DLL as a runtime.
IIOP didn't succeed either, for a variety of reasons which included its
mandate of an API (boa/poa) + runtime (an orb).
Point 8: Modern HTTP servers have converged on the functionality of an ORB.
Both allow arbitrary user code to be loaded and invoked based on a
request/response.
Both support a variety of process and thread models.
Both support both persistent and transient endpoints (objects in
corba-speak).
Both allow server-side state (servant in corba-speak) to be associated with
an arbitrary endpoint.
Both decouple server-side state management from TCP connection management.
Both allow the location of the request processing to transparently occur on
a different host machine than where the request arrived.
Both are routinely combined with transaction managers and databases.
Both typically have integrated security/authorization/auditing management.