Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number

(OT) Webservices really progress?

by Aristotle (Chancellor)
on Aug 24, 2002 at 14:21 UTC ( #192542=perlmeditation: print w/replies, xml ) Need Help??

I just read a letter to the editor in a German computer magazine that concisely expresses a lot of how I’ve felt about the webservices hype in general. From <cite>iX 9/2002, pg 9</cite>:

For the same reason that an administrator closes RPC ports against outside access, that is, to prevent strangers from arbitrary calling code on the machine, he would have to close port 80 as soon as a mechnism to execute arbitrary functions is available on it.

If there is to be any security in allowing access from outside the intranet, there will have to be something like a semantic firewall analysing traffic and possibly filtering it. Not only the complexity makes this approach questionable – without a disproportionate amount of processing power in the firewall, it is not feasible to avoid denial of service attacks against a server on a high bandwidth connection.

I think it is much simpler to just communicate SOAP traffic through a separate port.

Really in the course of its future SOAP will have to reinvent all the security (and not only) mechanisms that DO, RMI, CORBA and friends already offer – and all this based on a protocol with very high redundancy.

So far, I struggle to perceive this as progress.

I couldn’t agree more.

Makeshifts last the longest.

Replies are listed 'Best First'.
Re: (OT) Webservices - really progress?
by blakem (Monsignor) on Aug 24, 2002 at 14:54 UTC
      Thanks, a good read and indeed very much like what I was posting.

      Makeshifts last the longest.

Re: (OT) Webservices - really progress?
by djantzen (Priest) on Aug 24, 2002 at 21:00 UTC

    I guess I see this principally as a problem of marketing in at least the following senses:

    First, what Microsoft is doing right now in pushing SOAP as an integral part of .NET, and with it Webservices, is wrapping up older techologies (i.e., XML-RPC, the JVM) under a single product (or product "namespace" for all its ambiguity), and by selling these once disparate technologies (by which I mean flexible and independent ;) together they ensure their hegemony for another decade because to buy into one you must buy into all.

    Secondly, SOAP/.NET is touted as a way to build sophisticated Web applications quickly and without all the overhead of competing protocols like those named in the letter (and DCOM). On the surface of it, this is progress; after all, as robust as CORBA is, it's a pain in the ass to code because of all the machinery it employs to ensure cross-language/platform compatibility and security. It's a similar story but to a lesser degree with Java RMI because at least there you're dealing with the same language on both sides of the method invocation. SOAP reintroduces flexibility and ease of development at the cost of decoupling components in a distributed system and allowing you to bypass security checks. What this means is that Web apps built using the heavier-weight protocols will typically take longer to complete and will be more resistent to change than a comparable app (comparable in terms of functionality, not reliability or security) written with SOAP.

    Unfortunately, it is clear at this point that what people expect most of the Web is continued flashiness, functionality, and ease of use. Emphasis on any one of these can reduce reliability and security, and taken together they result in disaster (MS Outlook being the premiere example). Until reliability and security are taken as valuable in and of themselves, we will continue to see software that looks nice but is rife with problems.

    As I suggested before, I think this is principally a marketing issue; SOAP is being pushed based on the virtue of quick deployment, which is anathema to secure software. Since the marketplace values increasing functionality, aesthetics and ease of use primarily, there is cash to be made in allowing developers to create cooler things faster. But to quote tilly from the excellent thread blakem suggested, "If security is something people have to get right again and again, then mistakes will happen. Repeatedly. And people will turn out to (quite predictably) wind up making similar mistakes, making life quite convenient for crackers."

Re: (OT) Webservices - really progress?
by Anonymous Monk on Aug 24, 2002 at 15:28 UTC
    Port 443 (https) is a far more immediate problem. Currently nothing is recorded other than the fact that a connection has been made, and this fact has been used for years by people who want to get things working through corporate firewalls. Things like online purchases, unauthorized vpns, and private emails. A lot of competently written malware probably does the same, only nobody notices because current tools can't break ssl-encrypted communications to audit them.

    Someone really needs to take sslsniff and turn it into a proper administrative tool. Admittedly it currently works through an IE mistake, but sysadmins can configure computers on the network to believe that you are a valid CA.

Re: (OT) Webservices - really progress?
by dws (Chancellor) on Aug 24, 2002 at 16:43 UTC
    An administrator ... would have to close port 80 as soon as a mechnism to execute arbitrary functions is available on it.

    This is a bit misleading, since web services aren't about executing arbitrary functions. (Though a poorly implemented SOAP server can do nearly that.) Web Services will most likely deploy within an Intranet or VPN. Living out in the wild may prove to be the exception.

    I suspect the author of that letter to the editor is miffed that his favorite protocol is no longer on the top of theheap.

      SOAP means Simple Object Access Protocol; it is nothing but a fancy remote procedure call mechanism.

      Granted living out in the wild and totally open to anyone will likely be an exception. However, webservices are touted as the tool for electronic B2B and as such, they will have to live in semi-private situations in the wild where they aren't necessarily open to anyone, but certainly accessible.

      Makeshifts last the longest.

        SOAP means Simple Object Access Protocol; it is nothing but a fancy remote procedure call mechanism.

        Yes. This means that a correct implementation can only invoke a remote procedure by identifier. Unfortunately, at least one buggy implementation has allowed callers to invoke arbitrary Perl code on the server. This muddies the waters.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://192542]
Approved by ignatz
[MidLifeXis]: Most likely it is a code that some undocumented system, hidden behind layers of IT, deep in the bowels of the building under the machine room floor, reads that code to keep a presence switch from going off. :-b
[MidLifeXis]: I think I forgot "running on a farm of commodore 64, vic 20s, trs 80s, and apple ]|[e systems"
[GotToBTru]: oh I know what it is .. but it is a number only slightly useful to me and of no possible use to our customer
[MidLifeXis]: Whew - you just saved the free world. <o)
[GotToBTru]: i guess it's a placeholder, the code will only fill it in if there is nothing else to use
[GotToBTru]: but then .. if you have nothing to say, why not say nothing?
[MidLifeXis]: I have a user who has a lot of say on how some of our processes work that abhors significant blanks. Perhaps that is a part of it. A not-so-obvious "this space intentionally left blank" indicator.

How do I use this? | Other CB clients
Other Users?
Others romping around the Monastery: (8)
As of 2017-01-20 19:09 GMT
Find Nodes?
    Voting Booth?
    Do you watch meteor showers?

    Results (176 votes). Check out past polls.