Mark Woyna wrote:
> Gerald Brose <gerald.brose@x...> wrote:
>>Mark Woyna wrote:
>>>Gerald Brose <gerald.brose@x...> wrote:

>>>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. 

In having fewer pages in the specs. :-) (WSDL and SOAP). In earnest,
I was referring to the semantically less strictly defined concept
of service, which can be almost anything and is thus more generally
applicable.

> CORBA and Web Services
> both boil down to constructing/deconstructing messages (IIOP/SOAP) and
> sending them out on the wire. 

CORBA requires more than just sending/receiving messages, the general
behavior of both clients and servers in an interaction is strictly
defined, and there are plenty additional little protocols (think of
code sets, etc.), plus lifecycle issues plus plus... Implementing an
ORB requires a larger investment than implementing a SOAP library.

> 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?

I was not saying that there weren't enough ORBs around, although
perhaps there aren't that many free embedded Java ORBs that I can
run in my cell phone. I am saying you sometimes don't need one,
or can't use it because you won't find a partner on the other side.

>>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.

You may state that, but it is not true. Are all these other protocols
(PVM/MPI, ftp, http, MQ) just there because people were too dumb
to grasp CORBA? Again, I recommend the "dark middleware" article,
I find it quite enlightenting.

Finally, I am not saying that Web Services are generally better
than CORBA.

> Had Microsoft embraced CORBA the way they are embracing Web Services,
> there would be no Web Services as we know it today. 

Who knows.

> 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.

CORBA is the backbone for J2EE anyway, RMI/IIOP is the interop protocol
and CSIv2 is the secure interop protocol.

> 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.

Yes, it could have been done.

>>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.

No doubt about that, I have never claimed you could not do that,
and the OMG is certainly happy to subscribe to SOA with CORBA, too.
However, without a simplified, XML-based transport that does not
buy you any of the looser coupling and thus flexibility you don't
gain much here in terms of complexity reduction.

>  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.

It is more readable, but WSDL is not anything that I would want
to write manually anyway, so there is no point here. WSDL is generated.

>>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 :-) 

At least you don't think I have never loved CORBA in its youth (or
mine...) :-)

> How on earth is this any different from needing an XML Parser?

It means that you can get a text message from just about anywhere and
parse it through your favorite parser API, which is simpler than
doing the same thing with a GIOP message that did not arrive over
IIOP. It also means that it is simple to build a DOM tree in
memory to represent a SOAP message and then serialize that to anywhere,
or use a pre-made template message and just fill in parameters in
a script etc.

> 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.

There's a basic dilemma with IIOP that has been pointed out numerous
times in the past, viz. that you cannot correctly demarshal a message
without complete type information about the parameters. With XML
you can get just the parts that you are interested in (and know how
to process). This makes XML more suitable foor multi-part document
exchanges than IDL.

>>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.

When you wrap a legacy COBOL (or whatever) application, how many
times are you going to port the wrapper? Portability is great,
but sometimes not a crucial issue.

>>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.

Well, with JacORB you have to. There's no other OA. And the
other portability APIs in CORBA (ETF, PI) also make you go
through extra loops.

>>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.

If I can't convince you by saying that sending and receiving
SOAP messages is per se simpler because the message format
is so simple then obviously more arguing is not going to help.

>>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.

Hm, I don't see any existing technology other than Web Services that
can connect existing applications that are distributed internally and
are using a mix of CORBA, MQSeries, RMI, .NET, SMTP, and HTTP
internally. But I guess you will say I should be using CORBA, right?
Too bad my C#-ORB is just not up to it yet...

> 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. 

Agreed for the interface. But the point is that you need to agree
on data models, too. XML is a more suitable tool for that if you
are exchanging anything that looks more like a document than
a value object.

> Any company using a J2EE application server
> these days have the basic CORBA and Web Services facilities available in
> the app server.

Exactly.

> 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?

Not necessarily, as many companies have large investments in
existing non-CORBA and non-J2EE software. If all you need is
document exchange, why not skip the app server integration and
use XML right away?

Cheers, Gerald.

-- 
Gerald Brose, PhD                       mailto:brose@x...
Xtradyne Technologies                     http://www.xtradyne.com
Schoenhauser Allee 6-7,                  Phone: +49-30-440 306-27
D-10119 Berlin, Germany                  Fax  : +49-30-440 306-78