IDL Vs WSDL ---- a comparison

[Generic Usenet Account]

Does anyone have an opinion on how IDL and WSDL compare to each other?
Are they equally powerful in their "expressive power"? Sometimes it
appears to me that IDL is a little easier for humans to follow. Also,
it appears to be more compact.

Are IDL and WSDL equally powerful in expressing complex data types,
and describing inheritance and association relationships? What would
be the most compelling reasons to choose one over the other?

[Vivekanandan M]

Re: IDL Vs WSDL ---- a comparison

Hi ,

Please find an article on "IDL and WSDL - A Comparison" published
by Sankhya Technologies at Nasscom (one of the biggest software
companies association in India),

http://www.products.nasscom.org/artdisplay.aspx?art_id=2629&cat_id=474

Best Regards,

~Vivekanandan M

-------------------------------------------------------------------

Vivekanandan M
Sankhya Technologies Private Limited,
#30-15-58, "Silver Willow",
Third FLoor, DabaGardens,
Visakhapatnam - 530 020 INDIA

Tel : +91-891-5542666
Fax : +91-891-5542665

Visit us @ : http://www.sankhya.com

usenet@sta.sams ung.com (Generic Usenet Account) wrote in message news:<90e5135.0 405271429.6c170 153@posting.goo gle.com>...[color=blue]
> Does anyone have an opinion on how IDL and WSDL compare to each other?
> Are they equally powerful in their "expressive power"? Sometimes it
> appears to me that IDL is a little easier for humans to follow. Also,
> it appears to be more compact.
>
> Are IDL and WSDL equally powerful in expressing complex data types,
> and describing inheritance and association relationships? What would
> be the most compelling reasons to choose one over the other?[/color]

[Shashank]

Re: IDL Vs WSDL ---- a comparison


Generic Usenet Account wrote:
[color=blue]
> Does anyone have an opinion on how IDL and WSDL compare to each other?
> Are they equally powerful in their "expressive power"? Sometimes it
> appears to me that IDL is a little easier for humans to follow. Also,
> it appears to be more compact.[/color]

IDL and WSDL belong to different technology domain (CORBA and Web Services
resp. and though they are inter convertible i.e. IDL may be generated from
WSDL and vice versa.).

I agree too, that IDL is little (or much) easier for humans to follow and
is more compact.

[color=blue]
>
> Are IDL and WSDL equally powerful in expressing complex data types,
> and describing inheritance and association relationships? .[/color]

I believe they are equally powerful in expressing complex data types etc.


Well most compelling reasons to choose one over the other is like choosing
a middleware (CORBA) to Web Service.

While middleware technologies have matured standardized development,
deployment and run time support (becoming more powerful with (CCM) CORBA
Component Model) the web services is still to mature. It still lacks
standardization in security, transaction, distribution, stateful
interaction etc. to name a few.

You may find an interesting presentation by Markus Völter on "Components ,
Remoting Middleware and Webservices" and how all of them fit together,
available at following site

http://www.voelter.de/conferences/presentations.html

hope this helps.
regards,
Shashank

[Mark Woyna]

Re: IDL Vs WSDL ---- a comparison

usenet@sta.sams ung.com (Generic Usenet Account) wrote in message news:<90e5135.0 405271429.6c170 153@posting.goo gle.com>...[color=blue]
> Does anyone have an opinion on how IDL and WSDL compare to each other?
> Are they equally powerful in their "expressive power"? Sometimes it
> appears to me that IDL is a little easier for humans to follow. Also,
> it appears to be more compact.[/color]

How is that possible???!!! I thought XML was selected because it was
human readable???

Not.

<definitions name="StockQuot eService"
targetNamespace ="http://argonne.com/stockquoteservi ce.wsdl"
xmlns:tns="http ://argonne.com/stockquoteservi ce.wsdl"
xmlns:xsd1="htt p://argonne.com/stockquoteservi ce.xsd"
xmlns:soap="htt p://schemas.xmlsoap .org/wsdl/soap/"
xmlns:wsdl="htt p://schemas.xmlsoap .org/wsdl/">
<wsdl:types>
<xsd:schema targetNamespace ="http://argonne.com/stockquoteservi ce.xsd"
xmlns:xsd="http ://www.w3.org/2000/10/XMLSchema">
<xsd:element name="LastSaleR equest">
<xsd:complexTyp e>
<xsd:all>
<xsd:element name="stockSymb ol" type="string"/>
</xsd:all>
</xsd:complexType >
</xsd:element>
<xsd:element name="LastSaleP rice">
xsd:<complexTyp e>
<xsd:all>
<xsd:element name="price" type="float"/>
</xsd:all>
</xsd:complexType >
</xsd:element>
</xsd:schema>
</wsdl:types>
<wsdl:message name="getLastSa leInput">
<wsdl:part name="body" element="xsd1:L astSaleRequest"/>
</wsdl:message>
<wsdl:message name="getLastSa leOutput">
<wsdl:part name="body" element="xsd1:L astSalePrice"/>
</wsdl:message>
<wsdl:portTyp e name="StockQuot eServicePortTyp e">
<wsdl:operati on name="getLastSa le">
<wsdl:input message="tns:ge tLastSaleInput"/>
<wsdl:output message="tns:ge tLastSaleOutput "/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="StockQuot eServiceSoapBin ding"
type="tns:Stock QuoteServicePor tType">
<soap:binding style="document "
transport="http ://schemas.xmlsoap .org/soap/http"/>
<wsdl:operati on name="getLastSa le">
<soap:operati on soapAction="htt p://argonne.com/getLastSale"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="StockQuot eService">
<wsdl:documenta tion>Argonne Technologies Stock Quote
Service</documentation>
<wsdl:port name="StockQuot eServicePort"
binding="tns:St ockQuoteService Binding">
<soap:address
location="http://argonne.com/StockQuoteServi ce"/>
</wsdl:port>
</wsdl:service>



/* StockService IDL - not at all readable */

module stockServices {

typedef float LastSalePrice;

struct LastSaleRequest {
string stockSymbol;
};

interface StockService {
LastSalePrice getLastSale(in LastSaleRequest request);
};
};

[color=blue]
>
> Are IDL and WSDL equally powerful in expressing complex data types,
> and describing inheritance and association relationships?[/color]

Other than the fact that the Simple Object Access Protocol (SOAP) has
no concept of Objects, and is in no way simple?

WSDL has no concept of inheritance or objects. 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.
[color=blue]
> What would
> be the most compelling reasons to choose one over the other?[/color]

IDL == CORBA == Working == Boring 'ol technology.

WSDL == Web Services == Not quite there yet == Another buzzword to put
on a resume.

:-)

Mark

[Generic Usenet Account]

Re: IDL Vs WSDL ---- a comparison

woyna@argonne.c om (Mark Woyna) wrote in message news:<81158393. 0406010909.6e23 0875@posting.go ogle.com>...
<snip>[color=blue]
>
> WSDL has no concept of inheritance or objects. >[/color]
<snip>[color=blue]
> Mark[/color]


On the surface, lack of support for inheritance does appear to be a
serious limitation of WSDL, especially compared to IDL. Any thoughts?

Bhat

[Shashank]

Re: IDL Vs WSDL ---- a comparison


As said in earlier mail that IDL definitions can be mapped to WSDL definitions and vice versa. There is an
specification by OMG (CORBA to WSDL/SOAP Interworking Specification) that handles the mapping between IDL and
WSDL and vice versa.

For example:
In IDL, interfaces support multiple interface inheritance. WSDL does not have this construct and therefore
interface inheritance is mapped as repetition of the operations declared in the parenting interfaces. Types
declared within the parent interface scope are not repeated as that type space is available to the derived
interfaces.

So as such WSDL doesn't have limitation in carrying the information associated with an object that inherits
from multiple object definitions.

You may want to have a look at the above mentioned specification for full mapping.

regards,
Shashank

Generic Usenet Account wrote:
[color=blue]
> woyna@argonne.c om (Mark Woyna) wrote in message news:<81158393. 0406010909.6e23 0875@posting.go ogle.com>...
> <snip>[color=green]
> >
> > WSDL has no concept of inheritance or objects. >[/color]
> <snip>[color=green]
> > Mark[/color]
>
> On the surface, lack of support for inheritance does appear to be a
> serious limitation of WSDL, especially compared to IDL. Any thoughts?
>
> Bhat[/color]

[Gerald Brose]

Re: IDL Vs WSDL ---- a comparison

Mark Woyna wrote:[color=blue]
> usenet@sta.sams ung.com (Generic Usenet Account) wrote in message news:<90e5135.0 405271429.6c170 153@posting.goo gle.com>...
>[color=green]
>>Does anyone have an opinion on how IDL and WSDL compare to each other?
>> Are they equally powerful in their "expressive power"? Sometimes it
>>appears to me that IDL is a little easier for humans to follow. Also,
>>it appears to be more compact.[/color]
>
> How is that possible???!!! I thought XML was selected because it was
> human readable???[/color]

Perhaps there's a difference between "compact" and "human readable"? :-)
[color=blue][color=green]
>>Are IDL and WSDL equally powerful in expressing complex data types,
>>and describing inheritance and association relationships?[/color]
>
> Other than the fact that the Simple Object Access Protocol (SOAP) has
> no concept of Objects, and is in no way simple?[/color]

The original question was about WSDL, not SOAP. SOAP is a message
format that has not concept of object, true. (A better comparison
would be between GIOP and SOAP.) But it *is* simple, especially
when you look at GIOP.

Granted, the XML schema language that is used in WSDL for data
type definitions etc. is not that simple. Fortunately, very few
of us have to implement yet another XML parser.
[color=blue]
> WSDL has no concept of inheritance or objects.[/color]

True for WSDL 1.1, but WSDL 1.2 has inheritance, cf.

http://www.w3.org/TR/wsdl20/#Interface

[color=blue]
> 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.[/color]

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

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.).
[color=blue][color=green]
>>What would
>>be the most compelling reasons to choose one over the other?[/color][/color]

CORBA delivers better performance, and the type-safe IDL inter-
faces are well-suited for closely integrated intra-domain
applications.

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

Regards, Gerald

--
Gerald Brose, PhD mailto:brose@xt radyne.com
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

[David Eng]

Re: IDL Vs WSDL ---- a comparison

Gerald Brose <gerald.brose@x tradyne.com> wrote in message news:<2i5gvaFhv jq7U1@uni-berlin.de>...
[color=blue]
> 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...
>
> 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.).
>
> CORBA delivers better performance, and the type-safe IDL inter-
> faces are well-suited for closely integrated intra-domain
> applications.
>
> 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.
> 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...
>[/color]
Totally agree. The comparison between IDL and WSDL or Web service and
CORBA is meaningless because they address different abstraction in
which IDL addresses object model and WSDL addresses document model.
Web service shall be developed as an MOM-based middleware which
requires a document model instead of RPC-based or RMI-based middleware
which requires an object model. In this way, Web service and CORBA
are complementing each other instead of competing each other.
However, the focus and current development on RPC-based Web service is
very wrong, IMO. The mapping between IDL and WSDL makes no sense. I
don't know when market will realize this and shift the focus to
MOM-based Web service to replace Tibco, MQ, JMS, EAI, and bunch of
proprietary message middleware, so we can have a platform, language,
and vendor independent MOM-based Web service and RPC-based CORBA.
What a wonderful world!

[Mark Woyna]

Re: IDL Vs WSDL ---- a comparison

davideng2004@ya hoo.com (David Eng) wrote in message news:<6b74193f. 0406020749.3937 4b7c@posting.go ogle.com>...[color=blue]
> Gerald Brose <gerald.brose@x tradyne.com> wrote in message news:<2i5gvaFhv jq7U1@uni-berlin.de>...
>[color=green]
> > 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...
> >
> > 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.).
> >
> > CORBA delivers better performance, and the type-safe IDL inter-
> > faces are well-suited for closely integrated intra-domain
> > applications.
> >
> > 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.
> > 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...
> >[/color]
> Totally agree. The comparison between IDL and WSDL or Web service and
> CORBA is meaningless because they address different abstraction in
> which IDL addresses object model and WSDL addresses document model.
> Web service shall be developed as an MOM-based middleware which
> requires a document model instead of RPC-based or RMI-based middleware
> which requires an object model. In this way, Web service and CORBA
> are complementing each other instead of competing each other.
> However, the focus and current development on RPC-based Web service is
> very wrong, IMO. The mapping between IDL and WSDL makes no sense. I
> don't know when market will realize this and shift the focus to
> MOM-based Web service to replace Tibco, MQ, JMS, EAI, and bunch of
> proprietary message middleware, so we can have a platform, language,
> and vendor independent MOM-based Web service and RPC-based CORBA.
> What a wonderful world![/color]

CORBA has always had an MOM-like capability, i.e. Event Service, and
more recently asynchronous messaging capability (fire-and-forget) via
the Messaging Service specification, and is very much platform,
language, and vendor independent.

The fact that the proprietary MOM vendors never support the CORBA
Notification/Event Service is unfortunate, and reflects the power they
possessed to lock in their customers. The introducion of JMS was a
step in the right direction.

Associating CORBA with RPC style communication is misleading. The
ability to loosely couple CORBA objects has always been available. The
type of payload, e.g. document vs. message, is an application design
decision, not a middleware requirement.

I agree that the initial focus on Web Services has been in the RPC
area, and I'm not sure when the transition to document-centric
processing will occur.

[Mark Woyna]

Re: IDL Vs WSDL ---- a comparison

Gerald Brose <gerald.brose@x tradyne.com> wrote in message news:<2i5gvaFhv jq7U1@uni-berlin.de>...[color=blue]
>[color=green]
> > 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.[/color]
>
> 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...[/color]

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.
[color=blue]
>
> 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.).
>[color=green][color=darkred]
> >>What would
> >>be the most compelling reasons to choose one over the other?[/color][/color]
>
> CORBA delivers better performance, and the type-safe IDL inter-
> faces are well-suited for closely integrated intra-domain
> applications.[/color]

Agree, but reluctantly.
[color=blue]
>
> 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.[/color]

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.
[color=blue]
> 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...[/color]

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
[color=blue]
>
> Regards, Gerald[/color]

[Michael N. Christoff]

Re: IDL Vs WSDL ---- a comparison


"Mark Woyna" <woyna@argonne. com> wrote in message
news:81158393.0 406021410.470b0 d66@posting.goo gle.com...[color=blue]
> Gerald Brose <gerald.brose@x tradyne.com> wrote in message[/color]
news:<2i5gvaFhv jq7U1@uni-berlin.de>...[color=blue][color=green]
> >
> > 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.[/color]
>
> What is Web Services if not the next attempt at a homogeneous
> middleware layer???
>[/color]

The web services spec is homogenous, but the two ends of the wire need not
be the same type of middleware (as is required in the case of RMI, for
example). However, as mentioned, CORBA is not tied to any single language,
but, if I'm not mistaken, the languages need to be object-oriented.
[color=blue]
> 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.
>[color=green]
> > 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...[/color]
>
> 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.
>[/color]

Agreed. It seems like people are still thinking in terms of the days when
most web sites simply served up static html.



l8r, Mike N. Christoff

[Gerald Brose]

Re: IDL Vs WSDL ---- a comparison

Mark Woyna wrote:[color=blue]
> Gerald Brose <gerald.brose@x tradyne.com> wrote in message news:<2i5gvaFhv jq7U1@uni-berlin.de>...
>[color=green]
>>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.[/color]
>
>
> What is Web Services if not the next attempt at a homogeneous
> middleware layer???[/color]

It is a lot "less homogenous" than CORBA.
[color=blue]
> 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.[/color]

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.

The two models differ in important aspects. CORBA's, with the notion
of objects in the OO sense, is much richer; and more of the interaction
semantics is spelled out in the spec. While this is nice if you are
in an OO language, 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, 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)

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. You can use portable APIs (e.g. JAX-RPC) but you don't
have to. 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.

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.
[color=blue][color=green]
>>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...[/color]
>
>
> 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.[/color]

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.

Cheers, Gerald
--
Gerald Brose, PhD mailto:brose@xt radyne.com
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

[Örjan Petersson]

Re: IDL Vs WSDL ---- a comparison

"Michael N. Christoff" <mchristoff@sym patico.caREMOVE THIS> writes:
[color=blue]
> [...] However, as mentioned, CORBA is not tied to any single language,
> but, if I'm not mistaken, the languages need to be object-oriented.
>[/color]
Not necessarily object-oriented. There are official mappings for C,
Cobol, PL/I, ...
--
Orjan Petersson, Logcode SARL
The email address in the From: header is valid

[Christopher Browne]

Re: IDL Vs WSDL ---- a comparison

"Michael N. Christoff" <mchristoff@sym patico.caREMOVE THIS> wrote:[color=blue]
> However, as mentioned, CORBA is not tied to any single language,
> but, if I'm not mistaken, the languages need to be object-oriented.[/color]

You're mistaken. "object orientedness" is a _programming technique_,
and can be applied in just about any language. There are CORBA
bindings to languages like C and COBOL that are not typically
considered to be "abject oriented."
--
(format nil "~S@~S" "cbbrowne" "cbbrowne.c om")

http://cbbrowne.com/info/corba.html

"If we believe in data structures, we must believe in independent
(hence simultaneous) processing. For why else would we collect items
within a structure? Why do we tolerate languages that give us the one
without the other?" -- Alan Perlis

[Mark Woyna]

Re: IDL Vs WSDL ---- a comparison

Gerald Brose <gerald.brose@x tradyne.com> wrote in message news:<2i864aFji 3sfU1@uni-berlin.de>...[color=blue]
> Mark Woyna wrote:[color=green]
> > Gerald Brose <gerald.brose@x tradyne.com> wrote in message news:<2i5gvaFhv jq7U1@uni-berlin.de>...
> >[color=darkred]
> >>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.[/color]
> >
> >
> > What is Web Services if not the next attempt at a homogeneous
> > middleware layer???[/color]
>
> It is a lot "less homogenous" than CORBA.[/color]

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?
[color=blue]
>[color=green]
> > 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.[/color]
>
> 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.[/color]

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 interoperabilit y 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.
[color=blue]
>
> The two models differ in important aspects. CORBA's, with the notion
> of objects in the OO sense, is much richer;[/color]

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.
[color=blue]
> and more of the interaction
> semantics is spelled out in the spec. While this is nice if you are
> in an OO language,[/color]

I don't see what is has to do with the implementation language. It still
boils down to sending messages.
[color=blue]
> 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,[/color]

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?
[color=blue]
> 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)[/color]

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.
[color=blue]
>
> 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.[/color]

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.
[color=blue]
> You can use portable APIs (e.g. JAX-RPC) but you don't
> have to.[/color]

And you don't have to use POA. Selecting a portable API makes sense.
[color=blue]
> 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.[/color]

And this is no different that basic CORBA interoperabilit y. You're
not making a very compelling case.
[color=blue]
>
> 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.[/color]

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.
[color=blue]
>[color=green][color=darkred]
> >>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...[/color]
> >
> >
> > 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.[/color]
>
> 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.[/color]

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.
[color=blue]
>
> Cheers, Gerald[/color]

Likewise. :-)

Mark