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
Michi Henning
> 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).
All of this is really about strict compile-time typing versus loose
run-time typing. Either can be appropriate, depending on what you do.
The trade-offs are well known: strict compile-time typing is less flexible
but much safer because it eliminates a whole class of errors at compile
time; loose run-time typing gives you better extensibility, at the cost
of potentially having latent bugs that may not be found until after
deployement (because you find the bug only if you happen to have
test case that tickles it).
The other down-side of loose typing is that the application code gets
a lot more complex and has to deal with more error conditions. (For a sterling
example, compare the static invocation interface with the DII.)
The fundamental problem I have is that it is not feasible to turn a loose
type system into statically safe one at the application level, whereas
it is trivial to turn a statically safe type system into a dynamic one
(for example, by using sequences of anys, value types, unions, or string
encodings).
I also fail to see why suddenly, the on-the-wire representation of the
data should be considered so important. The application code is many
layers removed from the marshaled representation of data, using generated
code to encode and decode that data (whether you use SOAP or IIOP, or anything
else). So, by the time I'm up in the application layer, where I want
to deal with application-level concerns, why would I care how the data
is marshaled?
Marcel Ruff
Type safety is null with the key/value approach,
but sometimes this solves the needs, and thus
is the best way in an XML unaware world :-)
But simple key/values are not at all
as powerful as XML, allowing hierarchical
information, guaranteed sequence order of children
and so forth. This is why i like xml so much.
With xml it is often possible to model
the reality in a simple way.
With XSLT, you can query this data or transform it
to whatever.
Sending xml messages with xmlBlaster for example
allows to query or filter the messages with XPath
(which is part of XSLT).
Having a key/value approach, you usually haven't
got a standardized or powerful way to query.
Timothy Docker
Michi Henning <mi...@ooc.com.au> writes:
> I also fail to see why suddenly, the on-the-wire representation of the
> data should be considered so important. The application code is many
> layers removed from the marshaled representation of data, using generated
> code to encode and decode that data (whether you use SOAP or IIOP, or anything
> else). So, by the time I'm up in the application layer, where I want
> to deal with application-level concerns, why would I care how the data
> is marshaled?
I guess you mean other than efficiency issues!
My current frustruction with pre-valuetype corba is that there isn't a
way of designing some sort of exensible values without using anys (or
strings.. uggh), and these have sufficent overhead that they are
unworkable for us.
Tim
Stephen Crawley
> (A good programmer can write FORTRAN in any language ;-)
The canonical version of this quote is:
"A Real Programmer can write FORTRAN in any language"
... from "Real Programmers don't eat Quiche".
Only a Real Programmer would confuse a Real Programmer with a good
programmer :-)
-- Steve
Michi Henning
Hmmm... I'm not quite sure what to make of that ;-)
At any rate: oops, I stand corrected :-)
Owen Rees
<dcwvbuw...@soluble.dstc.edu.au>:
I think the original is in "Real Programmers Don't Use PASCAL" which can be
found at:
<http://www.edfac.usyd.edu.au/staff/souters/Humour/Real.Programmer.Stories.
html>
This includes both:
"Real Programmers use FORTRAN."
"Besides, the determined Real Programmer can write FORTRAN programs in any
language."
There are also a lot of variants of the Real Programmer stories (some at
the site mentioned above) that say something like:
"Real Programmers don't write in FORTRAN. FORTRAN is for pipe stress freaks
and crystallography weenies."
In the context of SOAP,CORBA etc. I think the "application programs" remark
would be adapted something like this:
"Real Programmers don't use middleware, they program down to the bare
metal. Middleware is for feebs who can't do systems programming."
Unfortunately, we still see people trying to be Real Programmers and
extolling the virtues of programming directly to the socket interface, and
inventing their own protocols and data formats.
--
Owen Rees, HP Laboratories, Bristol
Any statements in this message are personal opinions
and do not represent the views of HP.
Michi Henning
> Michi Henning <mi...@ooc.com.au> writes:
>
> > I also fail to see why suddenly, the on-the-wire representation of the
> > data should be considered so important. The application code is many
> > layers removed from the marshaled representation of data, using generated
> > code to encode and decode that data (whether you use SOAP or IIOP, or anything
> > else). So, by the time I'm up in the application layer, where I want
> > to deal with application-level concerns, why would I care how the data
> > is marshaled?
>
> I guess you mean other than efficiency issues!
Yes! :-)
> My current frustruction with pre-valuetype corba is that there isn't a
> way of designing some sort of exensible values without using anys (or
> strings.. uggh), and these have sufficent overhead that they are
> unworkable for us.
Hmmm... But SOAP would be? Somehow, that doesn't ring true -- if you
can afford SOAP, you can afford anys...
Martin v.Loewis
> 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.
I don't think the problems are serious: you just have to have an
implementation in advance, since you can't expect the downloading to
work. Having implementations of classes locally available is known
by the name "class library" in many languages; there is nothing
inherently troubling in that concept.
Specifically, I don't see it as a problem that some people view
valuetype methods as violating some abstract principles :-)
> Another more or less unresolved non-issue is memory management of circular
>valuetypes.
It seems to me that it is a rather less than more unresolved non-issue.
Ok, so you produce garbage in C++ if you are not careful. To most C++
programmers, this is not surprising news.
Regards,
Martin
Diego Sevilla Ruiz (dsevilla@um.es)
I can't resist one more, that I don't know if was told by Larry Wall
(perl's inventor) or by Linus Torvalds:
"Real programmers can write assembly in any language"
... perhaps even earlier that any other ;-)
Regards.
diego.
Owen Rees wrote:
--
Diego Sevilla Ruiz -- http://ditec.um.es/~dsevilla/ -- dsev...@um.es
Departamento de Ingeniería y Tecnología de Computadores
Facultad de Informática. Universidad de Murcia
Campus de Espinardo - 30080 Murcia (SPAIN). - Tel. +34-968-367658
PGP: http://pgp.rediris.es:11371/pks/lookup?op=get&search=0xC9B964B7
\huge d\em\kern-.36em\lower-.2ex\hbox{\small sevilla}\kern...@um.es
perl -e'$_="\x4\@FLe\x2&B";for(/../g){print unpack("b*",$_),"\n"}'|tr 01 " #"
Philip Lijnzaad
Martin> In article <slrn968m...@rose.fpx.de>, Frank Pilhofer <f...@fpx.de> wrote:
>> 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.
Martin> I don't think the problems are serious: you just have to have an
Martin> implementation in advance,
The problem is that in all other client/server technologies, the server
publishes its interface, hopefully sticks to it, and clients can use the
promised functionality in whichever way it pleases them. With methods in
valuetypes however, the server suddenly tells clients what to do: "you have
to implement some_method(some_args)". And if this isn't bad enough, the
server never even uses this some_method(), because it's local. This confused
design (to be polite) creates a strange, non-existing relationship between
client and server, with few obvious benefits.
Philip
--
Vegetarians eat vegetables. Beware the humanitarians (anon.)
-----------------------------------------------------------------------------
Philip Lijnzaad, lijn...@ebi.ac.uk \ European Bioinformatics Institute,rm A2-08
+44 (0)1223 49 4639 / Wellcome Trust Genome Campus, Hinxton
+44 (0)1223 49 4468 (fax) \ Cambridgeshire CB10 1SD, GREAT BRITAIN
PGP fingerprint: E1 03 BF 80 94 61 B6 FC 50 3D 1F 64 40 75 FB 53
Michi Henning
> Martin> I don't think the problems are serious: you just have to have an
> Martin> implementation in advance,
>
> The problem is that in all other client/server technologies, the server
> publishes its interface, hopefully sticks to it, and clients can use the
> promised functionality in whichever way it pleases them. With methods in
> valuetypes however, the server suddenly tells clients what to do: "you have
> to implement some_method(some_args)". And if this isn't bad enough, the
> server never even uses this some_method(), because it's local. This confused
> design (to be polite) creates a strange, non-existing relationship between
> client and server, with few obvious benefits.
For CORBA, the idea of methods on value types doesn't fit very well into
the overall architecture. The cornerstone of CORBA is interoperability
in heterogeneous environments. In order to achieve that, CORBA has a very
strict separation of interface and implementation. With that, in order
to communicate with a server, all you need to know is the IDL interface
(plus an initial object reference to an object with that interface).
That's it, and with that information, any client can to talk to any server,
no matter how the server is implemented, what OS it uses, what language
it was written in, where the server is, etc, etc.
Methods on value types break this quite badly. That's because, in order
to use a value type with methods, you no longer just need the IDL and an
object reference, you also need an implementation of those methods
in your local address space. However, the platform provides no way to
know where to get those methods from and, worse, the majority of programming
languages don't support the kind of on-the-fly downloading of code that
Java supports.
So, suddenly, we have completely broken the implementation transparency
of the platform. For the vendor of a service that uses value types with
methods, that spells trouble big time. In order to allow arbitrary
clients to communicate with the service, the vendor now suddenly has
to provide an implementation of the methods in the value type to each
supported client. At least the following factors affect how such an
implementation has to be created and supplied:
- operating system
- operating system version
- programming language
- compiler vendor
- compiler version
- client-side ORB
- client-side ORB version
- other third-party run-time libraries that may be used in the
client and may interact with the remainder of the client code
in some way (e.g. for threading models)
The vendor is now confronted with the need to potentially provide libraries
for all possible combinations of these factors. It's easy to see that
this number can easily be in the tens or hundreds.
In the past, I was involved with a CORBA project that was meant to be
multi-platform and multi-ORB. At some point during the project, someone
decided that all the CORBA APIs needed to be augmented with client-side
helper classes, both to make it easier for non-CORBA literate programmers
to use the platform, and to implement some client-side caching functionality.
This worked well for a time, and the resulting API was indeed an improvement
in many ways over the naked CORBA IDL interfaces.
The truth struck home during a port to NT, when people suddenly realized
that all the client-side helper code now had to be ported and shipped
separately. The truth struck home again when the project was forced to
support a second C++ compiler for UNIX and a different version of the
same C++ compiler for NT; suddenly, the client-side helper classes had to
be modified again. At that point, there were four versions of the libraries.
The next step was that the ORB had to be upgraded to a newer version because
the old one couldn't do certain things, but the old ORB still had to be
supported for deployed code. Now there were eight versions of the libraries.
Finally, when the requirement came up to support an ORB from a different
vendor as well, the decision was made to (at great cost) remove the
client-side helper API. Of course, that meant that all the deployed customer
code had to change, which wasn't appreciated by customers.
I'm quoting this example to demonstrate that these problems are real, and
that it is very easy to underestimate their significance at first. Methods
on value types are subject to exactly the same problems and should therefore
be approached with great caution. Basically, they make sense only if
you can tightly control both the client- and the server-side development
and deployment environment (but even then, the versioning issues will
still plague you). On top of that, you have to be absolutely sure that,
some time later, you won't suddenly be asked to support another client-side
language, OS, compiler version, or similar, because, as a rule, each such
request will instantly double the number of libraries you have to support.
Looking at the history of value types, they started out as something quite
sensible (namely, extensible structs) and ended up being a misguided attempt
at making CORBA more like JAVA RMI, no matter the cost to the integrity
of the CORBA architecture...
Jonathan Biggar
> For CORBA, the idea of methods on value types doesn't fit very well into
> the overall architecture. The cornerstone of CORBA is interoperability
> in heterogeneous environments. In order to achieve that, CORBA has a very
> strict separation of interface and implementation. With that, in order
> to communicate with a server, all you need to know is the IDL interface
> (plus an initial object reference to an object with that interface).
> That's it, and with that information, any client can to talk to any server,
> no matter how the server is implemented, what OS it uses, what language
> it was written in, where the server is, etc, etc.
>
> Methods on value types break this quite badly. That's because, in order
> to use a value type with methods, you no longer just need the IDL and an
> object reference, you also need an implementation of those methods
> in your local address space. However, the platform provides no way to
> know where to get those methods from and, worse, the majority of programming
> languages don't support the kind of on-the-fly downloading of code that
> Java supports.
I don't buy this argument. Let's say that we had CORBA valuetypes with
no methods. Client and server applications would still have to write
libraries of methods that operate on the valuetype data, since the data
without any code that understands it is pretty much useless. In Java,
we get a nice boost (ignoring the security issues) that the
implementation can possibly be imported into code that didn't know the
implementation a priori.
Valuetype methods act as documentation of the types of operations that
the IDL designer expect the client and server to perform on the
valuetype. There's no magical solution to the requirement to provide
implementation for these operations, but the documentatary fact that
they are specified in the IDL is still useful. Even better would be
formal notation for behavior, but we can't have everything, can we? :)
--
Jon Biggar
Floorboard Software
j...@floorboard.com
j...@biggar.org
Michi Henning
> > Methods on value types break this quite badly. That's because, in order
> > to use a value type with methods, you no longer just need the IDL and an
> > object reference, you also need an implementation of those methods
> > in your local address space. However, the platform provides no way to
> > know where to get those methods from and, worse, the majority of programming
> > languages don't support the kind of on-the-fly downloading of code that
> > Java supports.
>
> I don't buy this argument. Let's say that we had CORBA valuetypes with
> no methods.
What you are talking about then are extensible structs, where I can put
new data members into the derived part of the struct, yes?
> Client and server applications would still have to write
> libraries of methods that operate on the valuetype data, since the data
> without any code that understands it is pretty much useless.
Sure. But there would be no need to have any vendor-supplied library because
the IDL data types are well known anyway. (Just as I can deal with any
kind of data with non-value types once I've seen the IDL.)
My argument is that, without methods on value types, IDL would still be
the *only* contract between client and server, whereas value types with
methods add the requirement for the client-side code to be there, meaning
that the IDL alone isn't sufficient anymore for the client to use the data
delivered by the server (or vice-versa).
> In Java,
> we get a nice boost (ignoring the security issues) that the
> implementation can possibly be imported into code that didn't know the
> implementation a priori.
Yes, that's undoubtedly very nice. But it doesn't fit very well with
the heterogeneity goals of CORBA.
> Valuetype methods act as documentation of the types of operations that
> the IDL designer expect the client and server to perform on the
> valuetype.
Sure. That's just encapsulation at work, and it's a good thing. I'm not
against value types per se, just as I am not against Java or RMI. All I'm
saying is that value types with methods make for an uneasy fit with the
remainder of CORBA.
> There's no magical solution to the requirement to provide
> implementation for these operations, but the documentatary fact that
> they are specified in the IDL is still useful. Even better would be
> formal notation for behavior, but we can't have everything, can we? :)
C++ is a formal notion for behavior, as is Java. It's just that I can't
squirt C++ implementations around as easily as Java implementations. Having
a formal notion of behavior would end up defining simply another programming
language, given that this formal notion would have to be executable in
order to get around the problems I mentioned.
Frank Pilhofer
>
> > Another more or less unresolved non-issue is memory management of circular
> >valuetypes.
>
> It seems to me that it is a rather less than more unresolved non-issue.
> Ok, so you produce garbage in C++ if you are not careful. To most C++
> programmers, this is not surprising news.
>
The problem is that careful behavior is not yet defined here.
In previous discussion, no agreement was reached whether the ORB-provided
reference couting mix-in classes correctly handle circular valuetypes. Since
this issue is not mentioned in the specification, carefully-written code
will leak.
Frank
--
Frank Pilhofer ........................................... f...@fpx.de
Most people don't act stupid, it's the real thing! - A. E. Neuman
Jonathan Biggar
> > I don't buy this argument. Let's say that we had CORBA valuetypes with
> > no methods.
>
> What you are talking about then are extensible structs, where I can put
> new data members into the derived part of the struct, yes?
Yup.
> > Client and server applications would still have to write
> > libraries of methods that operate on the valuetype data, since the data
> > without any code that understands it is pretty much useless.
>
> Sure. But there would be no need to have any vendor-supplied library because
> the IDL data types are well known anyway. (Just as I can deal with any
> kind of data with non-value types once I've seen the IDL.)
>
> My argument is that, without methods on value types, IDL would still be
> the *only* contract between client and server, whereas value types with
> methods add the requirement for the client-side code to be there, meaning
> that the IDL alone isn't sufficient anymore for the client to use the data
> delivered by the server (or vice-versa).
Um, how does a strongly-typed language like C++ access the additional
members without a custom class definition? If you answer "use DynAny"
then you've lost all of the performance benefit over just using Any in
the first place.
Ultimately it's not a CORBA or IDL issue at all, it's a problem with
trying to wedge dynamic-typing into languages that don't have that
capability built-in.
Again, I submit that if you have a well-bounded set of valuetypes,
providing the code to implement the methods defined for those valuetypes
is no more of a deployment problem than providing code that understands
the semantics of a well-bounded set of CORBA structs that represent the
same data. The problems you attribute to valuetypes exist anyway
without them.
In the future, I expect C++ ORB implementations to provide the ability
to dynamically load class libraries for valuetype methods as a quality
of implementation feature. Even though the deployment of those
libraries won't be automatic like downloading Java code on the fly (and
I'm deeply suspicious of ever allowing that, even in Java, due to the
security implications), it's still a very worthwhile capability to be
able to extend an application with new valuetype code simply by
administratively configuring a new dynamic library into the ORB
environment.
> > In Java,
> > we get a nice boost (ignoring the security issues) that the
> > implementation can possibly be imported into code that didn't know the
> > implementation a priori.
>
> Yes, that's undoubtedly very nice. But it doesn't fit very well with
> the heterogeneity goals of CORBA.
Yes, but even though I'm not a Java believer, piggybacking on the hype
and tying Java to CORBA is a good thing.
> > Valuetype methods act as documentation of the types of operations that
> > the IDL designer expect the client and server to perform on the
> > valuetype.
>
> Sure. That's just encapsulation at work, and it's a good thing. I'm not
> against value types per se, just as I am not against Java or RMI. All I'm
> saying is that value types with methods make for an uneasy fit with the
> remainder of CORBA.
That last statement is true, from a particular point of view. But I
think it isn't realistic to characterize IDL as the complete contract
between the client and server, for exactly the same reasons that you
deny that the "self describing" nature of XML as used in SOAP provides
any real benefit to machine-machine interactions.
The semantics and behavior associated with the IDL specification become
an implicit unwritten part of the contract. Valuetype methods make at
least a small part of the semantics and behavior explicit. That is
still a worthwhile improvement.
Jonathan Biggar
>
> Martin v.Loewis <loe...@cs.tu-berlin.de> wrote:
> >
> > > Another more or less unresolved non-issue is memory management of circular
> > >valuetypes.
> >
> > It seems to me that it is a rather less than more unresolved non-issue.
> > Ok, so you produce garbage in C++ if you are not careful. To most C++
> > programmers, this is not surprising news.
> >
>
> The problem is that careful behavior is not yet defined here.
>
> In previous discussion, no agreement was reached whether the ORB-provided
> reference couting mix-in classes correctly handle circular valuetypes. Since
> this issue is not mentioned in the specification, carefully-written code
> will leak.
I believe the current specification of valuetypes for C++ forces the
implementation of a garbage collector. There is no application hook for
a server that must return a valuetype graph as an out or return value to
regain control after the ORB is done with the valuetypes and safely
break the circular dependencies in the valuetype graph.
A garbage collector will add overhead. I can envision an implementation
where that overhead is a small amount of memory, and close to zero
runtime overhead as long as circular valuetype graphs are never created
and memory constraints aren't too tight.
Martin v.Loewis
>methods, that spells trouble big time. In order to allow arbitrary
>clients to communicate with the service, the vendor now suddenly has
>to provide an implementation of the methods in the value type to each
>supported client.
Who says that it is the vendor of the service that needs to provide
the implementations?
In general, it probably depends on the application; in many cases,
requiring the client application to implement these operations would work
fine - application developers could chose to *not* implement them, and
then not use them, either.
>Looking at the history of value types, they started out as something quite
>sensible (namely, extensible structs) and ended up being a misguided attempt
>at making CORBA more like JAVA RMI, no matter the cost to the integrity
>of the CORBA architecture...
Is that the history of value types? I thought they started out in response
to the "Objects by Value" RFP... I didn't re-read the requirements of that
RFP, again - but I think it was asking for even more (e.g. how to deal with
the identity of an object that is passed as a value).
Regards,
Martin
Martin v.Loewis
Philip Lijnzaad <lijn...@ebi.ac.uk> wrote:
>The problem is that in all other client/server technologies, the server
>publishes its interface, hopefully sticks to it, and clients can use the
>promised functionality in whichever way it pleases them. With methods in
>valuetypes however, the server suddenly tells clients what to do: "you have
>to implement some_method(some_args)".
It's not the server telling the client, it is the IDL designer
telling both the client and the server. And *all* she requires is that
a certain signature is available, which might be implemented by, say
raise CORBA.NO_IMPLEMENT()
>And if this isn't bad enough, the
>server never even uses this some_method(), because it's local.
Neither does the client see the server's implementation. So what?
>This confused design (to be polite) creates a strange, non-existing
>relationship between client and server, with few obvious benefits.
No, it doesn't. The interface does not require at all that there is
any relationship between the implementations of these operations the
client and the server.
Regards,
Martin
Martin v.Loewis
>the *only* contract between client and server, whereas value types with
>methods add the requirement for the client-side code to be there, meaning
>that the IDL alone isn't sufficient anymore for the client to use the data
>delivered by the server (or vice-versa).
Well, my argument is that with valuetypes, IDL is *still* the only contract
between client and server. It's completely up to the receiver of a value
type (which may be either the client or the server) to come up with an
implementation of the value type, specifically how, or even if, to implement
the operations. In many languages (like C++) registration of a factory
is necessary even if the valuetype has no operations. It is completely
up to the receiver what factory to register.
>Sure. That's just encapsulation at work, and it's a good thing. I'm not
>against value types per se, just as I am not against Java or RMI. All I'm
>saying is that value types with methods make for an uneasy fit with the
>remainder of CORBA.
If you chose to look at it this way, yes. Just by reading the
specification, the uneasy fit does not necessarily follow.
Regards,
Martin
Philip Lijnzaad
Martin> In article <u7r921m...@sol6.ebi.ac.uk>,
Martin> Philip Lijnzaad <lijn...@ebi.ac.uk> wrote:
>> The problem is that in all other client/server technologies, the server
>> publishes its interface, hopefully sticks to it, and clients can use the
>> promised functionality in whichever way it pleases them. With methods in
>> valuetypes however, the server suddenly tells clients what to do: "you have
>> to implement some_method(some_args)".
Martin> it is the IDL designer telling both the client and the server.
The common way of describing and working with client/server programming is
that the provider offers some functionality, and formally publishes and
documents it in the form of an interface; clients then can make use of this
in which ever way they choose. It is pointless to prescribe, in an interface,
that a client should have a local implementation of this or that methods;
it's a completely out of scope, none-of-its-business kind of thing.
Martin> And *all* she requires is that
Martin> a certain signature is available, which might be implemented by, say
Martin> raise CORBA.NO_IMPLEMENT()
I am not arguing that you there are no work-arounds; I'm arguing against
their necessity.
>> This confused design (to be polite) creates a strange, non-existing
>> relationship between client and server, with few obvious benefits.
Martin> No, it doesn't. The interface does not require at all that there is
Martin> any relationship between the implementations of these operations the
Martin> client and the server.
I know, so, again, why does IDL prescribe local methods to a client?
Frank Pilhofer
> Frank Pilhofer wrote:
>
> > In previous discussion, no agreement was reached whether the ORB-provided
> > reference couting mix-in classes correctly handle circular valuetypes. Since
> > this issue is not mentioned in the specification, carefully-written code
> > will leak.
>
> I believe the current specification of valuetypes for C++ forces the
> implementation of a garbage collector. There is no application hook for
> a server that must return a valuetype graph as an out or return value to
> regain control after the ORB is done with the valuetypes and safely
> break the circular dependencies in the valuetype graph.
>
That was essentially the meat of the previous discussion. My strong belief
that a garbage-collector in the ORB is essential was thoroughly challenged,
so until this requirement is written into the specification, I am not going
to believe in true interoperability of valuetypes.
Frank
--
Frank Pilhofer ........................................... f...@fpx.de
Martin v.Loewis
Philip Lijnzaad <lijn...@ebi.ac.uk> wrote:
>Martin> No, it doesn't. The interface does not require at all that there is
>Martin> any relationship between the implementations of these operations the
>Martin> client and the server.
>
>I know, so, again, why does IDL prescribe local methods to a client?
It is not IDL doing so, it is the designer of a specific IDL module.
Why does IDL prescribe the fields of a structure to a client?
Whether it is a useful thing or not certainly depends on your application.
I can see uses for it, e.g. to offer traversal operations in a tree.
Its just more convenient to use and implement when you can write methods,
instead of having traversal separate from the structure. It's called
object orientation.
Regards,
Martin
Philip Lijnzaad
> In article <u7g0ibn...@sol6.ebi.ac.uk>,
> Philip Lijnzaad <lijn...@ebi.ac.uk> wrote:
Martin> No, it doesn't. The interface does not require at all that there is
Martin> any relationship between the implementations of these operations the
Martin> client and the server.
>>
>> I know, so, again, why does IDL prescribe local methods to a client?
> It is not IDL doing so, it is the designer of a specific IDL module.
OK (sigh): why would a designer of a specific IDL module want to prescribe
what a client is supposed to implement?
> Why does IDL prescribe the fields of a structure to a client?
(It is not IDL doing so, it is the designer of a specific IDL module)
Because it doesn't. It does _not_ prescribe the fields of a structure to a
client in any way: it guarantees that these fields of this struct are will be
present for its own use. The client has to do exactly nothing. The IDL
compiler and ORB runtime guarantee that you can make use of structs without
any work, passing them to a server and receiving them back.
> Whether it is a useful thing or not certainly depends on your application.
> I can see uses for it, e.g. to offer traversal operations in a tree.
if your valuetype'd tree looks like
valuetype Node;
valuetype Node {
Node parent;
Node left;
Node right;
string data;
};
then why would you need traversal operations? Or do you mean something like
the following:
valuetype Node {
Node parent;
Node left;
Node right;
string data;
Node getRoot(); // top of tree
};
This essentially says: "you will always need a way to get to the top of the
tree; thou shallt implement it and call it getRoot();". This is simply a bad
separation of concerns.
Traditionally, designers of server functionality describe server behaviour,
not client behaviour. Confusing server and client responsabilities is
considered bad practice in most other fields. With methods on valuetypes,
that has changed.
> Its just more convenient to use and implement when you can write methods,
> instead of having traversal separate from the structure.
What's there to stop a client implementer from extending the local class to
add a more versatile Node goUpNLevels(in how_many)?
Why isn't the client implementer not able to judge wether or not have some
local functionality, and what names and signature to give it ? In other
words, since when does the IDL designer know the local needs and conventions?
Alternatively, what's there to stop a vendor to provide classes
with such convenience extensions for people to use?
Michi Henning
> In article <u7g0ibn...@sol6.ebi.ac.uk>,
> Philip Lijnzaad <lijn...@ebi.ac.uk> wrote:
> >Martin> No, it doesn't. The interface does not require at all that there is
> >Martin> any relationship between the implementations of these operations the
> >Martin> client and the server.
> >
> >I know, so, again, why does IDL prescribe local methods to a client?
>
> It is not IDL doing so, it is the designer of a specific IDL module.
> Why does IDL prescribe the fields of a structure to a client?
I have to side with Philip on this one. The client is free not to use the
IDL, or a specific structure in the IDL. If it does choose to use it, then
the IDL contains the complete description of the data. For a valuetype
with methods, that is not the case, because the client also needs the
code for those methods, but how to get that code and what it does is
not visible anywhere.
> Whether it is a useful thing or not certainly depends on your application.
> I can see uses for it, e.g. to offer traversal operations in a tree.
> Its just more convenient to use and implement when you can write methods,
> instead of having traversal separate from the structure. It's called
> object orientation.
No, that's *not* object orientation, because it is not encapsulated. The whole
point of OO is that an object encapsulates both code and data. But, for
value types with methods, that's not the case. The code is encapsulated
nowhere and in fact, the definition of the value type is provided by the
server, but the code is expected to be on the client. That's not OO.
How would you feel if you had a C++ library that returns a C++ object of
some kind and then, when you call a method on that object, you get a failure
unless you happen to have linked something else in a different library, which
may have to be obtained from a third party?