SOAP Performance - Really so slow ?

[Aquila Deus]

Aren't most remoting protocol networkable?

Yes but XMLHttpRequest works with HTTP only....

 

[Panagiotis Issaris]

Hi,

There's nothing wrong with RMI / Remoting / CORBA / whatever. They're
great technologies. However, they just don't have the vast market
penetration that Web Services is shaping up to have. As I said, if

I depends on what you mean with market penetration. As the standard Java
classlibraries have been including a CORBA implementation for years, I
think CORBA has been around and available for a long time. Before that,
Netscape included the Visibroker ORB in Navigator.

So, frankly, I do not think it is market penetration that causes people to
choose SOAP over CORBA. Personally, I think it is marketing, hype and
buzzwords working.

If SOAP had not been XML based, but a plain humanly
readable (ASCII or UTF-8) protocol, it wouldn't have been as popular as it
is now. And from most people, that's exactly what they claim is so great
about SOAP and XML-RPC. And actually, I don't really by into that argument
either, as a nice protocol analyzer (such as Ethereal) shows this info in
a much more human friendly form than looking at plain SOAP data.

The only nice thing about it imho, is that it works out of the box on
HTTP, making it easier to deploy then CORBA based applications.

But, in fact the reasoning behind this seems kind of strange too:
Sysadmins block everything but port 80, 'cause hey, there's "only
HTML/static content" passing through that port. And don't ask to open any
other ports to put a custom server online, because that's a security
hazard. But now, people hook up whatever servers they want behind a
dispatcher at port 80, and now people seem to believe there's no hazard
involved...

interoperability between heterogeneous platforms is high on my list of
requirements, I probably won't be considering Java RMI as my protocol.

No, surely not: It sound like the prototype problem for a CORBA based
solution.

If I'm in a closed, all-Java shop, then that changes everything. Use
the right tool for the right job... and there are many jobs for which
SOAP is the right tool.

With friendly regards,
Takis

 

[Panagiotis Issaris]

Hi,

I think, that everybody will have the same experience, because using SOAP
means that you will get more data then in binary mode. And if data size is
larger then network transfer of this data will be slow...

However, the flavor of SOAP is interoperability with different systems (
e.g. you can have web service written in Java and clients on .NET or vice
versa ).
If interoprability is not your goal then it is better to use binary
protocols...

Binary protocols or formats _do not_ prevent interoperability. The TCP/IP
stack is binary, the JPEG format is binary and numerous other formats are
binary and perfectly interoperable. The only thing that using non-binary
formats buy you is being able to use a "textviewer" to watch the protocol
on the wire (apps like cat, grep, more on Unix systems).

Being CORBA 2.x compliant requires supporting IIOP and thus 2.x compliant
CORBA implementations are interoperable. CORBA implementations are
available for numerous platforms (read: all) and numerous programming
languages.

The only reason SOAP is getting successful is because Microsoft's
refused to support the OMG standard. So now we'll have a new, albeit very
ineffecient "standard" protocol being SOAP.

With friendly regards,
Takis

 

[Panagiotis Issaris]

Exactly. And I just realized it was posted on a .net-group too My
point was merely that big bad binary protocol isn't just a dot-net
thingie. RMI and EJB-remoting is just as binary in the Java world.

Binary protocols are not "big bad" things. They are efficient and pretty
things if and only if they are openly specified Then there's no
reason for interoperability issues.

With friendly regards,
Takis

 

[Panagiotis Issaris]

Yes, of course, but binary protocols tend to be technology-specific. If
you use RMI in Java then you are pretty-much stuck with having a Java
client and a Java server (or at least a server that speaks RMI). If you
use .NET Remoting then you are pretty-much stuck with writing all of
your clients in .NET.

Yes, .Net is a Microsoft only solution, which will lock you into Microsoft
solutions and thus give you zero freedom of choice afterwards.

RMI is a nicer solutions since there are multiple vendors.

But the obvious solution for binary protocols is using IIOP (CORBA). It is
an open standard specified by the OMG being implemented by many vendors.
So if you choose for CORBA, you'll get freedom of choice. Which is
ofcourse not surprising, as choosing a standard has the obvious result of
giving you freedom of choice of a particular implementation.

With friendly regards,
Takis

 

[Panagiotis Issaris]

or there's ICE - http://www.zeroc.com/performance/index.html

which has the benefits of Corba without the rubbish and is highly
efficient too.

It hasn't got the benefits of CORBA as it is *no standard*. There's only
_one_ implementation of ICE, being the one that ZeroC provides.

And in fact, I found it highly disappointing that ZeroC did not just
introduce a new nicer IDL C++ mapping for CORBA.

With friendly regards,
Takis

 

[Andrew McDonagh]

It hasn't got the benefits of CORBA as it is *no standard*.

Benefits do not equal standards - or why else would we have POAs?

I've worked on enough telecoms projects which use lots of ratified
standards and each equipment manufacture implements those 'standards'
differently.

There's only
_one_ implementation of ICE, being the one that ZeroC provides.

And in fact, I found it highly disappointing that ZeroC did not just
introduce a new nicer IDL C++ mapping for CORBA.

Agreed - but ICE does a little more than that.

 

[Bent C Dalager]

hmmm couldn't this be easily solved by compression??

But then it becomes a binary protocol and you might as well just start
out with a binary one in the first place.

Cheers
Bent D

 

[Panagiotis Issaris]

Benefits do not equal standards - or why else would we have POAs?

Well, yes, but by accepting the POAs you get portability, and thus you get
choice of middleware implementation and choice of middleware
vendor/support.

I've worked on enough telecoms projects which use lots of ratified
standards and each equipment manufacture implements those 'standards'
differently.

But does dumping all standards solve anything?

When I program according to the POSIX threading specs or to the CORBA
2.6 specs, I can migrate my application from one environment to another.
Not without any changes, but still easier then when I had programmed to a
proprietary interface.

They could have dumped the parts they didn't like, and which really made a
difference. But instead, they decided to write an "entirely new"
middleware stack... which _strongly_ resembles the existing standard, but
is different (mostly simplified).

Agreed - but ICE does a little more than that.

If I were to believe their marketing page, it is the problem free solution
to all our problems, being efficient, scalable, easy and all other great
things.

On that same marketing page, they critisize CORBA for having many specs
being only implemented by "few" vendors. How many vendors implement ICE?


And this worries me too:
"Ice supports C++, Java, Python, PHP, C#, and Visual Basic. We are not
aware of any CORBA company that offers so much choice. In fact, most CORBA
vendors only offer C++ and Java. If you want to use other languages, you
have switch to different vendors, or consider using unsupported
experimental CORBA implementations."

In their mindset it is a problem if you have to rely on different vendors
for different software solutions: If you choose CORBA and want to use
multiple languages, you'll have to use products of many vendors. While if
you choose ICE, ZeroC can provide all your needs. Sounds very Microsoftish.

I would prefer to read that as: If you choose ZeroC you can only have
_one_ vendor: ZeroC.

With friendly regards,
Takis

 

[Roedy Green]

Binary protocols or formats _do not_ prevent interoperability. The TCP/IP
stack is binary, the JPEG format is binary and numerous other formats are
binary and perfectly interoperable.

The nice thing about binary formats is they are specified down to the
bit.

With any character based protocol there is always the ambiguity of
what encoding s supposed to be used. And even if the standard has
the balls to demand it, GUARANTEED you will soon find documents
floating about the universe with every encoding under the sun with
unmarked or mislabeled encodings.

 

[j-integra_support]

Yes, .Net is a Microsoft only solution, which will lock you into Microsoft

solutions and thus give you zero freedom of choice afterwards.

Not necessarily. Interoperability middleware solutions such as
J-Integra allow you to use Microsoft .NET/COM technology with Java and
Corba.

But the obvious solution for binary protocols is using IIOP (CORBA). It is
an open standard specified by the OMG being implemented by many vendors.
So if you choose for CORBA, you'll get freedom of choice. Which is
ofcourse not surprising, as choosing a standard has the obvious result of
giving you freedom of choice of a particular implementation.

J-Integra Espresso is a Corba ORB for the .NET platform that allows
your .NET clients to "talk" IIOP to Java/Corba servers. Middleware
solutions such as this allow you to use Microsoft .NET without worrying
as much about vendor lock-in.

Shane Sauer
J-Integra Interoperability Solutions
http://j-integra.intrinsyc.com/
high performance interop middleware for java, corba, com & .net

 

[Roedy Green]

Not necessarily. Interoperability middleware solutions such as
J-Integra allow you to use Microsoft .NET/COM technology with Java and
Corba.

I don't see how that follows. If you use .NET, you are locked into
MS no matter what tools you used.

Are you saying at least your Java side code can be flipped to
something else with a config parm, rather than redesigning code?

 

[j-integra_support]

Having "legacy" applications written in COM or .NET does not
necessarily mean you *HAVE* to choose Microsoft technologies for future
development. There is a great deal of interop middleware out there
which allows you to expand your infrastructure with a different
technology without losing the ability to communicate with your old
Microsoft apps (or vice versa). J-Integra is one example of a
middleware solution which provides interoperability between COM/.NET
and Java/Corba.

Shane Sauer
J-Integra Interoperability Solutions
http://j-integra.intrinsyc.com/
high performance interop middleware for java, corba, com & .net