Summary
Let's take an old idea, like RPC, and wrap it with some new hype and nomenclature, and then mediate it with a completely orthogonal protocol! Yeah, lets!
Advertisement
I was just idly thinking today about Web Services. You know, the big hype item that some folks hoped would break through the IT economic doldrums after dotbomb and 9/11. There were articles, magazines, conferences, and the normal hoopla, all boiling around this old concept wrapped in new clothes.
The old concept, of course, is RPC -- Remote Procedure Call. A concept, by the way, that never really succeeded in a huge way. Apparently the industry decided that we needed to take this questionably successful technique and promote it to the whole web at large.
Of course it couldn't be just remote procedure call. It had to be remote object invocation! We can't just have functions and procedures, we've got to have objects. Functions are just to passe. Objects are where it's at.
OK, so if we are going to implement remote method invocation (RMI) in a generic way, how do we do that? Clearly we don't want to invent our own protocol for that, do we. No, no, it would be much better to piggy back on some completely orthogonal protocol that evolved for utterly different reasons. But which one? Should it be SMTP, or NNTP, or CMIP?
Well.... Lots of enterprises have created a very nice security hole around HTTP. Yeah! If we use HTTP then we can sneak over the same security hole and enterprises won't have to do anything special to allow remote method calls to come in. Right?
So, yeah, lets take a protocol that evolved for the transport of HTML documents between servers and web browsers, and hijack it for transporting method invcocations complete with arguments, return values, and object serialization. Yeah! Can you spell "coupling"? I knew you could!
Ah, but there aren't enough TLAs in our scheme yet. We need more TLAs. (Three Letter Aconyms). Another popular TLA is, XML. Yeah! XML! Lets encode all the procedure invocations, method arguments, return values, object serializations, headers, footers, and all that other logistical stuff into XML documents and then tranport them over HTTP! Yeah! Can you spell "big, messy, and slow"?
OK, I'm ranting (or hand't you noticed). But really folks, if you want to provide a service on the internet, there is already a facility for that. Write a little process that sits on the back side of a socket. If the industry really needs some kind of platform independent remote method invocation (something that I seriously doubt) I think we could do better than to hijack HTTP and XML.
Well said. I think the industry is struggling to find the right balance between REST (data + very generic methods) and full-fledged RPC (XML data + application specific methods).
The reason for this partly might be that it is hard to decide a-priori how much of your application functionality should be shareable w/ others. Deciding to integrate post-application creation has proved too expensive.
And the myth of "universal schemas" still have people waxing eloquent (failures like cyc not-withstanding).
What, indeed, have *you* been smoking? Why not take a closer look at what you're ranting about? E.g. nobody - at least nobody I would take seriously - has claimed that Web services are OO.
Thanks for relieving me of some of my socket guilt. About a year ago, I had a java app that needed to communicate with a python app. This seemed like an appropriate place for SOAP, but I opted to use a socket and a string. It took like 10 minutes to implement. I've had to defend this implementation several times over the last year, but SOAP just seemed silly for the task at hand. Although, it would have made the app a much more buzzword compliant.
First, my own rant: XML (and, for that matter, TLA) is not an acronym. It's an initialism. Acronyms are pronouncable as distinct words (e.g., "laser" or "scuba" ).
OK, the main point: If you find XML-over-HTTP too messy or slow for your needs, then don't use it. But messy and slow are relative. XML-RPC is part of the standard Ruby library (and other languages, too, but let's use my favorite language as an example). It's dead simple to expose Ruby apps as XML-RPC services. And for most cases it will be fast enough. XML-RPC has become fairly ubiquitous, so the amount of code you need for a app interoperability can often be small, and save time devising your data encoding scheme.
You might also find this article interesting: "Web Services are not Distributed Objects" ( http://weblogs.cs.cornell.edu/AllThingsDistributed/archives/000343.html ), which discusses three (in the author's view) common misconceptions: Web Services Are Just Like Distributed Objects; Web Services Are RPC for the Internet; Web Services Need HTTP
James writes: >XML-RPC is part of the standard Ruby > library (and other languages, too, but let's use my > favorite language as an example).
This really is what makes Web Services/SOAP/XML-RPC different from previous RPC protocols. Why do web services matter? Compare to other recent and not-so-recent attempts. First, it's relatively simple. Compared to CORBA, writing web services is dead simple. Next, it's truly platform and language independent. The same can't be said for DCOM or Java RMI. Even CORBA bindings are few and far between. And CORBA ORBs? Few are available, and of those, the best are quite spendy. Deploying web services requires no such massive infrastructure.
To paraphrase a truism, all RPC implementations suck. Web services suck less than most.
This, of course, assumes that SOAP is fundamental for web services, which it is not, strictly speaking. Even so, the O in SOAP is a bit of a misnomer; the envelope is the most important part in current use.
When I think about web services, the spec that I think about first is WSDL, not SOAP.
I don't care about web services and the whole host of related technologies. What I do care about is having a blindingly easy way to access data provided by, say, Amazon.
In Ruby, I had to type roughly two lines at the command prompt and some tool generated a set of classes that allow very easy access to the services offered by, in this case, Amazon. I really don't care how it is implemented underneath: SOAP, WSDL, HTTP, XML. Could have been RPC, CORBA, RMI, or plain Sockets -- whatever. What I do care about is that it works.
So, if "web services" means that it works, I do care about web services after all. But I won't pledge my soul to any of the concrete technologies involved.
The core complaints about Web Services in this article do not match what I have seen in my work. WS solves a certain set of problems for me that would otherwise take effort, and thus money, to solve other ways.
The complaint that WS is chatty is fair; XML is hefty. On the other hand, it also can be watched on the wire. I have debugged a number of problems that way, and it took much less time than debugging similar binary protocols that required translation. It is very nice when tcpdump can produce a solution in a few minutes without special translation code, and even nicer when I can take an off the shelf tool and have it work out of the box to debug a problem. I am not sure that a less chatty language would allow that.
More importantly, at least for me, a great number of things Just Work. For example, Axis and WebObjects-based web applications generate WSDL files and Web Service interfaces given a working app/set of classes, without the programmer having to implement them. Thus, as a provider of applications, I can expose a web services interface cheaply. A socket-based implementation would take less time to write than Axis did, but I do not pay that cost. I only pay the cost to write my app.
Once you do have to sink effort into WS implementations, then WS may not be as inexpensive and convenient. I have had to massage Perl's Soap::Lite a fair amount to get WS output from it that can be used via Axis, and there the equation is not so clear. Simpler markup and a socket-based telnet interface might well have been sufficient for that task.
More often than not, though, I have had to expend fairly minimal amounts of effort to get a WS interface that complements a web application interface. As this opens up my apps to other b2b tools without my direct intervention, it is a win in my experience.
In summary, it has been fairly inexpensive to get WS exposure, and I have gotten more benefit than the minimal cost in most cases. When expense climbs, then a custom protocol might be a better choice, or might not. Like a dancing bear, the key for WS is not whether it is a good protocol for what it is, but whether it is good enough to solve business problems.
> First, my own rant: XML (and, for that matter, TLA) is not > an acronym. It's an initialism. Acronyms are > pronouncable as distinct words (e.g., "laser" or "scuba" > ).
XML is pronounced "zimmle". TLA is pronounced "tlaeh".
we had a presentation at work a month or so ago where an authority on the subject explained how web services support a Service-Oriented Architecture (SOA). she went on to say that although the RPC aspects have received a lot of attention, a document-centered approach is the better way to go. the primary advantage is the decoupling provided by the dependence on an extensible document.
document-centrism may seem like overkill for many applications now, but i can imagine that a long time ago, people would've thought you were idiotic to connect via a socket to a database on the same machine, and then request data using a wordy interpreted language.
although the hype is misleading, IMHO i see real value in SOA and web services.
> Well.... Lots of enterprises have created a very nice > security hole around HTTP. Yeah! If we use HTTP then we > can sneak over the same security hole and enterprises > won't have to do anything special to allow remote method > calls to come in. Right?
There are some pros you are missing here. Web servers and other beasts that use HTTP are hardened by long experience and one can expect a reasonable level of security (from DoS, spoofing and the like) and robustness (buffer overflows).
Write your own server with sockets will make for smaller code for sure but can it cope with a buffer overflow?
I stand a better chance protecting my webserver despite it being big than rediscovering all the stuff that webservers learnt years ago.
However after using XML-RCP I have to say that REST makes a lot more sense and requires less tools.
Flat View: This topic has 30 replies
on 3 pages
[
123
|
»
]
Previous Topic
