Gerald Brose <gerald.brose@x...> wrote in message news:<2i864aFji3sfU1@u...>...
> Mark Woyna wrote:
> > Gerald Brose <gerald.brose@x...> wrote in message news:<2i5gvaFhvjq7U1@u...>...
> > 
> >>For loosely coupled application-to-application communication
> >>that cannot rely on a homogeneous middleware layer such as
> >>CORBA and may need to be rearranged to integrate more systems
> >>every other month, you will be better off with Web Services.
> > 
> > 
> > What is Web Services if not the next attempt at a homogeneous
> > middleware layer???
> 
> It is a lot "less homogenous" than CORBA.

How so? It's just *another* middleware standard. CORBA and Web Services
both boil down to constructing/deconstructing messages (IIOP/SOAP) and
sending them out on the wire. CORBA and Web Services are available on a
multitude of platforms. Can you provide an example of a platform that
supports Web Services that does not have at least one ORB available for it?

> 
> > CORBA was to be *the* standard for heterogeneous distributed
> > computing. Since one important company, read: Microsoft, did not buy
> > off on the vision of a heterogeneous computing environment, the world
> > was left with two major platforms: CORBA and COM/DCOM/COM+/etc, and a
> > collection of proprietary MOM products. The fear that Sun would
> > succeed in using Java to provide a uniform distributed platform led
> > Microsoft to push for a cross-language, cross-platform solution, i.e.
> > SOAP and Web Services. This does not change the fact that there was a
> > standard open model for distributed computing.
> 
> Sure, that's the history, but this is ignoring the actual technical
> differences between CORBA and the SOA/Web Services which account
> for the different sweet spots. But first let me spell it out again:
> neither CORBA nor SOA/Web Services are "better" per se, they have their
> strong points in different usage areas. You seem to be implying that
> CORBA would have been the universal silver bullet for all your distributed
> scenarios, which it just not the case.

I am not implying it, I am stated it quite loudly and clearly.

Had Microsoft embraced CORBA the way they are embracing Web Services,
there would be no Web Services as we know it today. In addition, Sun
probably wouldn't have gone off and developed RMI, but would have had to
make CORBA the backbone for J2EE, as interoperability with MS desktops
would have (and still is) a major issue.

I'm not saying that CORBA is perfect, but the "features" that make
Web Services so appealing could have easily been added to CORBA. If the
energy spent by companies such as IBM, Microsoft, Iona, Borland, Sun, etc. 
would have been directed at improving CORBA, e.g. firewall support, lack
of development tools, support for documents/XML, it would be a different
ballgame. Of course, I say "if", since it didn't happen.

> 
> The two models differ in important aspects. CORBA's, with the notion
> of objects in the OO sense, is much richer;

Yes, but as I've pointed out numerous times, it's trivial to make a
single "Service" object that basically mimics a Web Service. While the
ability to make lots of little distributed objects exists in CORBA, one
doesn't have to use, and probably shouldn't use, this capability.

  interface StockService {
     LastSalePrice getLastSale(in StockSymbol stock);
  };

I noticed that nobody commented how readable my CORBA "Service" was
compared to the equivalent WSDL. I've had students implement basic
CORBA applications with practically no knowledge of CORBA.

> and more of the interaction
> semantics is spelled out in the spec. While this is nice if you are
> in an OO language,

I don't see what is has to do with the implementation language. It still
boils down to sending messages.

> it entails many assumptions for the interaction
> between clients and servers. It also means that you need to have a
> complete ORB marshallin engine for even simple things,

A complete marshalling engine??? You mean an ORB? There are dozens of
good orbs available, many of them free, e.g. JacORB :-) How on earth is
this any different from needing an XML Parser?

> i.e., you cannot
> simply run a PERL script to fire a message. (I would like to point out
> Steve Vinoski's "Middleware dark matter" article to all those believing
> that CORBA is the only true middleware around.) For SOAP, all you need
> is an XML parser. (I know, they are complex too, but they are much
> more available and easier to integrate than isolated GIOP/CDR mar-
> shalling engines)

Shall we list the available CORBA orbs vs. the available XML parsers? I
would imagine that the lists aren't that different in size. Besides, if
IIOP had been the focus over the last few years, there would be plenty
of marshalling engines around.

> 
> CORBA also spends a lot of space on specifying APIs for portability
> purposes (e.g. POA, PIs), which is completely out of scope for SOA/Web
> Services.

Yes, until one too many businesses get bit in the ass by having code that's
tied to a proprietary Web Services framework. Do you believe the POA was
developed because the OMG was bored? No, it was developed because it was
*needed*. I spent *way* too much time porting code from one orb vendor to
another, as did many others.

I seem to recall the recent clamor within the Java community for a
standard J2EE XML API? Why is that? Because companies like standards. They
don't want to have to port code when they wish/need to switch vendors.

> You can use portable APIs (e.g. JAX-RPC) but you don't
> have to.

And you don't have to use POA. Selecting a portable API makes sense.

> Web Services as a middleware are more modular, if you like,
> and it also suffices if the two parties that actually interact know
> what it means. It's enough to pick those pieces off the standards
> that are required for the task at hand.

And this is no different that basic CORBA interoperability. You're
not making a very compelling case.

> 
> To cut this long story short: in B2B it is a lot easier to
> retrofit a thin Web Services layer onto applications to connect
> existing stuff than to agree on CORBA and on IDL interfaces
> and then wrap things.

Please provide some evidence that this assertion is true. I don't buy
it.

To interoperate, companies *must* agree on an interface, including the
data that is carried within the messages. Implementing the interface
as a simple CORBA object, or a Web Service each require more or less
the same amount of work. Any company using a J2EE application server
these days have the basic CORBA and Web Services facilities available in
the app server.

This brings up an interesting point. On the one hand you talk about the
ease of integrating Web Services into languages such as Perl. On the
other hand, you state that Web Services are best utilized for business to
business communication. Aren't the businesses that are most likely to need
B2B going to be utilizing a full-blown application server framework?
In my view, a company that's going to be in the business of trading supply
chain data with Walmart is likely to already have their data managed by
a business-class application utilizing one of the major app servers.

> 
> >>XML messages are especially suited for document-style inter-
> >>actions, and the performance hit is tolerable in many of
> >>these applications. People also tend to believe that the
> >>firewall-friendliness of HTTP is a good thing...
> > 
> > 
> > Yes, believe. Like kids believe in Santa Claus. They'll believe until
> > some of their customers private data goes walking out port 80, and
> > then we'll see those ports closing up.
> 
> Well, the "..." was meant to signify that that is of course
> naive for any production environment. However, it comes in handy
> for larger-scale inhouse scenarios (say, for testing) where CORBA
> requires you to use an IIOP proxy, like Xtradyne's I-DBC, for
> firewall traversal.
> 
> For any real-world, extranet settings any "port 80" is closed, so
> you need a Web Services Security Gateway (like Xtradynes WS-DBC),
> too. However, the Web Services approach to security (while necessarily
> reinventing some parts of the wheel) is a lot more modular and
> promising than CORBASEC ever was.

I won't argue with that. But the CORBASEC could have evolved. Instead,
most of the energy recently has been directed at reinventing the WS
wheel.

> 
> Cheers, Gerald

Likewise. :-)

Mark