Connections
ZeroC’s Newsletter for the Ice community
Page 1 Issue 5, August 2005
Connections
ZeroC’s Newsletter for the Ice Community
Issue Number 5, August 2005
Contents
Introduction to IcePack ................................................... 2
Ice-E: A Preview ...........................................................
10
Avoiding Deadlocks, Part II .........................................
11
FAQ Corner ..................................................................
19
What is RPC?
My last editorial caused quite a
lively discussion about SOAP’s
performance. I recommend that you
read Jim Webber’s response as well
as my reply and make up your own
mind about this issue. In any case,
I’d like to thank the participants for
their feedback.
The discussion about SOAP performance brought up an unrelated
but very interesting topic, namely the nature of RPC (remote proce-
dure call) and how SOAP compares to CORBA or Ice with respect
to the use of RPC.
Michi believes that every request/response system, including
SOAP, is RPC. Wikipedia seems to agree with him. Others disagree,
believing instead that something is RPC only if, at the API level, the
request/response has the “look and feel” of a local procedure call.
Since SOAP can be used with other request/response styles, such
as using separate message queues for requests and responses, they
claim that SOAP is not RPC.
I’m not interested in debating the definition of RPC. However,
if SOAP is not RPC, then neither are Ice and CORBA. Both Ice
and CORBA offer many different invocation and dispatch styles,
including asynchronous method invocation (where separate threads
or callbacks handle responses), asynchronous method dispatch (to
decouple sending the response from receiving the request on the
server side), time-independent invocations, invocations using mes-
sage and event services, and so on. The point is, no matter how you
define RPC, SOAP offers nothing that Ice or CORBA do not offer
as well.
Quite independent from invocation style though, the fact is
that all distributed systems must deal with issues such as latency,
concurrency, network reliability, and error recovery. No middleware
can make these problems go away, regardless of whether you use
SOAP, Ice, CORBA, or plain sockets.
However, what kind of solutions you can apply to solve these
problems heavily depends on the middleware you use. What it
eventually comes down to is what tools your middleware provides
for interface design, how it allows you to distribute interface imple-
mentations over physical servers and at what granularity, whether
it supports both static and dynamic typing, and how much of the
type checking it does for you as opposed to making your application
code responsible for it.
There are many political arguments for SOAP, and it’s hard
to win these. But when it comes to technical arguments, SOAP
is mostly smoke and mirrors. At ZeroC, we are admittedly very
technical and we leave the big view about how technology markets
work to others. Instead, we concentrate on providing solutions that
solve real problems for real customers. It’s as simple as that.
Marc Laukien
President
ZeroC, Inc.
Issue Features
Introduction to IcePack
In this article, Matthew Newhook and Benoit Foucher show you
how you can use IcePack to automate the chat application so that
servers are started on demand and in the correct order, as well as
how to automate the deployment of the application for different
environments.
Ice-E: A Preview
Later this year, ZeroC will release Ice-E, a version of Ice for
embedded C++ and Java applications. This article provides a
brief overview of Ice-E.
Avoiding Deadlocks, Part II
In this second part of his two-part article, Bernard Normier
shows you how you can save yourself having to debug deadlock
situations by making sure they cannot arise in the first place.
剩余19页未读，继续阅读
资源评论
