468,168 Members | 1,521 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,168 developers. It's quick & easy.

IDL Vs WSDL ---- a comparison

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?
Jul 20 '05 #1
24 7978
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/artd...629&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

us****@sta.samsung.com (Generic Usenet Account) wrote in message news:<90*************************@posting.google.c om>...
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?

Jul 20 '05 #2

Generic Usenet Account wrote:
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.
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.


Are IDL and WSDL equally powerful in expressing complex data types,
and describing inheritance and association relationships? .


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

Jul 20 '05 #3
us****@sta.samsung.com (Generic Usenet Account) wrote in message news:<90*************************@posting.google.c om>...
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.
How is that possible???!!! I thought XML was selected because it was
human readable???

Not.

<definitions name="StockQuoteService"
targetNamespace="http://argonne.com/stockquoteservice.wsdl"
xmlns:tns="http://argonne.com/stockquoteservice.wsdl"
xmlns:xsd1="http://argonne.com/stockquoteservice.xsd"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">
<wsdl:types>
<xsd:schema targetNamespace="http://argonne.com/stockquoteservice.xsd"
xmlns:xsd="http://www.w3.org/2000/10/XMLSchema">
<xsd:element name="LastSaleRequest">
<xsd:complexType>
<xsd:all>
<xsd:element name="stockSymbol" type="string"/>
</xsd:all>
</xsd:complexType>
</xsd:element>
<xsd:element name="LastSalePrice">
xsd:<complexType>
<xsd:all>
<xsd:element name="price" type="float"/>
</xsd:all>
</xsd:complexType>
</xsd:element>
</xsd:schema>
</wsdl:types>
<wsdl:message name="getLastSaleInput">
<wsdl:part name="body" element="xsd1:LastSaleRequest"/>
</wsdl:message>
<wsdl:message name="getLastSaleOutput">
<wsdl:part name="body" element="xsd1:LastSalePrice"/>
</wsdl:message>
<wsdl:portType name="StockQuoteServicePortType">
<wsdl:operation name="getLastSale">
<wsdl:input message="tns:getLastSaleInput"/>
<wsdl:output message="tns:getLastSaleOutput"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="StockQuoteServiceSoapBinding"
type="tns:StockQuoteServicePortType">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="getLastSale">
<soap:operation soapAction="http://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="StockQuoteService">
<wsdl:documentation>Argonne Technologies Stock Quote
Service</documentation>
<wsdl:port name="StockQuoteServicePort"
binding="tns:StockQuoteServiceBinding">
<soap:address
location="http://argonne.com/StockQuoteService"/>
</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);
};
};


Are IDL and WSDL equally powerful in expressing complex data types,
and describing inheritance and association relationships?
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.
What would
be the most compelling reasons to choose one over the other?


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

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

:-)

Mark
Jul 20 '05 #4
wo***@argonne.com (Mark Woyna) wrote in message news:<81**************************@posting.google. com>...
<snip>

WSDL has no concept of inheritance or objects. > <snip> Mark

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

Bhat
Jul 20 '05 #5

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:
wo***@argonne.com (Mark Woyna) wrote in message news:<81**************************@posting.google. com>...
<snip>

WSDL has no concept of inheritance or objects. >

<snip>
Mark


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

Bhat


Jul 20 '05 #6
Mark Woyna wrote:
us****@sta.samsung.com (Generic Usenet Account) wrote in message news:<90*************************@posting.google.c om>...
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.
How is that possible???!!! I thought XML was selected because it was
human readable???


Perhaps there's a difference between "compact" and "human readable"? :-)
Are IDL and WSDL equally powerful in expressing complex data types,
and describing inheritance and association relationships?


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


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.
WSDL has no concept of inheritance or objects.
True for WSDL 1.1, but WSDL 1.2 has inheritance, cf.
http://www.w3.org/TR/wsdl20/#Interface
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...

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.

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:br***@xtradyne.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

Jul 20 '05 #7
Gerald Brose <ge**********@xtradyne.com> wrote in message news:<2i************@uni-berlin.de>...
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...

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!
Jul 20 '05 #8
da**********@yahoo.com (David Eng) wrote in message news:<6b**************************@posting.google. com>...
Gerald Brose <ge**********@xtradyne.com> wrote in message news:<2i************@uni-berlin.de>...
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...

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!


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.
Jul 20 '05 #9
Gerald Brose <ge**********@xtradyne.com> wrote in message news:<2i************@uni-berlin.de>...
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

Jul 20 '05 #10

"Mark Woyna" <wo***@argonne.com> wrote in message
news:81**************************@posting.google.c om...
Gerald Brose <ge**********@xtradyne.com> wrote in message news:<2i************@uni-berlin.de>...

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


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


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

Jul 20 '05 #11
Mark Woyna wrote:
Gerald Brose <ge**********@xtradyne.com> wrote in message news:<2i************@uni-berlin.de>...
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.
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.

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

Cheers, Gerald
--
Gerald Brose, PhD mailto:br***@xtradyne.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

Jul 20 '05 #12
"Michael N. Christoff" <mc********@sympatico.caREMOVETHIS> writes:
[...] However, as mentioned, CORBA is not tied to any single language,
but, if I'm not mistaken, the languages need to be object-oriented.

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
Jul 20 '05 #13
"Michael N. Christoff" <mc********@sympatico.caREMOVETHIS> wrote:
However, as mentioned, CORBA is not tied to any single language,
but, if I'm not mistaken, the languages need to be object-oriented.


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.com")
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
Jul 20 '05 #14
Gerald Brose <ge**********@xtradyne.com> wrote in message news:<2i************@uni-berlin.de>...
Mark Woyna wrote:
Gerald Brose <ge**********@xtradyne.com> wrote in message news:<2i************@uni-berlin.de>...
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
Jul 20 '05 #15

"Örjan Petersson" <no****@logcode.com> wrote in message
news:ul***********@logcode.com...
"Michael N. Christoff" <mc********@sympatico.caREMOVETHIS> writes:
[...] However, as mentioned, CORBA is not tied to any single language,
but, if I'm not mistaken, the languages need to be object-oriented.

Not necessarily object-oriented. There are official mappings for C,
Cobol, PL/I, ...


I stand corrected.

l8r, Mike N. Christoff

Jul 20 '05 #16

"Christopher Browne" <cb******@acm.org> wrote in message
news:2i************@uni-berlin.de...
"Michael N. Christoff" <mc********@sympatico.caREMOVETHIS> wrote:
However, as mentioned, CORBA is not tied to any single language,
but, if I'm not mistaken, the languages need to be object-oriented.


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


I'll have to look up this so-called Abject-Oriented programming...

l8r, Mike N. Christoff

Jul 20 '05 #17
Mark Woyna wrote:
Gerald Brose <ge**********@xtradyne.com> wrote:
Mark Woyna wrote:
Gerald Brose <ge**********@xtradyne.com> 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:br***@xtradyne.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

Jul 20 '05 #18
Gerald Brose <ge**********@xtradyne.com> wrote in message news:<2i************@uni-berlin.de>...
Mark Woyna wrote:
Gerald Brose <ge**********@xtradyne.com> wrote:
Mark Woyna wrote:
Gerald Brose <ge**********@xtradyne.com> 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.


I don't implement the ORB, I buy it. :-) Seriously, I don't really
care how difficult the underlying spec is to implement, provided that
someone gets a kick out of doing it. Obviously, there are numerous
orbs available, so it's not impossible. :-)
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.


I still believe that if the IT industry had stuck to CORBA/IIOP, we
would see plenty of lightweight orbs around. Netscape embedded an orb
in the browser in 1996, as they saw the future of distributed objects
(services) that stretched beyond static web pages. Web Services are
another flavor of that vision.
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.


Unfortunately, IIOP was an afterthought. By the time IIOP was added to
RMI, it was too late. The Java is everywhere vision had already taken
hold.
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.


Arg. Isn't that one of the primary selling points of Web Services,
that they are easier to develop? If you need a tool to generate WSDL,
why couldn't you use a tool to generate IDL?

By the way, I bet you a beer that you couldn't write a valid WSDL file
from scratch for a less than trivial service without referencing a
textbook. ;-)
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...) :-)


Yes, you loved it enough to write a good book about it. :-)
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.


Sounds like a lot of busy work to simply get the data out of a
message. I'd rather have a stub class perform the work, created by
someone who likes that sort of thing. Me, I've got applications I have
to write. :-)
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.


This could have been added as either a) an additional protocol, or b)
adding a new datatype that supports semi-structured data. Actually,
the structured event part of the Notification Service spec sounds like
a close match.

My experience is that you don't get very far in extended message
formats until you hit some mandatory field that *every* client has to
understand and process. There just aren't that many optional fields in
B2B interactions. It doesn't matter if I was using a relational
database, CORBA, or XML.

Would I like the flexibility of adding a new field to a CORBA struct
without breaking my users? Sure. However, the minute I need that data
from them is the minute they all have to know the field.
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.


It's a nice insurance policy.
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.


What is simpler? I've posted several coding examples previously that
show that the equivalent CORBA code is much smaller and easier to read
than constructing and sending a SOAP message. Of course, if you use a
stub-based SOAP framework, you've effectively done the same thing that
every orb vendor provides.

In addition, we seem to agree that WSDL is practically unreadable next
to the equivalent IDL.

Having implemented an orb, I assume you are referring to the ORB
developer, in which case you're probably right. However, as a user of
the technology, I want to be shielded from the underlying complexity.
Isn't that one of the major reasons CORBA was invented? As long as
there is someone willing to develop orbs, I'm buying. :-)

Of course, if you hide all the nasty details of SOAP behind a tool,
then you're not really commenting on the ease of using the platform,
but rather the quality of the tool.

Here's the example code of using my simple CORBA-based StockService to
get a stock quote. You do these same for a Web Services based
implementation, including basic error handling and UDDI query. Agreed?

package com.argonne.stockServices;

import org.omg.CosNaming.*;
import com.argonne.idl.stockServices.*;

public class StockClient {
public static void main(String[] args) {
try {
org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init(args,null);

org.omg.CORBA.Object rootObj =
orb.resolve_initial_references("NameService");
NamingContextExt root =
NamingContextExtHelper.narrow(rootObj);
org.omg.CORBA.Object object =

root.resolve(root.to_name("MyStockService"));
StockService stockService =
StockServiceHelper.narrow(object);
float price = stockService.getLastSale("IBM");
System.out.println("IBM Last Sale: " + price);
}
catch (NotFoundException e) {
System.out.println("IBM Last Sale not found");
}
catch(Exception e) {
System.err.println("Oh no");
}
}
}

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.


Are all those applications passing around SOAP/XML messages today? No?
Well, then you're going to have modify every one of them, regardless
of the transport. Are there XML parsers available on all the
platforms?

If not, then you're going to have to write an adapter that understand
all the messages, and converts them to X before you can send it to
your business partners.
But I guess you will say I should be using CORBA, right?
Yup. :-)
Too bad my C#-ORB is just not up to it yet...
That's OK, you can use Java. I know a nice Java ORB that's probably up
to the task. :-) Since it runs on just about everything, including MS
platforms, it should do the trick.
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.


What about all the data that *isn't* a document? Is inventory data a
document? How about bank transactions? Market data from the financial
industry? I guess with XML everything begins to look like a document.
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.


Yes, software that probably doesn't speak SOAP/XML today. There's
still plenty of work to do.
If all you need is
document exchange, why not skip the app server integration and
use XML right away?
Yes, I guess we should simply send it via email. :-) Seriously, I
guess I just haven't seen a good set of document-centric examples to
convince me. Everything I've seen up to date has been RPC-style use of
SOAP/XML.

You're certainly not the only one stressing the importance of loosely
coupled, document-centric Web Services, but unfortunately there are
more people in the WS industry today providing RPC-style
examples/training/tools/etc. Current "popular" examples of Web
Services usage, e.g. Amazon, Google, are certainly RPC-like.

Cheers, Gerald.


A pleasure once again.

Mark
Jul 20 '05 #19
Mark Woyna wrote:
Gerald Brose <ge**********@xtradyne.com> wrote in message news:<2i************@uni-berlin.de>...
Mark Woyna wrote:
Gerald Brose <ge**********@xtradyne.com> wrote:

Mark Woyna wrote:

>Gerald Brose <ge**********@xtradyne.com> wrote:
<snip/>
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.


Arg. Isn't that one of the primary selling points of Web Services,
that they are easier to develop? If you need a tool to generate WSDL,
why couldn't you use a tool to generate IDL?


Sure you can, but that does not mean that Web Services are not
easy to develop.
By the way, I bet you a beer that you couldn't write a valid WSDL file
from scratch for a less than trivial service without referencing a
textbook. ;-)
I guess I'd be paying for that beer :-) but we also generate our
object code these days, so why not WSDL? BTW, people also use
compilers to arrive at legal IDL, and getting that value type
syntax right takes for a non-trivial CORBA app also takes some
experience.
At least you don't think I have never loved CORBA in its youth (or
mine...) :-)


Yes, you loved it enough to write a good book about it. :-)


Thanks. (If more people were loving CORBA, there would be a market
for a new edition by now).
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.

Sounds like a lot of busy work to simply get the data out of a
message. I'd rather have a stub class perform the work, created by
someone who likes that sort of thing. Me, I've got applications I have
to write. :-)


Perhaps this is actually the point of our argument here: I am not
thinking of writing new applications, and if I were writing one,
I guess I would not be using Web Services as the middleware unless
for some very specific XML requirements. I am mainly thinking of
EAI/B2B where all your apps are there already, and its a matter of
how your model your data (IDL or XML) and how easy it is to get
from existing interfaces (perhaps file-based) to message exchanges.
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.


This could have been added as either a) an additional protocol, or b)
adding a new datatype that supports semi-structured data. Actually,
the structured event part of the Notification Service spec sounds like
a close match.


True.
My experience is that you don't get very far in extended message
formats until you hit some mandatory field that *every* client has to
understand and process. There just aren't that many optional fields in
B2B interactions. It doesn't matter if I was using a relational
database, CORBA, or XML.

Would I like the flexibility of adding a new field to a CORBA struct
without breaking my users? Sure. However, the minute I need that data
from them is the minute they all have to know the field.
There's a subtle difference here: if you have different participants in
a multi-domain interaction that all share a document (say, in an
order-processing workflow), then they all care about different parts
of the document. Why should I have to rebuild all the software when
the changes concern only two of those guys?
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.


It's a nice insurance policy.


Granted. But we don't buy all those policies just because they
exost, do we ;-)?
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.

What is simpler? I've posted several coding examples previously that
show that the equivalent CORBA code is much smaller and easier to read
than constructing and sending a SOAP message. Of course, if you use a
stub-based SOAP framework, you've effectively done the same thing that
every orb vendor provides.

In addition, we seem to agree that WSDL is practically unreadable next
to the equivalent IDL.


It's a lot less readable, but with the XML mode in my emacs I can
make sense of it.
Having implemented an orb, I assume you are referring to the ORB
developer, in which case you're probably right. However, as a user of
the technology, I want to be shielded from the underlying complexity.
Isn't that one of the major reasons CORBA was invented? As long as
there is someone willing to develop orbs, I'm buying. :-)
That is true, of course. However, for niche markets, you are not
likely to find an "free lunch" ORB, so the buying may be very
expensive. What I claim is that in many cases grabbing data from
a legacy app, taking a SOAP toolkit and sending that data is
both cheaper and easier for the average developer.
Of course, if you hide all the nasty details of SOAP behind a tool,
then you're not really commenting on the ease of using the platform,
but rather the quality of the tool.
The nasty details are only syntax. (Let's assume that EJB is about
as far we can go to simplify CORBA by hiding POA programming behind
a few "bean type" patterns. Any "simpler" ways for the average
programmer, anyone?) This is still pretty complex. How far can tools
go, theoretically?
Here's the example code of using my simple CORBA-based StockService to
get a stock quote. You do these same for a Web Services based
implementation, including basic error handling and UDDI query.
Agreed?
No UDDI, as you are not using the Trader ;-).
package com.argonne.stockServices;

import org.omg.CosNaming.*;
import com.argonne.idl.stockServices.*;

public class StockClient {
public static void main(String[] args) {
try {
org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init(args,null);

org.omg.CORBA.Object rootObj =
orb.resolve_initial_references("NameService");
NamingContextExt root =
NamingContextExtHelper.narrow(rootObj);
org.omg.CORBA.Object object =

root.resolve(root.to_name("MyStockService"));
StockService stockService =
StockServiceHelper.narrow(object);
float price = stockService.getLastSale("IBM");
System.out.println("IBM Last Sale: " + price);
}
catch (NotFoundException e) {
System.out.println("IBM Last Sale not found");
}
catch(Exception e) {
System.err.println("Oh no");
}
}
}
This is not a very useful comparison as you are using a stub-based
RPC approach which I can do, too, and then the code is almost identical.
Anyway, here it is, using the JAX-RPC API (this code is stolen off
ttp://www.sys-con.com/webservices/articleprint.cfm?id=585). It has
just four statements because it does not do a name service lookup.

package stockquote;

import javax.xml.rpc.Stub;

public class StockQuoteClient
{
public static void main(String[] args)
{
try
{
Stub stub =
(Stub)(new MyStockQuoteService_Impl().getStockQuoteIFPort());
stub._setProperty(javax.xml.rpc.Stub.ENDPOINT_ADDR ESS_PROPERTY,
args[0]);
StockQuoteIF stock = (StockQuoteIF)stub;
System.out.println(stock.getQuote("IBM"));
}
catch (Exception ex)
{
System.err.println("Oh no");
}
}
}

Had you used the DII to make an asynchronous call, then you could
compare with this code:

http://www.xmethods.net/download/ser...oteClient.java
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.


What about all the data that *isn't* a document? Is inventory data a
document? How about bank transactions? Market data from the financial
industry? I guess with XML everything begins to look like a document.


Pretty much :-)
If all you need is
document exchange, why not skip the app server integration and
use XML right away?


Yes, I guess we should simply send it via email. :-)


Well, there is a place for e-mail as middleware, as there is for
many other apparently trivial connectors. Would you sent customer
news letters out of your document management systems using CORBA :-)?
You're certainly not the only one stressing the importance of loosely
coupled, document-centric Web Services, but unfortunately there are
more people in the WS industry today providing RPC-style
examples/training/tools/etc. Current "popular" examples of Web
Services usage, e.g. Amazon, Google, are certainly RPC-like.


True. BTW, there is a really good new book on Web Services, just
in case anybody is interested:
http://www.amazon.com/exec/obidos/tg...91836?v=glance
Cheers, Gerald.


A pleasure once again.


Thanks for the enjoyable conversation,
Gerald.
--
Gerald Brose, PhD mailto:br***@xtradyne.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

Jul 20 '05 #20
Gerald Brose <ge**********@xtradyne.com> wrote in message news:<2i************@uni-berlin.de>...
(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.)


Thanks for the reference, Gerald. In fact, I've written a number of
papers and articles related to this very IDL/WSDL topic. You can find
the dark matter paper and the others here:

<http://dsonline.computer.org/0210/d/w5midd.htm>
<http://www.iona.com/hyplan/vinoski/pdfs/IEEE-Integration_With_Web_Services.pdf>
<http://www.iona.com/hyplan/vinoski/pdfs/IEEE-Web_Services_Interaction_Models_Part_1.pdf>
<http://www.iona.com/hyplan/vinoski/pdfs/IEEE-Web_Services_Interaction_Models_Part_2.pdf>
<http://www.cuj.com/documents/s=7990/cujcexp1910vinoski/>

I should also mention some relevant OMG work that IONA is leading at
the moment. At the previous meeting, back at the end of April, we
succeeded in getting the OMG to issue an RFP for a WSDL-to-C++
mapping:

<http://www.omg.org/cgi-bin/apps/do_doc?mars/04-04-22.pdf>

At the next meeting later this month, I'll be presenting a proposal
that the OMG issue an RFP for a CORBA binding for WSDL. Most people
associate only SOAP with WSDL, but WSDL is in fact specifically
designed to be extended with non-SOAP bindings. Some of this is
discussed in the second paper referenced above.

At IONA we have a product called Artix that supports WSDL-based access
for CORBA systems, MQ Series, Tuxedo, TIBCO, SOAP, J2EE. This is not a
SOAP-to-whatever bridge, but instead supports native bindings for
these technologies (though it can also bridge SOAP to these other
things). The Artix WSDL CORBA binding is the one we'll submit to the
OMG if the accept our above-mentioned proposal and issue the RFP. You
can read more about Artix and download a free Artix developer kit
here:

<http://www.iona.com/products/artix/welcome.htm>

Artix gives you the best of both worlds, in that it preserves your
investment in CORBA, while also allowing you to marry it rather
seamlessly and with high performance to other middleware and to web
services.

--steve
Jul 20 '05 #21

"Gerald Brose" <ge**********@xtradyne.com> wrote in message
news:2i************@uni-berlin.de...
Mark Woyna wrote:
Gerald Brose <ge**********@xtradyne.com> wrote:
Mark Woyna wrote:
Gerald Brose <ge**********@xtradyne.com> wrote:


A problem I see is that many people (not implying you personally) already
have the mindset of SOA being the new "magic bullet" for distributed
software developement. SOA is wondeful for a lot of things, especially
enterprise business applications. However I wouldn't say, for example, its
the best architecture for p2p networking. With the lower number of
connections a typical peer has, maintaing stateful connections is not nearly
the same problem it would be on say, google (which actually provides its own
webservices).
http://www.google.com/apis/

l8r, Mike N. Christoff

Jul 20 '05 #22
Steve,

The first link you reference doesn't work:

http://dsonline.computer.org/0210/d/w5midd.htm
"The requested object does not exist on this server. The link you followed
is either outdated, inaccurate, or the server has been instructed not to let
you have it."

Alan.
"Steve Vinoski" <vi*****@ieee.org> wrote in message
news:6c**************************@posting.google.c om...
Gerald Brose <ge**********@xtradyne.com> wrote in message news:<2i************@uni-berlin.de>...
(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.)


Thanks for the reference, Gerald. In fact, I've written a number of
papers and articles related to this very IDL/WSDL topic. You can find
the dark matter paper and the others here:

<http://dsonline.computer.org/0210/d/w5midd.htm>

<http://www.iona.com/hyplan/vinoski/p...h_Web_Services.
pdf> <http://www.iona.com/hyplan/vinoski/p...eraction_Model
s_Part_1.pdf> <http://www.iona.com/hyplan/vinoski/p...eraction_Model
s_Part_2.pdf> <http://www.cuj.com/documents/s=7990/cujcexp1910vinoski/>

I should also mention some relevant OMG work that IONA is leading at
the moment. At the previous meeting, back at the end of April, we
succeeded in getting the OMG to issue an RFP for a WSDL-to-C++
mapping:

<http://www.omg.org/cgi-bin/apps/do_doc?mars/04-04-22.pdf>

At the next meeting later this month, I'll be presenting a proposal
that the OMG issue an RFP for a CORBA binding for WSDL. Most people
associate only SOAP with WSDL, but WSDL is in fact specifically
designed to be extended with non-SOAP bindings. Some of this is
discussed in the second paper referenced above.

At IONA we have a product called Artix that supports WSDL-based access
for CORBA systems, MQ Series, Tuxedo, TIBCO, SOAP, J2EE. This is not a
SOAP-to-whatever bridge, but instead supports native bindings for
these technologies (though it can also bridge SOAP to these other
things). The Artix WSDL CORBA binding is the one we'll submit to the
OMG if the accept our above-mentioned proposal and issue the RFP. You
can read more about Artix and download a free Artix developer kit
here:

<http://www.iona.com/products/artix/welcome.htm>

Artix gives you the best of both worlds, in that it preserves your
investment in CORBA, while also allowing you to marry it rather
seamlessly and with high performance to other middleware and to web
services.

--steve

Jul 20 '05 #23
Hi Alan,
Try this link http://dsonline.computer.org/0210/d/wp5midd.htm

regards
anand

Alan Walker wrote:
Steve,

The first link you reference doesn't work:

http://dsonline.computer.org/0210/d/w5midd.htm
"The requested object does not exist on this server. The link you followed
is either outdated, inaccurate, or the server has been instructed not to let
you have it."

Alan.

"Steve Vinoski" <vi*****@ieee.org> wrote in message
news:6c**************************@posting.google.c om...
Gerald Brose <ge**********@xtradyne.com> wrote in message

news:<2i************@uni-berlin.de>...
(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.)


Thanks for the reference, Gerald. In fact, I've written a number of
papers and articles related to this very IDL/WSDL topic. You can find
the dark matter paper and the others here:

<http://dsonline.computer.org/0210/d/w5midd.htm>

<http://www.iona.com/hyplan/vinoski/p...h_Web_Services.
pdf>

<http://www.iona.com/hyplan/vinoski/p...eraction_Model
s_Part_1.pdf>

<http://www.iona.com/hyplan/vinoski/p...eraction_Model
s_Part_2.pdf>
<http://www.cuj.com/documents/s=7990/cujcexp1910vinoski/>

I should also mention some relevant OMG work that IONA is leading at
the moment. At the previous meeting, back at the end of April, we
succeeded in getting the OMG to issue an RFP for a WSDL-to-C++
mapping:

<http://www.omg.org/cgi-bin/apps/do_doc?mars/04-04-22.pdf>

At the next meeting later this month, I'll be presenting a proposal
that the OMG issue an RFP for a CORBA binding for WSDL. Most people
associate only SOAP with WSDL, but WSDL is in fact specifically
designed to be extended with non-SOAP bindings. Some of this is
discussed in the second paper referenced above.

At IONA we have a product called Artix that supports WSDL-based access
for CORBA systems, MQ Series, Tuxedo, TIBCO, SOAP, J2EE. This is not a
SOAP-to-whatever bridge, but instead supports native bindings for
these technologies (though it can also bridge SOAP to these other
things). The Artix WSDL CORBA binding is the one we'll submit to the
OMG if the accept our above-mentioned proposal and issue the RFP. You
can read more about Artix and download a free Artix developer kit
here:

<http://www.iona.com/products/artix/welcome.htm>

Artix gives you the best of both worlds, in that it preserves your
investment in CORBA, while also allowing you to marry it rather
seamlessly and with high performance to other middleware and to web
services.

--steve


Jul 20 '05 #24
> Steve,

The first link you reference doesn't work:

http://dsonline.computer.org/0210/d/w5midd.htm
"The requested object does not exist on this server. The link you followed
is either outdated, inaccurate, or the server has been instructed not to let
you have it."


Try this instead:
http://dsonline.computer.org/0210/d/wp5midd.htm

Cheers,
Brian
IONA Technologies
Jul 20 '05 #25

This discussion thread is closed

Replies have been disabled for this discussion.

By using this site, you agree to our Privacy Policy and Terms of Use.