Jeremy said:
http://xmlrpc.scripting.com/directory/1568/implementations
I would be surprised you could get one in all those environments, and
doesn't CORBA have ORB interop concerns rather often?
Not to my knowledge - I've been sucessfully interoperating TAO, Jacorb and a
VB orb without any problems - and that was 4 years ago. There used to be
problems at some time, but they seem to be solved. CORBA is much more
mature than SOAP in that respect - and others as well.
Besides, how exactly do you get CORBA going in Javascript? Squeak, from a
quick web search, doesn't have an ORB either. That's just two I plucked
out of the list.
The OP didn't say much about his environment - so I can only speculate if
there are ORBs for them available. He wanted a feature xmlrpc didn't offer
to him, so I proposed one that for a majority of projects out there is
usable.
Yes, it is in some sense a step back. That's the whole point. If it
doesn't meet your needs, don't use it, but it isn't useless, either; if
CORBA met all needs XML-RPC would never have been created, as it
post-dates CORBA by quite a lot.
It isn't useless - I use it myself. But its very limited, and if I had the
chance not to use it, I wouldn't. Unfortunately, making php running corba
is a royal pain in the neck, so I had to use xmlrpc. SOAP support is better
in php, but python lacks in that field.
I know CORBA seems easy to you, I'm willing to bet CORBA would seem easy
to me. (It can't be worse than COM, from what I hear, and I've engaged in
mortal combat with that technology a couple of times.) But there is
still a lot of programmers/scripters who really can't follow it, and
XML-RPC works better for them. (I speak of users, not implementers.)
Might be - but everybody who feels in the need of IPC should be able to use
it. Invoking an idl compiler and extending the generated server classes
isn't exactly black magic. While the learning curve for corba might be a
little bit steeper in the first place, I think that the headaches caused by
then rolling out your own session/authentication mechanism justify for
this. But this is of course an opininon - I never observed a inexpirienced
programmer choosing either technique.
The latter most likely rather than the former; the "marketing" for XML-RPC
has been "Here it is, use it if you like." The is no significant company
behind it, pushing for it, just this one guy, really. SOAP is the one with
the big marketing push.
Sure, but the marketing hype after SOAP clearly helps xmlrpc - after all,
from a non-proggramers POV (read: management and adminstrators) they are
basically the same: http-driven, thus firewall-compatible, and use xml. I
very well know that soap is _more_ than xmlrpc, can use smtp and so on -
but in 95% of usecases, it will be used in conjunction with http, making it
really close to xmlrpc.
BTW, the usual solution to the authentication problem is to require a
username and password on each call. It has its disadvantages, yes, but it
actually has a couple of security advantages, too. (There is no persistant
connection you can "break into" and get the privs of the authenticated
account; I forget what this attack is called. **Obviously** there are
other concerns, I'm just pointing this one thing out.) If authentication
I see these two as equal - in fact, a session at least can only be captured
once and only in a limited time window, where using name/password everytime
gives an attacker the key to the system at any time. Preventing either of
them only works through a secured comm-channel, like https.
And furthermore, they're basically the same - its simply a piece of data
associated with the request - no big difference here.
SOAP at least allows for http headers to be used for this for the connection
as whole, so you can e.g. with axis establish a session mechanism. But this
exactly is one of the grey areas pointed out before - it won't interoperate
between implementatitons. And the xmlrpc-hack suggested by roger binns even
needs tweaking at a deeper level.
takes a long time, cache it on the server side. It may seem clumsy but it
isn't much different than the HTTP solution with cookies (one way or
another you are passing a handful of bytes of extra state to the server),
Exactly.
and it's not like it isn't trivial to fix in any real language with a
wrapper or something. XML-RPC has real problems on large scale use but
So you end up writing wrappers - I've done that myself, of course that works
- but corba _generates_ these wrappers for you....
authentication is hardly one of them. You don't use XML-RPC when
processing bajillions of queries where the overhead of parsing XML would
be signficant is your goal. Outside of that, while persistent connections
might be nice, they would complexify the spec and smack of premature
optimization.
Calling often wanted features premature optimization strikes me a bid odd -
nearly any application that needs to communicate over several calls needs
to have some sort of session scheme, with or without authentication. And as
the underlying protocols have means to deal with such information, I wonder
why the people specifying xmlrpc as well as soap didn't think of that -
after all, we're in the 21st century, and all serious webapps make use of
sessions - cookie or url-based. So why do the specs lack in that field?
To me it looks as if they're unneccesarily reinvent the wheel, and the wheel
is close to beeing square right now. Maybe it shapes up - bdt until then,
lots of time and money has been invested to overcome the shortcomings of a
square wheel.
