Forgot your password?
typodupeerror
Patents Businesses Red Hat Software Your Rights Online

Red Hat Claims Patent On SOAP Over CGI 191

Posted by kdawson
from the wash-your-mouth-out dept.
WMGarrison writes "US Patent 7453593 claims command-line processing by a web server of SOAP requests, resulting in XML responses, from and to a remote client. The HTTP Common Gateway Interface (CGI) operates precisely as described in Claim 1. If you POST a SOAP document and return an XHTML response or a SOAP document, this infringes Claim 2, since both XHTML and SOAP are XML languages. This patent thus claims to own the processing of SOAP documents by CGI programs."
This discussion has been archived. No new comments can be posted.

Red Hat Claims Patent On SOAP Over CGI

Comments Filter:
  • by haystor (102186) on Friday March 20, 2009 @11:34AM (#27268977)

    If this results in the abandonment of SOAP, I'm all for it.

    • they will get rid of SHOWERS.

      • Most of IT support and administration staff weren't fond enough of SHOWERS to use it. SOAP itself wasn't necessarily a child process or deamon for SHOWERS as it also worked with BATH and HANDWASH. Neither of which are popular either. Most of them will just hope that DEODORANT will cover up the problems that SOAP, SHOWERS, or BATH would have fixed but generally everyone can tell if they start sniffing around the network.

        I hear good things about the open source project PTA BATH.

        • by foobsr (693224)
          PTA BATH

          Taking advantage of prior art like the ultrasonic shower (Asimov, robot series IIRC) or the sonovac (2001) would be a good idea. Admittedly, I since I first read about these ultrasonic devices decades ago (when there was no such thing like the 'basement geek culture' (??) I am very fond of the idea.

          CC.
      • Wow... clever invocation of Godwin's Law.
        • by TheLink (130905)
          No he said: "they will get rid of SHOWERS."

          Doing a Godwin would be: In Nazi Germany, SHOWERS get rid of YOU!
    • If this results in the abandonment of SOAP, I'm all for it.

      No complaints there, but it would be inconvenient if you're no longer allowed to return XML in response to a request. Even a large proportion of HTML documents are valid XML, so hypothetically you might have to include unclosed tags in your pages to be on the safe side.

    • Sure SOAP is complex, but that complexity can be encapsulated away. Really, the alternative is what? Everyone coming up with completely incompatible data transmission formats, reinventing the wheel and making the same mistakes over and over?

      • Re: (Score:2, Insightful)

        by haystor (102186)

        I'm not sure what SOAP solves. What does that complexity buy me? I've written to API's in XML, fixed width files, serialized objects, url encoded, cgi post, shared memory, named pipes and others.

        All SOAP manages to do is make object instantiation and invocation look nothing like what is going on.

        SOAP is not abstraction it is misdirection.

        COBOL files were typically well defined. Writing a parser and validator for them would take less time than setting up the same for SOAP. I'm not suggesting we go back t

        • Guh? SOAP solves the problem of "how can I move the discussion of RPC communications to what's important - the contract." If you need high performance and SOAP doesn't cut it, by all means use something else.

          You don't have to do anything to "set up" SOAP. I can make a SOAP service based in Java or .NET that can use secure communications using SSL, Kerberos, Certificates, or other mechanisms in a matter of minutes.

          It can get extremely complicated, but so can any complex RPC implementation.

          SOAP isn't going

      • by i_ate_god (899684)

        Sure SOAP is complex, but that complexity can be encapsulated away. Really, the alternative is what? Everyone coming up with completely incompatible data transmission formats, reinventing the wheel and making the same mistakes over and over?

        Uh... use HTTP for what it was designed for?

        GET /resourceName/resourceId

        PUT /resourceName?param1=val1&param2=val2

        POST /resourceName/resourceId?param1=val1&param2=val2

        DELETE /resourceName/resourceId

        ok, that's not a perfect representation, but HTTP has all your CRUD methods, which is really all you need. You use GET to perform queries, you use PUT and POST to CREATE and UPDATE respectively, and DELETE to... DELETE!

        The HTTP protocol makes a hell of a lot more sense than using SOAP, it's a deeply rooted

        • That is insane. Have you ever actually tried that stuff? Firewalls, cache, all these things don't behave well with GET. Furthermore, there are arbitrary limits to GET string length.

          At the very least, any browser/server communication format must be able to handle arbitrarily complex datastructures of arbitrary length... unless you're writing toy apps.

          • by mini me (132455)
            1. If your firewall is broken, fix your firewall.
            2. If your is broken, fix your cache.
            3. What difference does it make if GET has an upper length limit? You're only requesting a short URI. When you are sending data you are using POST or PUT which do not have the same limits imposed on them.

            The web browser is just another web service client. Slashdot is just another web service. The mere fact you were able to post your message shows that the model works just fine. Why add unnecessary complexity?

          • by i_ate_god (899684) on Friday March 20, 2009 @02:27PM (#27271527) Homepage

            That is insane. Have you ever actually tried that stuff? Firewalls, cache, all these things don't behave well with GET. Furthermore, there are arbitrary limits to GET string length.

            At the very least, any browser/server communication format must be able to handle arbitrarily complex datastructures of arbitrary length... unless you're writing toy apps.

            You're so very wrong. The HTTP protocol does not define a max length for the GET query string. Any complex data structure can be represented by XML and you can return 100gb of XML if you want. Simpler structures can even be represented by JSON which might be even easier.

            As for firewall and cache, well... stop setting up idiotic solutions. Your public API is exposed via HTTP. So your firewall and caching solutions need to represent this. If it doesn't, that's because you did something wrong and missed the point. HTTP is highly scalable and that's the point. If your public API are serving massive requests very frequently, throw squid infront of your HTTP server. If you want some obfuscation set your port to something other than 80. Your excuses for firewall and caching don't make a lot of sense.

            • As to GET and PUT limitations: http://support.microsoft.com/kb/208427 [microsoft.com]

              As to browser cache and proxy behavior: You are assuming app developers have control over their users' browsers and proxy servers. That's a false assumption. You just failed to meet the minim requirements for the project (working on ie6 with ghettoproxy 0.1).

              • by i_ate_god (899684) on Friday March 20, 2009 @03:03PM (#27272193) Homepage

                As to GET and PUT limitations: http://support.microsoft.com/kb/208427 [microsoft.com]

                As to browser cache and proxy behavior: You are assuming app developers have control over their users' browsers and proxy servers. That's a false assumption. You just failed to meet the minim requirements for the project (working on ie6 with ghettoproxy 0.1).

                You don't know what you're talking about. Who mentioned browsers? Since when do browsers make direct SOAP calls to SOAP-based web services? They don't. Applications make SOAP-based requests to web services and then serves up views based on the data models the web service returns. The problem with SOAP is that SOAP reinvented HTTP. HTTP is perfectly geared to handle this notion of a centralized API with many applications using the same API. You can use this setup with ANY KIND OF APPLICATION, whether it be a desktop app, a web app, a command line app. You don't even need the internet.

                • User makes request
                • Application receives request, fetches data from RESTful webservice over HTTP
                • Centralized API fetches data, returns it to application
                • Application displays top ten favorite movies to user

                If you somehow see a problem with this, then you're working in the wrong job.

              • by blueskies (525815)

                That's not a GET and PUT limitation. That is a IE 6 limitation. That's a huge difference.

                All you need to do is force upgrade people using IE6. Use one of the various browser exploits that exist for IE6, and upgrade their computer for them. In fact, don't bother sniffing for IE6, if they have IE6 your code will exploit them, upgrade their computer and reboot. You'll slowly be patching the entire internet.

        • by Fnord (1756)

          The REST model is probably a good thing, but HTTP doesn't type your parameters, doesn't allow datastructures more complex than key value pairs, and doesn't do input validation. In most cases where I've seen people using HTTP as a REST mechanism, they end up needing complex data, and end up sending ... *drumroll* ... blocks of XML! Unspec'd, incompatible, app specific XML layouts. SOAP isn't the answer, but it solved some problems very well that HTTP doesn't even approach.

        • "Uh... use HTTP for what it was designed for?"

          You mean delivering static pages? You can use HTTP for web services, but it certainly wasn't designed for that purpose.

      • by mini me (132455)

        Really, the alternative is what?

        HTTP?

        I'm sure you have some edge case waiting to point out where HTTP fails and SOAP does not. But just because SOAP is better suited for one out of every million projects, it does not mean that it is suitable for every project.

        It comes down to using the right tool for the job. SOAP may have it's place, but if you're writing a quick CGI script to expose a web service like the article seems to imply, SOAP is most certainly not the right tool.

      • Really, the alternative is what?

        XMLRPC (which would probably also be covered by this patent)?

      • by sjames (1099)

        Encapsulation doesn't remove complexity, it just hides it away so it can cause hard to find bugs.

        A good scheme would make simple things easy and hard things possible. SOAP violates that by making practically anything moderately hard (or at least complex).

        If your encapsulation is going to have THAT much overhead, it needs to provide a lot more benefit than SOAP does over simpler and more compact representations.

  • by unlametheweak (1102159) on Friday March 20, 2009 @11:35AM (#27268997)

    OK, to save companies time and money (except for the Trolls and parasites), just get rid of software patents already. It's not good for buyers or sellers. It's not good for employees. It only benefits lawyers and patent troll parasites. Patent reform shouldn't take years, it should take days. I don't want to see another story like this ever again.

  • by neo (4625)

    Since returning HTML would not be covered, AHAH requests would not be covered.

    You should be using AHAH anyway.

  • by olddotter (638430) on Friday March 20, 2009 @11:38AM (#27269053) Homepage

    Perhaps I should patent Talking. A means of transferring information between people. If you submit audible sounds to a individual and get audible sounds back, then you are infringing. :-) For a follow up I'll patent political speeches.

    When will the madness end?

    • I should patent (Score:3, Informative)

      by einhverfr (238914)

      A circular load bearing device where a bent-wood rim is suspended around a hub with wooden segments of equal length. This is useful as a method of facilitating the motion of wagons, chariots and the like. Optionally a metal (bronze or iron) rim can be placed around the wooden rim adding greater durability at the expense of weight.

      • A circular load bearing device where a bent-wood rim is suspended around a hub[...]

        Except in Australia, such a patent was issued [ipmenu.com].

  • Ok so who patented POSTing a JSON and returning an XML? Or GETing a key/value pair and returning JSON? Or POSTing XML and returning porn?

    And why only over CGI? Why not patent the use of server text preprocessors as well?

  • 1. Red Hat are now employing too many lawyers and they need something to do.

    2. Red Hat have started to become the target of a lot of patent trolls themselves and this is what the said lawyers recommend as a defense mechanism.
  • by Dachannien (617929) on Friday March 20, 2009 @11:42AM (#27269097)

    All of the various "free patents" sites are pure spam. The USPTO, like many other patent offices around the world, lets you view patents online for free - including free from ads.

    In this particular case, you can read the patent here [uspto.gov], straight from the horse's mouth.

    • by pieterh (196118) on Friday March 20, 2009 @12:15PM (#27269557) Homepage

      Actually, I think you're wrong and overmoderated. I've been trying freepatentsonline.com and it is pretty neat.

      Negative points: adverts, and these go away when you sign in.

      Positive points: extensive search functions (e.g. search on all different fields), ability to save searches, ability to download search results as spreadsheets (not figured out how yet).

      Of course you can read the patent without ads on the USPTO site. But the hard part is searching patents.

      Maybe you want to actually try the site before making blanket statements about "all free patent sites being pure spam". I think Google patent search is also pretty neat, and it's free.

      And the USPTO site is also free.

    • The USPTO, like many other patent offices around the world, lets you view patents online for free - including free from ads.

      The various "free patents" sites provide the service of translating the images from TIFF in an obscure codec to something more popular, such as JPEG, PNG, or PDF.

    • by jank1887 (815982)

      does USPTO give you PDF download of the full document? I go to see images, and I'm told I need a TIF plugin. a quick registration at freepatentsonline, and I can download the full PDF. Google patents, I can download a registration free PDF download. Both are 'image pdf' files with non selectable text. wikipatents is interesting, but doesn't quite do it for me.

      USPTO is behind the times. But that's to be expected.

  • Defensive patents (Score:5, Insightful)

    by Richard W.M. Jones (591125) <[gro.aixenna] [ta] [hcir]> on Friday March 20, 2009 @11:43AM (#27269113) Homepage
    These are defensive patents. You have to file them if you're in the US software business, or else risk getting sued for $billions. Read how Red Hat licenses their patent portfolio to all open source projects [redhat.com].
    • Re: (Score:3, Insightful)

      by Obfuscant (592200)
      If software patents are bad, then they are bad. You can't claim you are doing a Good Thing by patenting something simple and obvious and then prohibiting some people from using it.

      That's what they are doing by promising not to sue Open Source projects for using THEIR patented intellectual property. It's still THEIR patented intellectual property, and they'll sue closed source projects for using it.

      What's even worse is they renig on their promise if an Open Source project tries to challenge Red Hat's claim

      • Re: (Score:2, Informative)

        by Anonymous Coward

        Oh how adorable!

        Is your mommie a lawyer? You should ask her to read their patent promise to you one night before bed.

        In particular, she could explain to you the difference between "patent litigation" and a patent re-examination. They are not the same thing (yes, I'm ignoring ex parte vs. inter partes).

        The phrase you refer to means that the license for a third party to use the patents is terminated if that third party attempts to sue the holder over any other software patent.

        Ps. it's "renege".

      • by pembo13 (770295)

        > You can't claim you are doing a Good Thing

        RedHat never claimed it was doing a good thing. Just doing something for survival _while_ they try to get patent reform.

      • Wrenches can be used to kill people. So can metal broomhandles and tennis rackets. This fact does not make anyone who carries a wrench, a broomhandle, or a tennis racket a bad murderer.

        (My father used to keep a tennis racket in the car to arm himself when he was in a bad neighborhood - works well and you won't be accused of brandishing a weapon)

        There are few (any?) other companies that 'get' OSS more/better than Red Hat. They license their patents to the community at large, effectively subverting the usual

        • by Obfuscant (592200)
          Wrenches can be used to kill people. So can metal broomhandles and tennis rackets. This fact does not make anyone who carries a wrench, a broomhandle, or a tennis racket a bad murderer.

          However, when someone buys a wrench (gets the software patent) and then smacks someone over the head with it (denies them the right to use the IP protected by that patent) they are guilty of attempted murder (using software patents to protect their IP.) Only if you buy a wrench (get the patent) and then never hit anyone wit

      • by Ant P. (974313)

        If (strawman) then {meaningless conclusion}.

        Replace "software patents" with "handguns", "bittorrent clients" or "$minor_feature_in_desktop_environment_X" to suit the invalid point being pushed.

    • Re: (Score:3, Funny)

      by gandhi_2 (1108023)
      Oh...so like a litigious Boondock Saints?
    • Re: (Score:2, Insightful)

      by ryran (942995)
      Thanks for posting the link! It should've been posted along with the article. .... Although I had never read it before, I already knew what it [much more explicitly] states: Red Hat cares about the community -- they owe everything to the community; they're not trying to extort the community. Having a firm grasp on the history of things, and having worked with Red Hat employees a lot, it's hard for me to understand how people can't see that.
      • by pieterh (196118)

        Red Hat is not one thing. It is:

        - a community of engineers
        - a bunch of lawyers and accounts
        - a group of shareholders

        and more. I think the value of this story is not to show that the engineers are bad people. It's to show that the lawyers and accountants have a lot of power and could abuse that.

        It probably goes without saying that Red Hat engineers are generally really smart and ethical people - you don't work for an open source company otherwise.

        A lot of technology firms have tensions between the patent

        • by Obfuscant (592200)
          It probably goes without saying that Red Hat engineers are generally really smart and ethical people - you don't work for an open source company otherwise.

          Then it is the Red Hat lawyers prodded by the shareholders who file for patents on software, which the engineers think are bad, and expect closed-source software companies to license the IP.

          If Red Hat objected to software patents in general, they'd file for the patent and then let ANYONE use it. That's what would happen if there were no software patent

    • by RingDev (879105)

      These are defensive patents. You have to file them if you're in the US software business, or else risk getting sued for $billions.

      I disagree.

      If their only concern were defense, then the solution is obvious! PUBLISH. The only difference between publishing your invention and patenting your invention is that you can sue someone for violating your IP rights associated with the patent.

      If they publish their invention, it is out there in the wild acting as prior art. If anyone else were to come along and try to sue them over a patent that the plaintiff had been issued after the defendant had published, all they have to do is point to the pub

      • by teg (97890)

        If their only concern were defense, then the solution is obvious! PUBLISH. The only difference between publishing your invention and patenting your invention is that you can sue someone for violating your IP rights associated with the patent.

        Publishing would protect against being sued for this particular "invention". What defensive means in this context is to have a portfolio of patents - if another software vendor sues for violating their patents, Red Hat can point at their portfolio and say "you are v

  • The In Re Bilski case invalidates this patent, as it is not tied to a particular machine.

    DISCLAIMER: Not only am I not a lawyer, my sole basis for my statement is knowledge gained from my somewhat-attentive reading of previous /. comments (not articles) regarding the "In Re Bilski" case. I'm not sure if the word "case" applies to In Re Bilski. I'm not sure if "In Re Bilski" should be written with initial caps, as opposed to "in re Bilski", for instance.

    • Re: (Score:2, Informative)

      by jerrund (464194)

      Bilski doesn't apply here, as the In Re Bilski ruling only applies to Process claims. The claims in question are directed to a system.

      • the In Re Bilski ruling only applies to Process claims. The claims in question are directed to a system.

        If a system's only novel aspect is a process that happens in the system, in this case XML encoding and decoding at each side of the connection, then what's the difference [wikipedia.org] between a system claim and a process claim?

  • Acronyms (Score:3, Funny)

    by necro81 (917438) on Friday March 20, 2009 @11:46AM (#27269189) Journal
    I haven't had to wade through that many acronyms since "Good Morning Vietnam [youtube.com]"
  • by Rogu3 (1504073)
    MS Robotics Studio uses Soap to XML. Haha, how like life now.
  • I mean, SOAP's entire purpose is to be a messaging mechanism over different mediums, protocols, architectures, and implementations; ergo, if I implement "Handling SOAP over " how on earth could that be patentable? Maybe they're referring to actual soap (like Lava, or Lever 2000, summat...)

  • Someone had to... (Score:4, Insightful)

    by neowolf (173735) on Friday March 20, 2009 @12:09PM (#27269479)

    Face it- if Red Hat hadn't done it, M$ probably would have. It's likely a "defensive" patent they are unlikely to use unless provoked. It's all just a game. A big, high-stakes, unfortunate game.

  • SixApart should lay down the law [soaplite.com].
  • bric_soap (Score:2, Informative)

    by kwoff (516741)

    I've been using such a command called bric_soap in Bricolage [bricolage.cc] (Perl-based CMS) for the last six years at least.

    Introduced in 2002: ViewVC [bricolage.cc]

    An example (see the API docs [bricolage.cc], navigate to bin -> bric_soap ...): "Republish all published stories. This is useful when a template change needs to be reflected across a site. The sort -k2 -t_ -n is a crude way to make sure that newer stories overwrite older ones."

    bric_soap story list_ids --search publish_status=1 | sort -k2 -t_ -n | bric_soap workflow publish -

  • RIP (Score:5, Funny)

    by thethibs (882667) on Friday March 20, 2009 @01:28PM (#27270671) Homepage

    With any luck, this will finally put SOAP to REST.

  • When I was at Cabela's we had built what is now called SOAP. We were doing XML request/responses across HTTP LONG before SOAP was SOAP... That prior art will blow this patent out no matter WHO claims it... We were sending XML to from an AS/400 to/from Apache web servers / Java web servers. We compiled the source for castor on the AS/400 and were marshelling/demarshelling XML on an AS/400.

  • Patent 101.... (Score:3, Informative)

    by twivel (89696) on Friday March 20, 2009 @02:49PM (#27271949)

    A patent is not infringed upon unless all claims within the patent are infringed upon. The slashdot submission does not take into account the other claims in the patent.

    Of course, that doesn't really matter, because there are numerous prior art implementations of a CLI integrating to SOAP for something like this. For example, IBM WebSphere Portal has an xmlaccess command line utility that does exactly this.

If I'd known computer science was going to be like this, I'd never have given up being a rock 'n' roll star. -- G. Hirst

Working...