SOAP, what's the big deal?
scleme...@my-deja.com
It is to replace the use of CORBA? If so, why?
It seems to be tied to XML. Is everyone gonna have to use XML for
everything to be SOAPy?
There seems to be a lot of hype behind SOAP (a la Microsoft), is
it valid?
Sent via Deja.com http://www.deja.com/
Before you buy.
Martin v.Loewis
>What is the situation with SOAP? What is it for?
It is an XML-based RPC protocol.
>It is to replace the use of CORBA? If so, why?
The others of SOAP intend that it replaces all "proprietary" RPC mechanisms,
such as DCOM, DCE/RPC, and CORBA. They claim it is a simpler protocol, and
provides better interoperability.
I believe SOAP introduces more problems than it solves, since it is in fact
not a single protocol, but a family of them; each application needs to define
its own message body format (in terms of XML entities). That will cause an
interoperability nightmare.
>It seems to be tied to XML. Is everyone gonna have to use XML for
>everything to be SOAPy?
Yes, use of XML on the wire is mandatory for SOAP.
>There seems to be a lot of hype behind SOAP (a la Microsoft), is
>it valid?
I'm not sure what you mean by valid. The SOAP specification, to my knowledge,
is "correct", meaning that it probably can work as specified.
The "official" position of the OMG on SOAP is that OMG is in the process
of defining a SOAP transport mechanism for CORBA, so that ORBs may receive
and emit SOAP requests that are understood as CORBA requests in a standard
way. That will allow interoperability between a CORBA application and a
pure SOAP application.
Regards,
Martin
Dieter Maurer
> >It is to replace the use of CORBA? If so, why?
>
> The others of SOAP intend that it replaces all "proprietary" RPC mechanisms,
> such as DCOM, DCE/RPC, and CORBA. They claim it is a simpler protocol, and
> provides better interoperability.
>
> I believe SOAP introduces more problems than it solves, since it is in fact
> not a single protocol, but a family of them; each application needs to define
> its own message body format (in terms of XML entities). That will cause an
> interoperability nightmare.
Each application defines its own interfaces.
Dieter
Marvin Wolfthal
(GIOP) guarantees interoperability, allowing you to
define whatever application level interfaces you require
without having to worry about interoperability
(assuming correct implementations, of course).
---------------------------------------------------------
Marvin Wolfthal
Chief Architect
IMRglobal (617) 914-0317
mwol...@imrglobal.com
m...@dvlp.imrglobal.com
"Dieter Maurer" <die...@handshake.de> wrote in message
news:x7u285j...@lindm.dm...
Martin v.Loewis
Dieter Maurer <die...@handshake.de> wrote:
>> I believe SOAP introduces more problems than it solves, since it is in fact
>> not a single protocol, but a family of them; each application needs to define
>> its own message body format (in terms of XML entities). That will cause an
>> interoperability nightmare.
>Is that not the same for CORBA?
> Each application defines its own interfaces.
Indeed. Therefore, CORBA has built quite some sizeable infastructure for
dealing with application-specific interfaces: IDL syntax and semantics,
IDL language mappings, etc.
There is no equivalent of such application-awareness in SOAP, AFAIK: no
IDL, no language mappings (although perhaps a DTD could count as an
interface definition). I believe a common assumption is that it is easy
to generate SOAP messages, e.g. with plain C printf statements. That will
lead to dialects of an interface, since slight modifications may pass
unnoticed for a while. In essence, I predict the interoperability problems
that CORBA had in the early days of GIOP.
To get true interoperability, a mere publishing of the interface that some
service offers is not enough - one also has to widely agree (e.g. within
an application domain) what interfaces to use for a specific service. For
CORBA, there have been years-long activities to define interfaces in various
domains (CORBAmed, electronic commerce, telecom, etc). The same amount of
standardization will be necessary for SOAP to make it useful; they can copy
the CORBA interfaces, of course.
Regards,
Martin
Frankey
tells you; but then they said the same about dde and mdi and ole and dcom and .net.) It's
just a bunch of text on the wire, the primary reason as I understand is to let the stream
of protocol data through firewalls.
> It is to replace the use of CORBA?
No, it's rather to replace IIOP.
> If so, why?
> It seems to be tied to XML. Is everyone gonna have to use XML for
> everything to be SOAPy?
SOAP is XML, but not all XML is SOAP <g>. SOAP is one of the potential uses of XML.
> There seems to be a lot of hype behind SOAP (a la Microsoft), is
> it valid?
No comment. Have you used dde lately (TM)?
James Logajan
> > scleme...@my-deja.com wrote:
> > There seems to be a lot of hype behind SOAP (a la Microsoft), is
> > it valid?
> No comment. Have you used dde lately (TM)?
I think the software industry should wash it hands of SOAP. It is solution
for which no problem exists.
Michi Henning
Actually, the problem does exist: how do I do RPC between heterogeneous
systems? The interesting point is that the problem has been solved already.
So, more accurately, I would say that SOAP (largely) solves a solved problem.
What concerns me more than anything else is the horrendous cost of using
SOAP. The representation is extremely bulky. For many messages, the
bandwidth required is easily 50-100 times that of IIOP. Further, the cost
marshaling and unmarshaling these messages is very high, on the order
of a 100 times the CPU cycles required for IIOP.
The net result is that, with SOAP, you will get the same performance out of
a 5 Mb dedicated link as you get when running IIOP over a 56 kb modem.
Bandwidth and CPU time are cheap, yes, but not *that* cheap.
Despite that, SOAP will play an important role, but not as a universally-used
RPC protocol. Instead, I see it being used for coarse-grained, batch-like
interactions across administrative boundaries, with other protocols, such
as IIOP, being used for communications within those boundaries.
Cheers,
Michi.
--
Michi Henning +61 7 3324 9633
Object Oriented Concepts +61 4 1118 2700 (mobile)
Suite 4, 8 Martha St +61 7 3324 9799 (fax)
Camp Hill 4152 mi...@ooc.com.au
Brisbane, AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html
Frankey
> On Sat, 23 Dec 2000, James Logajan wrote:
> > Frankey wrote:
> > > > scleme...@my-deja.com wrote:
> > > > There seems to be a lot of hype behind SOAP (a la Microsoft), is
> > > > it valid?
> > > No comment. Have you used dde lately (TM)?
> >
> > I think the software industry should wash it hands of SOAP. It is solution
> > for which no problem exists.
>
> Actually, the problem does exist: how do I do RPC between heterogeneous
> systems?
well. What's the difference? You define a protocol, end of story. SOAP isn't needed for
that, it's needed to eliminate the problems that regular ??P/IP has going through the
firewalls. Text doesn't have that problem. That's what you need SOAP for. You pump XML to
web servers and they execute what's necessary and send text back, firewalls or not.
> What concerns me more than anything else is the horrendous cost of using
> SOAP.
Right you are. Now, since when does MS worry about cost of using anything? Just upgrade
your hardware <g>...
Josef Stadelmann
I think SOAP/XML tends to jump alos into areas previously owned by EDI
(Electronic document exchange) which was used to exchange documents
(as the name states) betwen companies having different systems.
I ask one question: Can we exchange today a bill for a truck's load
delivered
in a standard form(at) via EDI with every company getting load/goods
delivered
by a truck world wide. If EDI has solved this problem then SOAP/XML migth
be able to solve it one more time. But as far as I know, this problem was
never
fixed by EDI on a world wide standard base.
The contract how bills for that reason have to look like is missing.
Now: XML gives you at least self describing data (no more no less)
Saing it is still up to you to apply and agree up on the same semantic
to a bit of self describing data to understand each other.
so wheres the contract between SOAP/XML based systems talking to
each other. I know that for shure if I talk CORBA; it's IDL.
Sepp
"Michi Henning" <mi...@ooc.com.au> wrote in message
news:Pine.HPX.4.05.100122...@bobo.ooc.com.au...
Martin v.Loewis
Josef Stadelmann <stad...@datazug.ch> wrote:
>I think SOAP/XML tends to jump alos into areas previously owned by EDI
>(Electronic document exchange) which was used to exchange documents
>(as the name states) betwen companies having different systems.
Well, the name really means "Electronic Data Interchange", so it was, as
the name states, used to exchange data between companies having different
systems.
As such, EDI is a description of general procedures (you shall exchange
your data over the via instead of by snail mail). Commonly, EDI is also
associated with national and international standards, such as EDIFACT.
>I ask one question: Can we exchange today a bill for a truck's load
>delivered in a standard form(at) via EDI with every company getting load/goods
>delivered by a truck world wide.
I'm not and EDIFACT expert, but it appears that the "Invoice message"
message could be used, see
http://www.unece.org/trade/untdid/d95a/trmd/invoic_d.htm
>If EDI has solved this problem then SOAP/XML migth
>be able to solve it one more time. But as far as I know, this problem was
>never fixed by EDI on a world wide standard base.
Well, and why do you think it was not solved? *If* it was not solved,
I guess that's not because the parties couldn't agree on a wire format.
More likely, they couldn't agree on the information model of a bill
for a truck's load. Why do you think that using XML would do any better?
You still have to define what information you want to have in the bill,
and how that information is structured.
>The contract how bills for that reason have to look like is missing.
>Now: XML gives you at least self describing data (no more no less)
Nah, what exactly would
<bill>
<payto>23572065</payto>
<good amount="5">34589</good>
<good amount="2">34892</good>
<value>34.56</value>
</bill>
mean to you? It's a myth that XML is self-describing when it comes to
money, banking, and traders.
Regards,
Martin
Stefan Loidl
>
> The contract how bills for that reason have to look like is missing.
> Now: XML gives you at least self describing data (no more no less)
>
> Saing it is still up to you to apply and agree up on the same semantic
> to a bit of self describing data to understand each other.
>
> so wheres the contract between SOAP/XML based systems talking to
> each other. I know that for shure if I talk CORBA; it's IDL.
>
> Sepp
Hi,
isn't the contract in the XML world an XML DTD?
I think an XML DTD is the equivalent to the CORBA IDL,
or am I wrong?
Greetings,
Stefan
--
Stefan Loidl Phone: +49 89 289-28882
Leibniz Supercomputing Center Fax: +49 89 2809460
Barer Str. 21 mailto:lo...@lrz.de
80333 Munich, Germany http://www.lrz.de
cbbr...@hex.net
> Josef Stadelmann wrote:
> > The contract how bills for that reason have to look like is missing.
> > Now: XML gives you at least self describing data (no more no less)
> >
> > Saing it is still up to you to apply and agree up on the same semantic
> > to a bit of self describing data to understand each other.
> >
> > so wheres the contract between SOAP/XML based systems talking to
> > each other. I know that for shure if I talk CORBA; it's IDL.
>
> I think an XML DTD is the equivalent to the CORBA IDL,
> or am I wrong?
There are a few flies in that ointment:
a) The "new thing" is to establish the contract as a "schema" rather
than via a DTD; DTDs are being somewhat deprecated.
b) DTDs (and schema) are considered _optional_ for XML (unlike with
SGML);
c) DTDs really only indicate the permissible "structuring" of the
data; they have vastly more limited "type" indications.
Where IDL offers long, char, string, double, and such, a DTD limits
you to something like a choice between "string and enum."
If you're willing to be real fuzzy about interpreting "equivalence,"
then yes, IDL and a DTD are "somewhat equivalent."
It is probably more accurate to use the phrase "vaguely analagous."
--
(reverse (concatenate 'string "ac.notelrac.teneerf@" "454aa"))
<http://www.ntlug.org/~cbbrowne/>
What hair color do they put on the driver's licenses of bald men?
Martin v.Loewis
<cbbr...@hex.net> wrote:
d) For IDL, language mappings define exactly how to use the interface in
a program. For DTDs/Schema, there are proprietary solutions for selected
languages the best you can get.
>It is probably more accurate to use the phrase "vaguely analagous."
I agree.
Martin
Marcel Ruff
>
> What concerns me more than anything else is the horrendous cost of using
> SOAP. The representation is extremely bulky. For many messages, the
> bandwidth required is easily 50-100 times that of IIOP. Further, the cost
> marshaling and unmarshaling these messages is very high, on the order
> of a 100 times the CPU cycles required for IIOP.
>
> The net result is that, with SOAP, you will get the same performance out of
> a 5 Mb dedicated link as you get when running IIOP over a 56 kb modem.
> Bandwidth and CPU time are cheap, yes, but not *that* cheap.
I haven't played with SOAP, but i have made some performance measures
with XML-RPC. Assuming that SOAP has approximately the same performance
as XML-RPC i would say that the bandwidth required for SOAP/XML-RPC
is at most 10 times compared to CORBA, see
http://www.xmlBlaster.org/performance.html
I like CORBA, but it is for my feeling to strictly connecting
massively distributed systems.
Large distributed systems (for example the internet) could not
be built with CORBA, it is just to rigid.
Another drawback of CORBA is that it tries to hide the low level
connection (for example TCP/IP), but you can't ignore it.
When programming distributed, you always need to be aware
that the objects are distributed, and failures of components
are common and 'allowed'.
Marcel
--
Marcel Ruff
mailto:ru...@swand.lake.de
http://www.lake.de/home/lake/swand/
http://www.xmlBlaster.org
Brian Kelly
> with XML-RPC. Assuming that SOAP has approximately the same performance
> as XML-RPC i would say that the bandwidth required for SOAP/XML-RPC
> is at most 10 times compared to CORBA, see
>
> http://www.xmlBlaster.org/performance.html
That's an interesting report - however I couldn't find details
of the types of messages being sent. I'm interested in the performance
of different types / nesting levels in CORBA vs. XML-RPC. Do you have
that data available for your benchmark?
Thanks,
Brian
Stefan Seefeld
> I like CORBA, but it is for my feeling to strictly connecting
> massively distributed systems.
I don't understand that sentence. Could you please rephrase it ?
What do you mean with 'strictly connecting' ?
Regards, Stefan
_______________________________________________________
Stefan Seefeld
Departement de Physique
Universite de Montreal
email: seef...@magellan.umontreal.ca
_______________________________________________________
...ich hab' noch einen Koffer in Berlin...
Douglas C. Schmidt
> I like CORBA, but it is for my feeling to strictly connecting
> massively distributed systems.
You might feel this way, but many other folks feel quite differently.
CORBA is used for all sorts of applications, ranging from large-scale
distributed systems connected via the Internet to small footprint
embedded and real-time systems. Check out
http://www.corba.org/success.htm
for the official OMG "success stories" page to learn more about the
wide range of applications that CORBA's been applied on. For
information about the use of CORBA for embedded and real-time systems,
you might check out
http://www.cs.wustl.edu/~schmidt/TAO-users.html
Other ORB Web sites have similar information, which you can learn
about by following the links at
http://www.cs.wustl.edu/~schmidt/corba-products.html
Take care,
Doug
--
Dr. Douglas C. Schmidt, Associate Professor TEL: (949) 824-1901
Dept of Electrical & Computer Engineering FAX: (949) 824-2321
616E Engineering Tower WEB: www.ece.uci.edu/~schmidt/
University of California, Irvine, 92697-2625 NET: sch...@uci.edu
Marcel Ruff
Sorry no, this little test can't be called a benchmark,
i just published some messages with the different protocols
to get a feeling for the performance.
If you want to run the test yourself just download
the xmlBlaster distribution and run the to processes as
described above the gif-image (there is no installation steps
like CLASSPATH etc. necessary).
Start the server (change to the xmlBlaster root directory first)
java -Xms18M -Xmx32M -jar lib/xmlBlaster.jar
the xmlBlaster server has all protocols switched on as default.
To change the protocol used, you can invoke the client
with the options
java -Xms18M -Xmx32M -cp lib/xmlBlaster.jar
testsuite.org.xmlBlaster.LoadTestSub -client.protocol XML-RPC
java -Xms18M -Xmx32M -cp lib/xmlBlaster.jar
testsuite.org.xmlBlaster.LoadTestSub -client.protocol IIOP
java -Xms18M -Xmx32M -cp lib/xmlBlaster.jar
testsuite.org.xmlBlaster.LoadTestSub -client.protocol RMI
regards,
Marcel Ruff
>
> Marcel Ruff wrote:
>
> > I like CORBA, but it is for my feeling to strictly connecting
> > massively distributed systems.
>
> I don't understand that sentence. Could you please rephrase it ?
> What do you mean with 'strictly connecting' ?
Well, CORBA components have not inherently a 'generic' interface,
the CORBA IDL interfaces are usually a view on a server object.
When you have a distributed system where software of many companies
is connected together with CORBA, nobody will dare to
change the interface easily, since all companies
must agree, code the extension/change as well and install
the modification at the same time (ok, this is a worst case).
The marketing people from each company will complain how
complicated this change is, and that it will cost
100-thousands of dollars.
So the poor project manager of the system,
after many conferences, meetings, quotes
and months of discussion and huge piles of paper
will be fustrated about the
effort to only make a little modification with the interface
and quits his job to be a farmer.
Every software i know is in a permanent flow with
new requirements, the permanent change of software
systems is a fact.
Often a generic interface can help to reduce this
rigid coupling of components following an important rule:
Use simple interfaces for distributed components!
The MOM paradigm is a good example.
best regards,
Michi Henning
> I haven't played with SOAP, but i have made some performance measures
> with XML-RPC. Assuming that SOAP has approximately the same performance
> as XML-RPC i would say that the bandwidth required for SOAP/XML-RPC
> is at most 10 times compared to CORBA, see
>
> http://www.xmlBlaster.org/performance.html
Well, here is an example:
POST /StockQuote HTTP/1.1
Host: www.stockquoteserver.com
Content-Type: text/xml
Content-Length: nnnn
SOAPMethodName: Some-Namespace-URI#GetLastTradePrice
<SOAP:Envelope xmlns:SOAP="urn:schemas-xmlsoap-org:soap.v1">
<SOAP:Body>
<m:GetLastTradePrice xmlns:m="Some-Namespace-URI">
<symbol>DIS</symbol>
</m:GetLastTradePrice>
</SOAP:Body>
</SOAP:Envelope>
That's ~360 bytes to invoke an RPC with a single in parameter of three bytes.
The reply looks something like:
HTTP/1.1 200 OK
Content-Type: text/xml
Content-Length: nnnn
<SOAP:Envelope xmlns:SOAP="urn:schemas-xmlsoap-org:soap.v1">
<SOAP:Body>
<m:GetLastTradePriceResponse xmlns:m="Some-Namespace-URI">
<return>34.5</return>
</m:GetLastTradePriceResponse>
</SOAP:Body>
</SOAP:Envelope>
That's around 280 bytes for a single floating-point return value.
With IIOP, the same thing takes about 60 bytes for the request and 28 bytes
for the reply. (And, IIOP is not particularly careful to conserve bandwidth;
HTTP-NG manages to do the same thing in about a dozen bytes each for
request and reply.)
Here is the IDL for sending a sequence of 128 structs:
enum ProductType { Apple, Peach, Orange };
typedef float PriceType;
struct Product {
ProductType product;
PriceType price;
};
typedef Product Order[128];
interface Foo {
Order op(in Order p);
};
The SOAP request for this takes approximately 10 kB, as does the reply.
With IIOP, request and reply take about 1 kB each.
If you have structs with more members (something that's very common),
the bandwidth difference can easily exceed a factor of 100. This means
that a 5 Mb dedicated leased line will move about as much traffic with SOAP
as a 56 kb modem with IIOP. Bandwidth is cheap, but not *that* cheap.
What's more, the CPU cycles burned during marshaling and unmarshaling are
easily 100 times that of IIOP, due to the insane parsing effort it takes
to decode and encode XML. CPU cycles are cheap, but not *that* cheap.
With inherent performance limitations like this, SOAP will be confined to
low-bandwidth applications because it can't possibly scale.
> I like CORBA, but it is for my feeling to strictly connecting
> massively distributed systems.
> Large distributed systems (for example the internet) could not
> be built with CORBA, it is just to rigid.
Really? Is XML any less rigid than IDL? Think carefully before you answer.
The fact is that, if I send you an RPC, you will have to work out
what the message I sent to you means. This involves knowing both the syntax
and the semantics. Proponents of SOAP keep telling people that XML is
so much better when you need to change an interface because, after all,
the messages are "self-describing". Again, think carefully before you accept
this. XML messages are no more self-describing than ASN.1 or IIOP.
The receiver has to know what to expect and how to make sense of it, no
matter in what syntax it is encoded.
People who believe that XML for RPC is somehow better because, after all,
the receiver can easily ignore those tags it doesn't understand, are
deluding themselves. Would you sign a contract with me after you understood
only have of what I just said to you? I think not...
Similarly, people who think that, because XML is human-readable, it is
somehow better than a binary encoding are deluding themselves too. When
was the last time you had a desire to read, for example, the traffic
on your LAN like you would read newspaper? And, besides, XML of reasonable
complexity was no more readable than binary, last time I looked...
> Another drawback of CORBA is that it tries to hide the low level
> connection (for example TCP/IP), but you can't ignore it.
> When programming distributed, you always need to be aware
> that the objects are distributed, and failures of components
> are common and 'allowed'.
True. But it's not immediately clear to me that making the details of the
underlying network visible would improve on things here. For example,
many temporary network problems can be caught and handled transparently
by the CORBA run time such that they are never seen by the application
code. As far as I am concerned, that's a good thing. Making all the low-level
networking details visible wouldn't improve the situation. You'd just
end up exposing all the grot that we have worked so hard to hide. And,
arguments about CORBA's complexity notwithstanding, I think it is clear
that CORBA makes it easier to write distributed systems than any other
technology before it. And all those technologies, CORBA included, provided
improvements by progressively hiding more details of the underlying
network.
Marcel Ruff
> That's ~360 bytes to invoke an RPC with a single in parameter of three bytes.
> ...
> ...
> That's around 280 bytes for a single floating-point return value.
>
> With IIOP, the same thing takes about 60 bytes for the request and 28 bytes
> for the reply.
Both would fit easy into one TCP/IP packet of ~1500 bytes.
> If you have structs with more members (something that's very common),
> the bandwidth difference can easily exceed a factor of 100. This means
> that a 5 Mb dedicated leased line will move about as much traffic with SOAP
> as a 56 kb modem with IIOP. Bandwidth is cheap, but not *that* cheap.
>
> What's more, the CPU cycles burned during marshaling and unmarshaling are
> easily 100 times that of IIOP, due to the insane parsing effort it takes
> to decode and encode XML. CPU cycles are cheap, but not *that* cheap.
There is a lot of truth in your words here.
> Really? Is XML any less rigid than IDL? Think carefully before you answer.
> The fact is that, if I send you an RPC, you will have to work out
> what the message I sent to you means. This involves knowing both the syntax
> and the semantics. Proponents of SOAP keep telling people that XML is
> so much better when you need to change an interface because, after all,
> the messages are "self-describing". Again, think carefully before you accept
> this. XML messages are no more self-describing than ASN.1 or IIOP.
> The receiver has to know what to expect and how to make sense of it, no
> matter in what syntax it is encoded.
If i send my grandma a recipe for strawberry cake encoded in xml
i believe she could figure out how to bake it, i wouldn't dare
to eat the IIOP strawberry cake.
>
> People who believe that XML for RPC is somehow better because, after all,
> the receiver can easily ignore those tags it doesn't understand, are
> deluding themselves. Would you sign a contract with me after you understood
> only have of what I just said to you? I think not...
The HTML/HTTP contract is very loose, but it revolutionized the world,
in only a few years - because it is simple.
I know, different use cases need different solutions, and CORBA
does a good job in many areas.
>
> Similarly, people who think that, because XML is human-readable, it is
> somehow better than a binary encoding are deluding themselves too. When
> was the last time you had a desire to read, for example, the traffic
> on your LAN like you would read newspaper? And, besides, XML of reasonable
> complexity was no more readable than binary, last time I looked...
>
> > Another drawback of CORBA is that it tries to hide the low level
> > connection ...
>
> True. But it's not immediately clear to me that making the details of the
> underlying network visible would improve on things here. For example,
> many temporary network problems can be caught and handled transparently
> by the CORBA run time such that they are never seen by the application
> code. As far as I am concerned, that's a good thing. Making all the low-level
> networking details visible wouldn't improve the situation. You'd just
> end up exposing all the grot that we have worked so hard to hide. And,
> arguments about CORBA's complexity notwithstanding, I think it is clear
> that CORBA makes it easier to write distributed systems than any other
> technology before it. And all those technologies, CORBA included, provided
> improvements by progressively hiding more details of the underlying
> network.
To get started with CORBA you need to have a lot of helper code.
For instance getting the EOF of a lost socket connection is a
nice information, but not available with CORBA.
So we need to declare a ping() method in our IDL and implement all
the code in the client/server and so forth.
You can do everything with C as well, but a technology
suggest you to follow a way, even if it is theoretically
possible to do it different.
I just have finished an EJB project. In my eyes this is
a horrible framework.
If you just implement how the EJB paradigm guides you,
you server will be unusable slow, the project will fail.
So you have to think as much as before, having know how
of distributed systems, implementing
workarounds for these architecture drawbacks of J2EE.
just some personal feelings,
Michi Henning
> > The receiver has to know what to expect and how to make sense of it, no
> > matter in what syntax it is encoded.
>
> If i send my grandma a recipe for strawberry cake encoded in xml
> i believe she could figure out how to bake it, i wouldn't dare
> to eat the IIOP strawberry cake.
Right. But that's because your grandma is human and can "intuitively" make
sense of the tags. However, to the machine, whether the tag is
"<invoice>" or "42" is exactly the same thing -- both are equally
incomprehensible to a computer unless there is a pre-established agreement
as to their meaning. For example, if I send an XML RPC with the tag
<Michi's favourite little joke here>, your application is unlikely to know
what it means (whereas you would have no problem yourself).
So, can you afford to ignore the tag? I think not. That's because it might
equally well have read "<Penalties for failing to reply to this message
within 10 seconds>", or have contained some other nasty "small print".
> > People who believe that XML for RPC is somehow better because, after all,
> > the receiver can easily ignore those tags it doesn't understand, are
> > deluding themselves. Would you sign a contract with me after you understood
> > only have of what I just said to you? I think not...
>
> The HTML/HTTP contract is very loose, but it revolutionized the world,
> in only a few years - because it is simple.
Yes, because people did only simple things with it. Try to do complex
things, and the contract won't be simple anymore either, whether it's in
IIOP or XML.
> You can do everything with C as well, but a technology
> suggest you to follow a way, even if it is theoretically
> possible to do it different.
> I just have finished an EJB project. In my eyes this is
> a horrible framework.
> If you just implement how the EJB paradigm guides you,
> you server will be unusable slow, the project will fail.
> So you have to think as much as before, having know how
> of distributed systems, implementing
> workarounds for these architecture drawbacks of J2EE.
>
> just some personal feelings,
Sure, I understand the sentiment. What you are really getting at here is
that you can't afford to forget about the presence of a network, whether
you use CORBA, DCOM, EJB, DCE, or whatever. Your application must still be
designed to take account of latency and bandwidth limitations, etc. But
with a high-level platform like CORBA, you can build distributed applications
without being a guru on sockets programming, flow control, byte alignment,
and about a thousand other things like it. As far as I am concerned, that's
definitely an improvement over doing things the hard way (like we used to
do). Of course, CORBA can't do anyone's thinking for them ;-) Or, to put
this differently, you can write a terrible system with any platform. CORBA
is no exception. (A good programmer can write FORTRAN in any language ;-)
Martin v.Loewis
Michi Henning <mi...@ooc.com.au> wrote:
>> The HTML/HTTP contract is very loose, but it revolutionized the world,
>> in only a few years - because it is simple.
>
>Yes, because people did only simple things with it. Try to do complex
>things, and the contract won't be simple anymore either, whether it's in
>IIOP or XML.
Or, more specifically, for the same reason why the grandma could read
the recipe: HTML was made for humans talking to humans. Later, machines
would talk to humans, with all those generated pages, but humans
can make sense out of a page even if it is stupidly overloaded with
banner ads.
I'm not aware of any large-scale success of HTML/HTTP being used for
machines talking to machines - those of us that have tried to automatically
extract data from some automatically generated page know why that
is not the most elegant protocol possible.
So I fully agree with your analysis that "XML is self-descriptive" is
an urban legend.
Regards,
Martin
Steinar Bang
> What concerns me more than anything else is the horrendous cost of
> using SOAP. The representation is extremely bulky. For many
> messages, the bandwidth required is easily 50-100 times that of
> IIOP. Further, the cost marshaling and unmarshaling these messages
> is very high, on the order of a 100 times the CPU cycles required
> for IIOP.
But even so the marketing hype for SOAP keeps using the term
_lightweight_ in combination with SOAP. And what's worse: people seem
to accept this use of the term. :-/
Marcel Ruff
Ok, i surrender.
thanks for the discussion,
cu
Marcel Ruff
Ahhhhh, i have to add this:
The marketing hype for EJB is even worse.
And what is even more worse: people seem to follow it.
cu,
Timothy Docker
Michi Henning <mi...@ooc.com.au> writes:
> Really? Is XML any less rigid than IDL? Think carefully before you answer.
> The fact is that, if I send you an RPC, you will have to work out
> what the message I sent to you means. This involves knowing both the syntax
> and the semantics. Proponents of SOAP keep telling people that XML is
> so much better when you need to change an interface because, after all,
> the messages are "self-describing". Again, think carefully before you accept
> this. XML messages are no more self-describing than ASN.1 or IIOP.
> The receiver has to know what to expect and how to make sense of it, no
> matter in what syntax it is encoded.
>
> People who believe that XML for RPC is somehow better because, after all,
> the receiver can easily ignore those tags it doesn't understand, are
> deluding themselves. Would you sign a contract with me after you understood
> only have of what I just said to you? I think not...
I see a potential benefit of the extra flexibility XML offers:
eg. I have applications that revolve around a fixed small set of
structures. From time to time additional fields are added to these
structures - for there is always an implied default value for these
new fields.
In CORBA IDL we have implemented this as a union of structures, as we
need pass by value semantics and efficient marshalling. When new
fields are added, we simply add them to the relevant structures in the
idl.
Of course CORBA dictates that when the IDL changes in this way all
interacting clients and servers need to be simultaneously updated. It
would be very convenient if we could permit "default values" in the
protocol, so that we could stage the rollout of clients and servers.
Obviously a XML message receiver is not going to make sense of an
arbitrary message, but potentially XML allows the use of some custom
protocol that specifies how missing or additional fields are to
be treated in a particular application domain.
Tim Docker
Martin v.Loewis
Timothy Docker <ti...@macquarie.com.au> wrote:
>eg. I have applications that revolve around a fixed small set of
>structures. From time to time additional fields are added to these
>structures - for there is always an implied default value for these
>new fields.
>
>In CORBA IDL we have implemented this as a union of structures, as we
>need pass by value semantics and efficient marshalling. When new
>fields are added, we simply add them to the relevant structures in the
>idl.
>
>Of course CORBA dictates that when the IDL changes in this way all
>interacting clients and servers need to be simultaneously updated. It
>would be very convenient if we could permit "default values" in the
>protocol, so that we could stage the rollout of clients and servers.
I agree. However, this is a deficiency of the CORBA type system, not
one of interface typing per-se. For example, in ASN.1, structures
can have OPTIONAL fields and fields with a DEFAULT value.
In older CORBA versions, there was no equivalent of those. Since CORBA 2.3,
a value boxes can be used to represent optional fields: if the value is
null, it is not present.
Fields with default values cannot be declared in IDL, although it is
possible to define a getter operation on the valuetype that will provide
the default value should the transmitted value have been left out.
>Obviously a XML message receiver is not going to make sense of an
>arbitrary message, but potentially XML allows the use of some custom
>protocol that specifies how missing or additional fields are to
>be treated in a particular application domain.
There is another aspect to this, which is extensibility. I.e. later
versions of the protocol may add fields, which aren't even known to
be optional to the receiver. In ASN.1, there is the ... extension marker,
indicating that future versions may add additional fields.
Again, with CORBA, this is solved by means of valuetypes: The first
version specifies some valuetype as the parameter type. Later versions
will define derived truncatable valuetypes, so that recipients which don't
know about the extension will know that they can safely drop the additional
fields.
Regards,
Martin
Timothy Docker
loe...@cs.tu-berlin.de (Martin v.Loewis) writes:
> Timothy Docker <ti...@macquarie.com.au> wrote:
>
> >Of course CORBA dictates that when the IDL changes in this way all
> >interacting clients and servers need to be simultaneously updated. It
> >would be very convenient if we could permit "default values" in the
> >protocol, so that we could stage the rollout of clients and servers.
>
> I agree. However, this is a deficiency of the CORBA type system, not
> one of interface typing per-se. For example, in ASN.1, structures
> can have OPTIONAL fields and fields with a DEFAULT value.
>
> In older CORBA versions, there was no equivalent of those. Since CORBA 2.3,
> a value boxes can be used to represent optional fields: if the value is
> null, it is not present.
Even given valuetypes, I don't think this solves the issue. I cannot
add a new value box to an existing value and have it compatible it
some sense with the previous version, can I?
I can add an optional value to a plain old structure (a bounded
sequence of length <= 1, or a union discriminated on a boolean), but I
can't interoperate between the original and new version. I can see why
corba doesn't permit this in general, but it's frustrating that I
can't implement some sort of conversion operations of my own between
old and new versions.
The recommended approach of versioning through inheritance doesn't
work with non-interface values.
> Fields with default values cannot be declared in IDL, although it is
> possible to define a getter operation on the valuetype that will provide
> the default value should the transmitted value have been left out.
It sounds like valuetypes could make life somewhat easier when they
are universally available, but I understood that operations on
valuetypes were generally a bad idea.
> >Obviously a XML message receiver is not going to make sense of an
> >arbitrary message, but potentially XML allows the use of some custom
> >protocol that specifies how missing or additional fields are to
> >be treated in a particular application domain.
>
> There is another aspect to this, which is extensibility. I.e. later
> versions of the protocol may add fields, which aren't even known to
> be optional to the receiver. In ASN.1, there is the ... extension marker,
> indicating that future versions may add additional fields.
Ah... this is what I was getting at in the first place.
> Again, with CORBA, this is solved by means of valuetypes: The first
> version specifies some valuetype as the parameter type. Later versions
> will define derived truncatable valuetypes, so that recipients which don't
> know about the extension will know that they can safely drop the additional
> fields.
Again assuming that valuetypes are an alternative, and you are happy
with the resulting inheritance hierarchy reflecting the versioning
history of the idl.
Cheers,
Tim
Frank Pilhofer
>
> Even given valuetypes, I don't think this solves the issue. I cannot
> add a new value box to an existing value and have it compatible it
> some sense with the previous version, can I?
>
Yes. That's what truncatable valuetypes are for.
valuetype old {
public short foo;
};
valuetype new : truncatable old {
public short bar;
};
You can then pass an `new' wherever an `old' is expected.
>
> The recommended approach of versioning through inheritance doesn't
> work with non-interface values.
>
It works with valuetypes.
>
> It sounds like valuetypes could make life somewhat easier when they
> are universally available, but I understood that operations on
> valuetypes were generally a bad idea.
>
The problem is that operations need an implementation, which needs to
be present. You might be able to download a valuetype in Java, but hit
serious problems in any other language. Considering that valuetypes are
straight out of Java, this was probably intended ...
Another more or less unresolved non-issue is memory management of circular
valuetypes.
Frank
--
Frank Pilhofer ........................................... f...@fpx.de
Some minds are like concrete ... all mixed up and permanently set.
- Alfred E. Neuman
Josef Stadelmann
strings. Sending a sequence can contain elements very similar to XML's. It
is then up to the receiver to take one out and act acordingly or just leave
it. CORBA is no hindering on that; even it's not what CORBA is for. If your
receiver gets by a retreiver routine for a named value, and does not find
the named value pair in the sequence, it can then deliver an empty string, a
default value.
That way we have reached CL / SV developer independenc in our CORBA world.
i.e. A server adds a named-value-pair into the sequence but the client does
not ask for in the reply. Or the client sends a named-value-pair in a
sequence but the server does not ask for. Or the client does not send it but
the server wants to have it; then the server is given a default.
If that does not match CL / SV developers then they have to setup for an
expensive meeting to discusse who is behind its project target.
Sepp
"Marcel Ruff" <ru...@swand.lake.de> wrote in message
news:3A5E43E3...@swand.lake.de...
Timothy Docker
> This can be fixed with a sequence of structure of name value pairs of
> strings. Sending a sequence can contain elements very similar to XML's. It
> is then up to the receiver to take one out and act acordingly or just leave
> it. CORBA is no hindering on that; even it's not what CORBA is for. If your
> receiver gets by a retreiver routine for a named value, and does not find
> the named value pair in the sequence, it can then deliver an empty string, a
> default value.
Sure, but as soon as you do this you lose many benefits of the normal
CORBA approach (static typing, marshalling efficiency). This
effectively reduces CORBA to a network protocol for transferring string
data (sounds like XML/SOAP all over again).
Tim