Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Apache Software

Exploring Apache's SOAP Serialization APIs 147

Posted by Hemos from the programming-with-dial dept.
Irish writes "This IBM developerWorks article discusses the theoretical underpinnings of SOAP's type system. Its a good article for anyone who wants to learn more about SOAP's programmatic support or to simply better understand Apache's SOAP."
This discussion has been archived. No new comments can be posted.

Exploring Apache's SOAP Serialization APIs More

Exploring Apache's SOAP Serialization APIs

Comments Filter:

  • A nice SOAP client/server can be found: (Score:4, Informative)

    by Macaw2000 ( 103146 ) on Wednesday April 03, 2002 @12:31AM (#3275061)
    here. [gotdotnet.com]

  • Ouch (Score:1, Troll)

    by Anonymous Coward
    AARGH my -eyes-, my eyes!! This scheme would give a colorblind guy a headache.

    What's with that?

    • Re:Ouch (Score:1, Funny)

      by Anonymous Coward
      well, so many slashsdot readers go blind from masturbation, they don't notice so much.

      Seriously, though, it reminds me of my toilet after eating bad mexican food.
  • It seems like the whole SOAP system is a great way to incorporte different datasets together for transmition and interaction (ie Java, XML, etc..). I hope that this project really has a chance to mature and get a good following.

    Plus hey..... any added feature (or weapon) we can give to Apache the better.
    • No, soap is a horrid protocol. And, despite the name, it explicitly says in its documentation that it doesn't provide support for remote object references. Basically, when you compare a system like SOAP to something mature, featureful, and powerul like CORBA, you see that SOAP is just barely a level above direct network access from a programming perspective.

      In addition, there is no set standard encoding for data. How on earth is that supposed to promote interoperability?

  • Bruce Schneier has said: (Score:5, Interesting)

    by Gis_Sat_Hack ( 101484 ) on Wednesday April 03, 2002 @12:42AM (#3275094) Homepage
    Implementation of Microsoft SOAP, a protocol running over HTTP precisely so it could bypass firewalls, should be withdrawn. According to the Microsoft documentation: "Since SOAP relies on HTTP as the transport mechanism, and most firewalls allow HTTP to pass through, you'll have no problem invoking SOAP endpoints from either side of a firewall." It is exactly this feature-above-security mindset that needs to go. It may be that SOAP offers sufficient security mechanisms, proper separation of code and data. However, Microsoft promotes it for its security avoidance.

    source:
    http://www.counterpane.com/crypto-gram- 0202.html

    • Re:Bruce Schneier has said: (Score:5, Informative)

      by steve_l ( 109732 ) on Wednesday April 03, 2002 @01:09AM (#3275185) Homepage
      Bruce hasnt looked at the protocol enough, he is being paranoid.

      well, doing SOAP callbacks into the firewall is hard because you have to have an accessible endpoint...for this reason you cant do SOAP callbacks over HTTP. But some of the other transports: SMTP, Jabber, do work and go through firewalls like nobodies business.

      Another issue is that you can't tell whether the message is good or bad from the header; it will always be a POST and the same endpoint/URL could be used from everything from a side effect free get to a malicious bufferstomping write.

      You need to look inside the XML payload, and, being XML, that means understanding XML...string matching is not enough, not when you can disguise stuff with escaping, UTF or Unicode formats, etc.
      • Err, I think Bruce would be well aware that I can't breach the firewall outside->inside. It's the OTHER direction he is "paranoid" about. I agree. If I allow only protocols X & Y to get out on ports X1 & Y1, I will not be impressed if a user/client breeches this by tunnelling XML data through protocol X. This is a completely valid argument in a sensitive environment.
        • maybe he is being prescient.

          A fair bit of stuff in soap land (ws-routing, now the MS GXA stuff) is about soap messages sent using some store and forward mechanism, routing it to the final destination without the sender knowing the actuall endpoint.

          One stated objective for this is to allow asynchronous replies/callbacks/events, which means that you will have to allow these messages back through the firewall.

          If this is done using SMTP or an IM protocol, we are in trouble as there is not enough validation by the firewall (esp. with IM), but for any of this stuff, it all boils down to 'do you trust MS and Sun (and Apache) to write code that is secure out the box', and 'do you trust the people who write SOAP based apps to not make things worse. I have more faith on apache than the other two infrastructure providers, even though Apache Axis has its own security issued (filed one on bugzilla last week). As a web service developer, I dont even trust my own code to be secure
    • SOAP is not tied to HTTP, just most of the examples are.
    • And your post back to the client is going to get through my PIX firewall how?

      I did not know that marketing people read slashdot.

    • Oh common (Score:4, Insightful)

      by apankrat ( 314147 ) on Wednesday April 03, 2002 @02:07AM (#3275383) Homepage
      You certainly can preach about 'feature-above-security mindset that needs to go' for as long as you want, but when it will come to the product not working at your biggest customer site due to the firewall setup and them not willing to mess it up just for trying out yet-another-beta proggy, you will consider SOAP, stunnel [stunnel.org], httptunnel [nocrew.org] and anything else that will get you closer to the goal.

      I agree that positioning SOAP as firewall-transparent protocol is .. err .. may get interpreted incorrectly by less experienced members of comp.sci society, but .. hey! .. you can misuse almost everything.

      .. and (not re: your post, but a thread head) XML-based marshalling ? Give me a break ... Once you start tuning the performance, you realize that bottleneck is often exactly in the freaking SOAP layer with its bloated XML data encoding. You certianly can compress it, but what's the need in XML there for then ?
    • Since SOAP relies on HTTP as the transport mechanism...
      The documentation is wrong. While HTTP is often used as the transport mechanism, SOAP doesn't rely on it. Read the spec.
      • I wouldn't assume that the documentation is wrong, but that Bruce Schneier is. The quote in the parent accurately reflects what is in Schneier's essay: He makes an unsourced reference to "Microsoft's Documentation". I wonder what else he makes up in the article.

        In this article [microsoft.com], MS "...demonstrates the creation of SOAP servers and clients that communicate using different transports: sockets, Microsoft Message Queue, the file system, and a custom HTTP listener."

        In this one [microsoft.com], we find the quote: "The fourth part of the specification defines a binding between SOAP and HTTP. However, this part is also optional. You can use SOAP in combination with any transport protocol or mechanism that is able to transport the SOAP envelope, including SMTP, FTP or even a floppy disk."

        At the top of the main developer resources for SOAP page [microsoft.com], we find another quote: "SOAP is a lightweight and simple XML-based protocol that is designed to exchange structured and typed information on the Web. The purpose of SOAP is to enable rich and automated Web services based on a shared and open Web infrastructure. SOAP can be used in combination with a variety of existing Internet protocols and formats including HTTP, SMTP, and MIME and can support a wide range of applications from messaging systems to RPC"

    • Re:Bruce Schneier has said: (Score:4, Insightful)

      by microTodd ( 240390 ) on Wednesday April 03, 2002 @02:48AM (#3275486) Homepage Journal
      If you use SSL with either Basic Authentication or some PKI mechanism then you could somewhat trust your client anyways.

      Also, some SOAP/Servlet containers don't run on port 80, they run on port 8080 or something like that. Just because it uses HTTP doesn't mean its using port 80.

      Besides, shouldn't your public web server be in the DMZ anyways, and your SOAP application server inside the firewall? So why are you allowing all port 80 traffic inbound?

    • Re:Bruce Schneier has said: (Score:5, Informative)

      by mmusn ( 567069 ) on Wednesday April 03, 2002 @03:07AM (#3275539)
      By that argument, let's get rid of HTTP. I mean, HTTP invokes remote procedures on the web server, in the form of servlets and CGI scripts. In different words, SOAP is no less secure than HTTP. If your firewall passes HTTP to the wrong internal servers, you have a security problem, no matter whether you are running SOAP or not.

    • Corba over HTTP(S)? (Score:4, Insightful)

      by Baki ( 72515 ) on Wednesday April 03, 2002 @07:24AM (#3276038)
      One of the advantages of Soap is proclaimed to be that it runs over HTTP (available everywhere) and also it is buzz-work compliant (XML).

      One could also run Corba over HTTP. Corba can use any transport medium. IIOP was only intended to be one of many possible, and if firewalls etc are really the problem, then why not run Corba over HTTP?

      I don't see any other 'advantages' from Soap over Corba. WSDL is an XML format describing the service. Why should it be better than IDL? Both can be parsed by machines and read by humans. With DII (dynamic invocation interface) one can build in generic Corba-over-HTTP client functionality in any program (such as a webbrowser).

      Really, what's new? What's wrong with Corba? Implementing a Corba service in a language such as Java (which takes care of memory management issues and integrates very well with IDL) is trivial. Writing clients even more so.

    • Re:Bruce Schneier has said: (Score:4, Insightful)

      by Zeinfeld ( 263942 ) on Wednesday April 03, 2002 @09:28AM (#3276301) Homepage
      Bruce says many things he really should not and often with far less thought than he should. You would think that someone who spends so much time talking to journalists would understand the way his pronouncements are taken.

      The reason that Bruce is quoted so often on security is that he returns journalists calls within an hour or two and gives a quotable quote by the deadline.

      I discussed the SOAP paper with Bruce and Adam. The comment about SOAP was not intended to be taken as gospel, it was simply a throw-away comment added to the end of a section.

      Bruce's security expertise is largely in the area of cryptography. He has not been a player in the network security protocols area. His last foray into that area was his criticism of IPSEC which was wrong on almost every count according to Steve Bellovin (who knows rather a lot about internet firewalls having helped invent them)

      The criticisms Bruce makes would be valid if they had not been anticipated. Microsoft has actually developed a very comprehensive security architecture for SOAP and .NET, one of the lead designers was Brian LaMachia who some folk will know as the one time author of the MIT PGP key server.

      A big problem with firewalls is that they are in most cases managed by people whose job is to stop bad things happening, it is not their job to help make usefull things happen.

      Another big problem is that they are often used in the manner of a +5 amulet of protection against hackers, the company does not know how they work but they hope they will ward of attacks. My company installs and configures firewalls. It is not uncommon for our PSO to go onsite to re-configure a longstanding installation and find that it is configured for passthrough on all ports.

      If you deploy SOAP you need an application layer firewall. Which coincidentally Microsoft just happened to demonstrate at RSA 2002. Now running a firewall on top of Win2K would be a pretty bad idea, you don't want a full feature O/S for that type of application. But running a firewall over the NT for embedded systems that is comming soon would be a pretty good idea, particularly with the .NET security framework.

      • A big problem with firewalls is that they are in most cases managed by people whose job is to stop bad things happening, it is not their job to help make usefull things happen.

        This is rubbish. You can EASILY ensure that no bad thing happens, just unplug the internet connection. Similarly, you can easily ensure that any application can do what it wants, just remove the firewall and replace it with a NAT box or router as required. Firewall administrators spend their time finding a balance which allows the useful stuff from happening with a minimal risk.

        • Firewall administrators spend their time finding a balance which allows the useful stuff from happening with a minimal risk.

          Either you are a firewall administrator protecting the guild or you have never worked in a large company.

          In a large company the firewall admins spend their time in CYA mode. It is not unusual for one of my consulting people doing non-firewall work that requires a firewall config to arrive on site to find it not done. The customer knows that the only way to make a change happen is to have a consultant onsite racking up $2,000 a day who is waiting for the change. It is not unusual for the consultant to wait several days.

    • It's not security avoidance, it's stupidity avoidance. RFC 3093 [ietf.org] and (to some extent) ssh tunnelling are in the same spirit. Until now, being able to do useful Internet communications (other than http) through a firewall has been limited to those geeky enough to set up some kind of tunnel or workaround. Well done to Microsoft for opening it up to the masses.

      I feel like predicting that in five years' time _all_ major services (including NFS, etc) will operate over http, that being the only way to make them accessible to most Web users. (Gloomily assuming that IPv6 doesn't take off and ISPs continue on their current path of masquerading and transparent proxying.) Then 'next generation' firewalls will appear which are able to selectively block SOAP packets and other kinds of http requests. But to bypass that, Microsoft will soon switch to https instead, and that will be the end of firewalls. Unless you give your firewall a copy of your servers' private keys so it can snoop on communications.

  • SOAP ain't so 'S'imple no mo (Score:4, Informative)

    by Anonymous Coward on Wednesday April 03, 2002 @12:46AM (#3275107)
    XML RPC is simple - it has a 4 page specification. SOAP is, well, not so simple. SOAP started out simple, but then committees got a hold of it. Try reading the specification - it's well over 100 pages long - and all legaleeze. All this crazy namespace and XSLT stuff only adds to its bloat. Surely we all can find a compromise between the simplicity of XML RPC and the robustness of SOAP. I have read that Don Box himself is questioning the SOAP protocol, or at the very least the HTTP transport it is coupled with.

    • Re:SOAP ain't so 'S'imple no mo (Score:2, Informative)

      by Anonymous Coward
      It is hard to argue with XMLRPC's simplicity....

      The XMLRPC specification [xmlrpc.com]

      XMLRPC.org [xmlrpc.com]

      XMLRPC bindings exist for Perl, Python, Java, Frontier, C/C++, Lisp, PHP, Microsoft.NET, Rebol, Real Basic, Tcl, Delphi, WebObjects and Zope.
      • XMLRPC is too limited...no IDL like spec language, no rich fault, and no easy inclusion of XML inside the envelope. But it is easy to implement.

        regarding dbox on soap, he seemed more minded last week towards SOAP as documents, not SOAP as RPC, which ties in with store and forward transports like, um, SMTP.
        • no idl? Take a look at the Introspect extension methods that most all of the implementations supply.

          It is also so limited that I use it at work to transfer literally thousands of xml and binary files every single day.
          • Oh, I use it on my production code too; look at the 'when web services go bad' paper off my home page.

            It is just more limited than SOAP. Maybe that is a good thing -like you say, it works, and it doesnt have SOAP interop grief.

    • Re:SOAP ain't so 'S'imple no mo (Score:5, Funny)

      by gnovos ( 447128 ) <gnovos@ c h i p p e d . net> on Wednesday April 03, 2002 @01:18AM (#3275221) Homepage Journal
      XML RPC is simple - it has a 4 page specification. SOAP is, well, not so simple. SOAP started out simple, but then committees got a hold of it. Try reading the specification - it's well over 100 pages long - and all legaleeze.

      The "Simple" in SOAP is like the Green in Greenland... it's there to keep the non-Vikings out... Look for Complex Hyperbolic Interface Protocol, that'll be the one that M$ ACTUALLY uses...

    • A better SOAP tutorial than IBM article... (Score:1, Informative)

      by Anonymous Coward
      A Busy Developer's Guide to SOAP 1.1 [soapware.org]
    • XML RPC is simple - it has a 4 page specification. SOAP is, well, not so simple.

      About 18 months ago I submitted two specifications that were at the time both ten pages to two different standards organizations. They are both 60 pages now and have spawned numerous sub-specifications.

      XML RPC only addresses a part of the space addressed by SOAP and not the most interesting part either.

      I have read that Don Box himself is questioning the SOAP protocol, or at the very least the HTTP transport it is coupled with

      Not suprising since one of the other main authors on SOAP was also an author of HTTP and spent several years working on HTTP-NG.

      The problem with improved transport protocols is that the time taken to negotiate the upgrade to the new protocol obviates any advantage you can gain. I suspect that Marshal Rose is going to find the same problem with BEEP, althought the current plot appears to be force folk to layer SACRED over BEEP to get BEEP adoption, which I suspect is more likely to kill SACRED. And if you dislike XML bloat you are going to hate BEEP.

      Anyway enough yattering and on to write my XML Compression spec. The problem with the argument that the problems of XML bloat can be solved by compression is that nobody has produced a usefull compression scheme for XML. Lev Zimpel compression does not work well on the short messages used in SOAP and requires too much state to insert as a simple filter element. I think we can easily get to the point where XML encoding plus compression results in smaller messages than schemes like ASN.1.

    • intro [weblogs.com], guide [soapware.org], and more [weblogs.com].
    • Try reading the specification - it's well over 100 pages long - and all legaleeze.

      Not to mention: It relies intimately on several other specifications starting with X. For example, XML Schema--which is considerably longer!

  • [joke] From my nose's interaction with the Geek community, SOAP is not something that they often come in contact with. [/joke]
    • Dude, that makes no sense.

      Windows itself is a monopoly, then they used that monopoly to force acceptance of IE.

      KDE isn't a monopoly, so they can't force anyone to use Konq.

      What's your argument?
      • Dude, that makes no sense. Windows itself is a monopoly, then they used that monopoly to force acceptance of IE. KDE isn't a monopoly, so they can't force anyone to use Konq. What's your argument?

        Perhaps but if I wanna use KDE, why do I need Konq?

  • Blobs (Score:5, Informative)

    by igrek ( 127205 ) on Wednesday April 03, 2002 @01:18AM (#3275222)
    There's one potential problem with SOAP - sending binary objects. You can't insert binary in XML, so the options are:
    - encode binary to 7-bit (hex, etc.) or
    - send it "outside" of the XML, as MIME attachment
    The acticle mentions these.

    However, there's one more way to do it - the new DIME protocol. It's explained in this article:
    DIME: Sending Binary Data with Your SOAP Messages [microsoft.com]

    • Re:Blobs (Score:2, Funny)

      by soap.xml ( 469053 )
      <root>
      <element><![CDATA[ BINARY DATA HERE BASE 64 ENCODED ]]></element>
      </root>

      your blob has been placed in an xml document. next.
      • ...and the size increased by about 33% ?
        Unsatisfactory. Next.

        • True, but your original post stated... "You can't insert binary in XML, so the options are"

          You can insert it, it might not be practicle, but it can be done.

          -ryan
          • you forgot the next line of the quote, which was converting to 7bit. Your post is redundant, but nevertheless a good example of his first solution for those that didnt catch it, like yourself.
        • The size has already been increased by 100% by using XML elements intead of a more compact protocol, so size really doesn't seem to be an issue for you anyway. Why does a pithy 33% increase in the size of binary data matter, when all the fluff surrounding the data doesn't?
          • Because sometimes XML/SOAP overhead is negligible comparing to size of binary.
            Hint: multimedia.
            • Sorry, you're going to need to be more explicit with your hints. Are you trying to pass a large but static multimedia object through XML-RPC? Okay, put it on a secondary HTTP server, and send a URL to the server, possibly with some authentication or session information.

              Are you trying to stream dynamic multimedia data, i.e a live feed? Then you'd best start thinking about implementing a custom protocol, because neither SOAP nor XML-RPC are going to serve you well for that.
              • Yes, we're passing large static multimedia objects through SOAP. I'm not sure what do you mean by secondary server... We download and upload images/videos from client. No HTTP servers on client are possible, of course. And SOAP with MIME attachments works fine just for us. But DIME would be better; too bad it's not supported by Apache group yet.
        • Bwahahaha. This is really not the time or the place for the XML junkies to start getting fussy over bloat.
      • If you base-64 encode it, you don't need to wrap it in a CDATA block. It can be an ordinary text node.

      • Re:Blobs (Score:4, Insightful)

        by Citizen of Earth ( 569446 ) on Wednesday April 03, 2002 @08:28AM (#3276163)
        <![CDATA[ BINARY DATA HERE BASE 64 ENCODED ]>

        They should include an additional escape mechanism to solve this problem directly, like (to borrow the horrid CDATA syntax):

        <![BDATA[10 xxxxxxxxxx]]>

        where the "BDATA" means "Binary Data", and the "10" is the number of binary bytes in ascii decimal followed by a single space followed by the indicated number of bytes of raw binary.

        Honestly, what kind of rabid theoreticians designed XML anyway and didn't include a mechanism for raw binary? Were they thinking that people would encode images like:

        <img:image>
        <img:row>
        <img:pixel>
        <img:red>0xFF</img:red>
        <img:green>0xFF</img:green>
        <img:blue>0xFF</img:blue>
        <img:opacity>0xFF</img:opacity>
        </img:pixel>
        ...
        </img:row>
        </img:image>

        Of course, with XML you also face an enormous lexical-scanning cost. One can easily derive a fully-interoperable totally-equivalent binary encoding for XML; perhaps one day people will realize that it's not efficient to pass everything around in text. Imagine spending all day parsing a big array of real numbers encoded in text rather than slurp/swapping raw 8-byte IEEE doubles.

        • I would say that if the purpose of xml was to transport binary data then yes, there should be a way to do it. However XML is simply a markup language. It's primary purpose was text, and text alone. Take a look at the DTD spec, there isn't support for strong datatypes or anything. XML schema has fixed alot of that, but IMHO XML is being used for quite a bit more than it was originally intended for.

          One thing that it is just simply not good at is transfering binary data, or data that can simply go into a csv (rows from a database for example...). The overhead of XML can absolutly kill you on the speed side, but it is very cool when it come to structured data. XML has its strong points and its week points... Binary data is not one of the strong points ;)

          -ryan
    • CDATA sections allow it. however you'll need to break your binary data up into several cdata sections that don't contain the CDATA ending character sequence.

      xml is meant for structured data where you don't give a damn about speed. sending large chunks of binary data? use a real, binary safe length delimited encoding.

  • Redundant Post xml-rpc is by far better (Score:4, Interesting)

    by codepunk ( 167897 ) on Wednesday April 03, 2002 @01:28AM (#3275251)
    SOAP is nothing more than a poorly designed and implemented version of xml-rpc. Try getting two soap services talking together one time. Interop does not exist in the SOAP world. Take a look at xml-rpc for some lib's that work (without the hype).

    Let's see 2 page spec vs 200, come on people wake up!

    • Let's see 2 page spec vs 200, come on people wake up!
      Bloated, over-engineered specs are typical of the W3C because the committees are often dominated by the big players (Microsoft, Oracle, Sun, etc.) and it's in their best interest to make standards so big and complex that only companies having their scale of resources will be able to produce compliant implementations thus shutting out the little players.
    • Except for the fact that the xml-rpc spec is dependent on HTTP. And that Strings can only be US-ASCII. Get rid of those two problems and it's great.

    • SOAP is nothing more than a poorly designed and implemented version of xml-rpc.

      I've read this complaint elsewhere and see it reiterated in several postings here: XML-RPC is a nice short small specification and SOAP is a big bloated specification that represents the union of the concerns of every member of a large committee.

      So my questions is this:

      Is there anyway that I can layer SOAP over XML-RPC and layer XML-RPC over SOAP so that if I go the route of doing XML-RPC I can always be assured of playing well with others?

  • Bloated RPC (Score:1, Troll)

    by Animats ( 122034 )
    This is the second most bloated RPC protocol I've ever seen. (Apple's Interapplication Communication [apple.com], circa 1996, was worse.)

    All this because Microsoft hates Java RMI and Sun RPC. It's not like we really we need this turkey.

    • The author appears to be unaware of DCE RPC, of which MS have a cheap, though somewhat buggy*, implementation.

      DCOM is fab. COM is fab. DCE RPC is fab, though I wish they'd specified an endianism, instead of reader makes right.

      * the hand-coded stubs for the COM/Automation VARIANT type didn't interoperate properly with Bigendian machines, last time I checked. If you're not using that, you'll likely be OK.
  • SOAP seems to be a useful tool for Personal Data Interchange via XML.

    There is a new forum at OpenContact.org [opencontact.org] for the discussion of contact management systems, with the goal of exploring options for integrating a centralized contact management database into the operating system; and to develop an extensive set of standard fields (akin to vCard or the obscure XML based SyncML) for universally compatible contact management. This would allow every third-party application on a computer to access the same contact data set, and eliminate the need to import and export contact data on a single system.

    If anyone in this thread can contribute some information about SOAP and its potential role in this initiative, please join the OpenContact.org forum [opencontact.org].

  • From the acticle... Software developers who want to dispense with Section 5's limitations can turn to schema-based serialization. This method works by publishing the interfaces of the SOAP service along with the schema(s) for the request/response messages. Web Services Definition Language (WSDL) is the current de facto standard for this purpose. Apache SOAP is not WSDL aware, but Axis (see Resources), Apache SOAP's successor toolkit, is.

    The lack of WSDL support in the apahce toolkit is a huge limitation of this toolkit if you wish to utilize remote web services. However the axis [apache.org] project at apache [apache.org] does look like it will provide a solution to this problem. Although the axis project is still in beta stages, it looks like it will be a killer implemetation once it matures. If you are planning on working with Java [sun.com] and SOAP in the future, then you really should take a look at axis. Beta, but worth it ;)

    -ryan

  • SOAP's popularity will be its problem (Score:5, Insightful)

    by conan_albrecht ( 446296 ) on Wednesday April 03, 2002 @01:48AM (#3275323)
    I just wrote an article on this. SOAP gets past firewalls because it *looks* like web traffic (at least, HTTP traffic). That's great because most firewalls let HTTP traffic on port 80 through.

    However, once admins realize that we programmers are sending our services (which are inherently a security issue) through port 80, they'll likely start filtering SOAP.

    One of the reasons that RMI and CORBA are firewalled is because they provide remote access to *objects* that might be powerful and that can certainly execute behavior within the trusted environment. SOAP does exactly the same thing, only it looks like HTTP traffic.

    Yes, SOAP can be detected very easily by firewalls. Therefore, I'm predicting that as it becomes popular, many admins won't let it through as easily as it gets through today.

    My $0.02.

    • Re:SOAP's popularity will be its problem (Score:1, Informative)

      by Anonymous Coward
      It doesn't just look like HTTP traffic, it is HTTP traffic. HTTP doesn't not equal web.

      HTTP = web
      HTTP = webdav [webdav.org]
      HTTP = SOAP too.

    • However, once admins realize that we programmers are sending our services (which are inherently a security issue) through port 80, they'll likely start filtering SOAP.
      But if they get in via port 80, then your servers are the ones providing the services because you told them to. This isn't very much different from a non-SOAP GET/POST request and a response.

  • OMG (Score:5, Funny)

    by zephc ( 225327 ) on Wednesday April 03, 2002 @02:39AM (#3275466)
    "XMI (XML Metadata Interchange) is an OMG standard for sharing UML models among applications"

    What about the OMFG ROFL standard?
  • Can someone point me to a good site that describes what SOAP is?
  • soap, shampoo and conditioner

    clean it..

    ah mean it, foo..

  • SOAP or BLOAT? (Score:2, Informative)

    by selectspec ( 74651 )
    Text encoding distributed object messaging and remote procedure calls, just so you can tunnel over HTTP is the stupidest thing I've ever heard of. If you sent the objects via carrier pigeon you could avoid the firewalls too!

    By the time I get a fat multi-megabit pipe out to my cabin in the woods, the internet will be saturated with this BLOAT, and I still won't be able to do much more than send email.
  • USE SOAP!

    (the above was brought to you humorously)

  • General Reply (Score:5, Informative)

    by awitod ( 453754 ) on Wednesday April 03, 2002 @12:16PM (#3277258)
    Hardly ever post here, but I know a thing or two about SOAP and thought you nice folks might find it informative.

    I've done three implementations for three different clients in the last two years. The first integrated an existing UNIX front-end with an existing NT back-end (I know... the real world sure is strange), the second enabled a COM+ app server to talk asynchronously to Apache on a Linux, and the third was a port of a windows forms app that used DCOM to SOAP for use in a VPN.

    I have to say that I am mostly pleased with SOAP, but that it does have areas that need improving.

    Reading this board, I've noted a couple of misconceptions that seem pretty prevalent.

    1. SOAP is not Simple. Several posters noted that the spec is over 100 pages long. Most of the specification is about the correct formatting of the description language on the server side. Fortunately, both Microsoft and IBM toolkits provide tools for generating this stuff and the tools cover 99.9% of what you will ever want to do. As a developer you can use SOAP without ever authoring a wsdl file. Reading the file is not very hard, I was able to write my first working SOAP client implementation within a week of starting. All you need is a good understanding of the HTTP protocol, XML, and your client platform.

    2. SOAP is bloated. Many people (including me) think this when they first see an example of a web service description language (wsdl) file. The key thing to note is that a decently designed client only needs to read it once (using http GET) to understand the service. The actual requests (using http PUT) and responses don't have too much adornment and are pretty darn simple. The server will use the wsdl to validate incoming requests and if it has a decent design, it too only read it once on the service startup.

    3. XML-RPC is better because it is simpler. XML-RPC is actually very, very similar to the rpc aspect of SOAP. But going back to 1. above the spec is so short because XML-RPC lacks an equivalent to wsdl (a runtime readable description of the service). In other words, XML-RPC requires you to understand the interface at design time. Because of this an XML-RPC solution is more tightly coupled and less flexible than an equivalent SOAP implementation. (This might be acceptable depending on the requirements).

    4. Running over port 80 is bad. In fact, it can be. However SOAP requests are generally speaking, HTTP POST, so this has less to do with the standard than the reliability and security of the listener. A good listener will act as an application proxy and reject any shenanigans. A good network design that includes a DMZ with another firewall between the private network and the server is also required for it to be secure. Message level security can use SSL or an alternative.

    5. It isn't standard between vendors. Some validity to this, but I found the differences between M$ and IBM to be very minor and easy to accommodate.

    There are some problems with running over HTTP though.
    1. It is never as fast as native rpc solutions in my experience. You can cut down on the size of the response by using gzip or deflate with http 1.1, but there is no facility for compression on the inbound side. The need to minimize round trips is directly at odds with this lack of functionality because:

    2. It is stateless so things like transactions are very difficult to do and cause the requests to contain enough info for the server to do something ACID... These accentuates problem number 1.

    3. You can't do call backs or event from the server to the client. This is strictly a 'you request and I respond' protocol. You can't push from the server to the client with SOAP.

    Hope you found this informative.
    • 1. It is never as fast as native rpc solutions in my experience. You can cut down on the size of the response by using gzip or deflate with http 1.1, but there is no facility for compression on the inbound side. The need to minimize round trips is directly at odds with this lack of functionality because:

      ***

      If you look at the contents of a simple SOAP request, it's over 1k!

      I don't see why people didn't choose CORBA as a web service protocol. It's supported by multiple vendors on many platforms, is easy to program in, and has a ton more userful features. The Simple Object Access Protocol doesn't even have support for remote object references. Blah!
    • But going back to 1. above the spec is so short because XML-RPC lacks an equivalent to wsdl (a runtime readable description of the service). In other words, XML-RPC requires you to understand the interface at design time. Because of this an XML-RPC solution is more tightly coupled and less flexible than an equivalent SOAP implementation.

      This doesn't make a lot of sense to me. How can software automatically "understand" an interface? Claiming that some declarative language can define the semantics of an interface seems equivalent to claiming to be able to solve the halting problem. And without understanding semantics, how can an application make effective use of any non-trivial interface? The notion of "self-describing" interfaces sounds a lot like fantasy. Any actual intelligence must be pre-programmed into the application, according to some pre-published human-understandable specification.

      Lots of XML fanboys also like to wank off about validation, but outside of debugging, what is really the point? It's a low-utility activity. Syntax != Semantics, and a syntactic description is all that whiz-bang gives you.
      • Well, I said it is more flexible, not that it is miraculous. It just provides a nice layer of abstraction in a way similar to, but different from, a data dictionary in an RDBMS. Here are a couple of practical things you can do with it...

        1. Provide location transparency. A wsdl file contains an address for the endpoint. You can leave the location of the description in one spot and move the endpoint any time you want in a way that is transparent to the clients of the service.

        2. A clean means of extension through ports. A wsdl file describes the methods available and their locations. Ports give you a clean way of managing name conflicts between names in different endpoints. This is nice if you want to add a new object to your service with what would otherwise be a conflicting name in a way that doesn't disturb existing clients. (and without having to create a new web-site).

        3. A way to conform to a standard API that allows different levels of support. Imagine an insurance API that supports the full range of insurance-type activities. You want to implement it, but you only support 80% of it. Clients can use the service and understand that you only support 80% by reading the description instead of by trying unsuccessfully to call the other 20%.

      • In most real-world apps, semantics aren't much
        of an issue, because the peers, their interfaces
        and collaborations, are domain-constrained. You
        really can automatically understand interfaces
        because your peer set consists only of agents which
        share a limited universe of discourse.

        We're not really talking semantics here. It's
        more, to continue using the metaphors of natural
        language linguistics, an issue of pragmatics.
        in the middle-ground between purely formal
        syntactic manipulation and symbol-grounding-chinese-room-paradoxical-scott-st rachey-playland
        semantics.
        We play in blocks worlds. Bridging the impedance
        mismatch between different blocks worlds is not
        so hard as all that.

        "fanboys". Your arguments work better without
        such glaring ad hominems. Syntactic descriptions
        are plenty for most purposes. In fact, unless
        you solve symbol-grounding, they're the only
        game in town, so your complaint is rather like
        complaining that XML only works with finite-state
        automata. Until you show me where I can buy
        a Turing 10000, I think FSAs will have to suffice.

  • It looks interesting...

    MIME-RPC [http://www.mimerpc.com] is a protocol for applications written in different languages and on different platforms to communicate with each other using a public standards.
    It works with the millions of already deployed web apps and web browsers (without plugins) It handles all Internet data including Unicode, JPEG, XML, etc.
    It works over both HTTP and SMTP (web and email)
    It protects application programmers from wire level concerns.
    It provides complete interlanguage object serialization (cyclic refs.) as well as interlanguage messaging
    It supports two way communication over client/server connections
    It is easy to implement.
    It doesn't require an extra XML parser when your application doesn't need one.
    Its specification is short and unambiguous.
    It leverages existing transport layer features like encryption, proxying, asynchrony, streaming/chunking, etc.

Slashdot Top Deals

"The four building blocks of the universe are fire, water, gravel and vinyl." -- Dave Barry

Close