Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


Re: IDL Vs WSDL ---- a comparison

From: woyna@-------.--- (---- -----)
To: NULL
Date: 6/2/2004 3:11:00 PM
Gerald Brose <gerald.brose@x...> wrote in message news:<2i5gvaFhvjq7U1@u...>...
> 
> > Granted, the overuse
> > of fine-grained distributed objects did give CORBA a performance black
> > eye in its early days (although no worse than the initial overuse of
> > J2EE Entity Beans), it is sometimes necessary to expose a handful of
> > stateful objects implementing the same interface in the same server.
> > Without the concept of object identity, this is not possible with
> > WSDL/SOAP, or at least not trivial.
> > 
> > Again, accepted practice is to expose singleton "service" objects,
> > i.e.
> > facade pattern, and keep entity objects behind the facade. Since
> > CORBA/IDL can implement either model, many believe that CORBA/IDL is
> > more powerful in this respect. On the otherhand, some have argued that
> > this capability makes CORBA/IDL  less "simple" that Web
> > Services/SOAP/WSDL.
> 
> The point for using Web Services is not that you cannot model
> services using CORBA, or that Web Services would be capable of doing
> everything better than CORBA can. Both statements are just wrong.
> This discussion is popping up again and again, as if Web Services
> were trying to be CORBA's successor for RPCs...

Well, that sure seems to be the case. Everyone seems to talk about a
document-centric view of Web Services, but every example I've ever
seem certainly appears to be RPC-like.

> 
> The point is that Web Services are better suited than CORBA for cross-
> domain B2B applications because of a few inherent properties of XML
> messaging, frequently summarized as loose coupling. (Extensibility,
> finer-grained contracts, marshalling with partial type information,
> etc.).
> 
> >>What would
> >>be the most compelling reasons to choose one over the other?
> 
> CORBA delivers better performance, and the type-safe IDL inter-
> faces are well-suited for closely integrated intra-domain
> applications.

Agree, but reluctantly.

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

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.

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

Mark

> 
> Regards, Gerald


transparent
Print
Mail
Like It
Disclaimer
.

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.

.
.

transparent

transparent