Posted by
Hemos
on 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."
147 comments
A nice SOAP client/server can be found:
by
Macaw2000
·
· Score: 4, Informative
I like foobar, I have a book for a software engineering class that constantly uses examples that have nothing to do with software whatsoever - my favorite is about building a house - "well great, if I ever need to build a house I'm all set, now about that software thingie?"
Physical real world examples tend to help in teaching theory in a lot of different fields.
Lord Knows there have been tons of things from a large variety of different areas of mathmatics that I didn't understand until it was related to me in terms of 2x4s.:)
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:
by
Gis_Sat_Hack
·
· Score: 5, Interesting
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.
Ummm, I've been in the office for like 16 hours and reading is hard and stuff. Could someone please provide me with like 100 words or less or something?
Re:Substantial
by
Anonymous Coward
·
· Score: 3, Informative
Ummm, I've been in the office for like 16 hours and reading is hard and stuff. Could someone please provide me with like 100 words or less or something
Reader's Digest version: SOAP lets you call remote procedures over HTTP (for better or for worse). It has binding for many languages. It is an ASCII protocol, and is fairly verbose.
Re:Let an editor handle this one-native soap.
by
Anonymous Coward
·
· Score: 0
Apache SOAP, sold with some reservation.
SOAP ain't so 'S'imple no mo
by
Anonymous Coward
·
· Score: 4, Informative
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
by
Anonymous Coward
·
· Score: 2, Informative
XMLRPC bindings exist for Perl, Python, Java, Frontier, C/C++, Lisp, PHP, Microsoft.NET, Rebol, Real Basic, Tcl, Delphi, WebObjects and Zope.
Re:SOAP ain't so 'S'imple no mo
by
steve_l
·
· Score: 1
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.
Re:SOAP ain't so 'S'imple no mo
by
gnovos
·
· Score: 5, Funny
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...
-- "Your superior intellect is no match for our puny weapons!"
Re:SOAP ain't so 'S'imple no mo
by
Anonymous Coward
·
· Score: 0
>
Surely we all can find a compromise between the simplicity of XML RPC and the robustness of SOAP.
Why can't XMLRPC be fully robust?
My naive analysis is: (1) XMLRPC is used to express RPC interfaces; and (2) an interface is exactly as robust as the code that implements it.
How can SOAP be more robust? Does it do auto-retry on transport errors, or something like that?
Re:SOAP ain't so 'S'imple no mo
by
codepunk
·
· Score: 1
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.
--
Got Code?
Re:SOAP ain't so 'S'imple no mo
by
Anonymous Coward
·
· Score: 0
How can [XMLRPC] be more robust?
XMLRPC does not provide a standard method of determining meta-data (i.e., how to query the remote interface?)
XMLRPC does not provide for interface versioning.
XMLRPC does not have the concept of a handle (or object reference, if you will)
Re:SOAP ain't so 'S'imple no mo
by
Anonymous Coward
·
· Score: 0
Re:SOAP ain't so 'S'imple no mo
by
Zeinfeld
·
· Score: 2
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.
--
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/
Re:SOAP ain't so 'S'imple no mo
by
deander2
·
· Score: 2
Actually, the Green in Greenland was put there to ENCOURAGE people to move and live there, not to keep them out.
Could this have been the worlds first marketing department?:-)
Re:SOAP ain't so 'S'imple no mo
by
Anonymous Coward
·
· Score: 0
How can [XMLRPC] be more robust? XMLRPC does not provide a standard method of determining meta-data (i.e., how to query the remote interface?)XMLRPC does not provide for interface versioning.XMLRPC does not have the concept of a handle (or object reference, if you will)
Thanks for the response. I guess I have a little more narrow definition of "robust" than you.
To me, your points look like a list of optional features, which may or may not be useful for any particular application.
I guess I don't usually think of optional features as contributing to "robustness" -- but that could just be due to a quirk in the way I comprehend the word "robust".
All 3 of your points are features that I could just implement myself in XMLRPC if I needed them. And eventually, I'm guessing that those features will get proposed and standardized within the XMLRPC framework.
Re:SOAP ain't so 'S'imple no mo
by
Anonymous Coward
·
· Score: 0
Actually, I believe MS is planning to use Supercomplex Hyperbolic Interface Technology
Re:SOAP ain't so 'S'imple no mo
by
steve_l
·
· Score: 1
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
by
The+Pim
·
· Score: 2
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!
--
The evaluation of an action as 'practical' . . . depends on what it is that one wishes to practice.
Re:Don't forget about...
by
Anonymous Coward
·
· Score: 0
"If IE's Windows integration is a monopoly, then I'm all for the removal of Konqueror from KDE."
You got the code sonny boy, rip it right out yourself.
Re:Don't forget about...
by
jonnythan
·
· Score: 2
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?
Re:Don't forget about...
by
Anonymous Coward
·
· Score: 0
cscx isn't interested in logical arguments. Apparently, he just likes to get attention by saying ridiculous things. Don't waste your breath trying to explain difficult concepts like "monopolies" to him.
Or, just have fun making fun of him.
Re:Don't forget about...
by
/dev/trash
·
· Score: 1
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?
TOP SECRET NATIONAL SECURITY FILES ABOUT ALIENS!
by
Anonymous Coward
·
· Score: 0, Troll
Classified intelligence secrets about the CIA and NSA and alien Greys at : www.fastaxs.com
Post and repost this URL in every open forum. Backup and place this data online - it will be covered up quick!!
How many read this as Sterilization?
by
Anonymous Coward
·
· Score: 0, Funny
Bring on true RPC, baby!
I'm glad at least Apache has the sense to embrace SOAP.
I wish those dirty GNU hippies would.
Re:Bruce Schneier has said:
by
steve_l
·
· Score: 5, Informative
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.
SOAP???
by
Anonymous Coward
·
· Score: 0
What if Microsoft pulls an embrace-and-extend on this one? Will all copies of Apache stop working? And if you really want to use an MS-sponsored standard, why not run IIS? I mean have your web site on a Linux/Apache box, and SOAP on an IIS box (behind a firewall, of course).
Personally, SOAP reminds me too much of Product Activation(tm)...
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.
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?
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:
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;)
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.
Redundant Post xml-rpc is by far better
by
codepunk
·
· Score: 4, Interesting
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!
--
Got Code?
Re:Redundant Post xml-rpc is by far better
by
pauljlucas
·
· Score: 2, Insightful
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.
-- If you reply, do so only to what I explicitly wrote. If I didn't write it, don't assume or infer it.
Re:Redundant Post xml-rpc is by far better
by
Anonymous Coward
·
· Score: 0
http://www.xmlrpc.com/
It doesn't hurt my eyes, or my brain nearly as much. Alot of this SOAP stuff seems straight forward, and I can see why I would want to deal with some of my big mod_perl handlers with something better than extra headers. But I don't really get why I care that SOAP can get Java to talk to Java if doing that over HTTP is so important, I must be missing something. Are SOAP people playing like HTTP a standard so any crap we push though it is as well?
Re:Redundant Post xml-rpc is by far better
by
CoreyG
·
· Score: 2
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.
Re:Redundant Post xml-rpc is by far better
by
4of12
·
· Score: 2
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?
-- "Provided by the management for your protection."
Re:Bruce Schneier has said:
by
Caspuh
·
· Score: 0, Flamebait
Hey retard, you can run any service on any port. Now go away.
Re:Bruce Schneier has said:
by
PowerTool
·
· Score: 1
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.
Corba isn't dead. It is being used a lot inside large corporations (I know the two biggest banks in the world use it extensively; I work in one of them).
For internet use, Corba-over-HTTP(S) might be a good idea. After all, Corba was designed to be used over any transport layer. Corba is an API spec, not a transport spec (that is IIOP, but you can well use Corba without IIOP).
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.
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.
--
Got Code?
Re:My PIX
by
Anonymous Coward
·
· Score: 0
two way tunnels initiated inside the firewall can punch thru your PIX like it didnt exist. and if you have stateful inspection in your pix SSL'ed SOAP should punch thru it easy. both ways.
Open Standard for Contact Management
by
wlevin
·
· Score: 2
SOAP seems to be a useful tool for Personal Data Interchange via XML.
There is a new forum at 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.
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 project at apache 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 and SOAP in the future, then you really should take a look at axis. Beta, but worth it;)
-ryan
And the Lord Saith...
by
leviramsey
·
· Score: 0, Offtopic
...In Goatseciah 6:9 "Do not click on the popups, for they are the spawn of Satan!"
dumbass
by
Anonymous Coward
·
· Score: 0
Um, that IS the first option : "encode binary to 7-bit (hex, etc.)".
Try reading the post next time.
Next.
Re:dumbass
by
Anonymous Coward
·
· Score: 0
Technically, base-64 would be 6 bits. The encoding uses the 7th bit only to shift the six-bit area to someplace where all the values are usable.
So that's not *exactly* what was said.
Ok you can hit me now. Oh wait, you can't.:D
Marketroids reading slashdot
by
Anonymous Coward
·
· Score: 0
Yes we do. (And *BSD is dying)
Re:TOP SECRET NATIONAL SECURITY FILES ABOUT ALIENS
by
Com2Kid
·
· Score: 1
wow, you linked to a none working domain name, don't you feel proud?
Yeesh.
The trolls are getting worse and worse around here.:(:(:(
SOAP's popularity will be its problem
by
conan_albrecht
·
· Score: 5, Insightful
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
by
codepunk
·
· Score: 0, Troll
Yes and it is fools passing around FUD that will cause the problems. Tell me please how it is any more insecure than someone downloading a exe off of a web server somewhere and executing it? Hell I will even go so far as to say that and ftp are far more dangerous. How many shops use Outlook? running outlook you might as well have screw my box tatoo'd on your forehead. And please tell me how someone is going to do a http post to a client behind my firewall, yea right.
--
Got Code?
Re:SOAP's popularity will be its problem
by
Anonymous Coward
·
· Score: 1, Informative
It doesn't just look like HTTP traffic, it is HTTP traffic. HTTP doesn't not equal web.
Re:SOAP's popularity will be its problem
by
pauljlucas
·
· Score: 2, Insightful
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.
-- If you reply, do so only to what I explicitly wrote. If I didn't write it, don't assume or infer it.
Re:SOAP's popularity will be its problem
by
Anonymous Coward
·
· Score: 0
Any modern corporate firewall/filter already blocks.exes...
Re:TOP SECRET NATIONAL SECURITY FILES ABOUT ALIENS
by
Com2Kid
·
· Score: 1
On a related note, the google cache of their main page
"American intelligence, the U.N and the E.U can transmit approximately 4 implants with particle transmission. They can pick up.41 millimeters of a dime (a shaving) and beam it anywhere in the world. "
Which makes absolutly no sense since he gives no rate (uh, 4 implants a day, a second, a minute, an hour? Yeesh).
Oh well, seems like a joke page, rather old, is dead.
Re:yes you "can" but its silly
by
Splork
·
· Score: 2
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.
WHY THE FUCK IS THIS ON THE FRONT PAGE?
by
Anonymous Coward
·
· Score: 0
WHY the FUCK is this ON THE FRONT PAGE?
Re:WHY THE FUCK IS THIS ON THE FRONT PAGE?
by
Anonymous Coward
·
· Score: 0
Because Mr. Hemos' journalistic integrity is about as real as his high school diploma.
This can't be real
by
Anonymous Coward
·
· Score: 0
Gavin Bong is a Java developer from Kuala Lumpur, Malaysia. His areas of interest include service-oriented architectures and wireless Java. You can contact Gavin at gavinb@eutama.com. He would like to thank Ying Pee Eng for her help on polishing up Figure 1.
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, httptunnel 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 ?
-- 3.243F6A8885A308D313
A better SOAP tutorial than IBM article...
by
Anonymous Coward
·
· Score: 1, Informative
"XMI (XML Metadata Interchange) is an OMG standard for sharing UML models among applications"
What about the OMFG ROFL standard?
--
"I would say that 99 per cent of what my father has written about his own life is false." - L. Ron Hubbard Jr.
Re:Bruce Schneier has said:
by
microTodd
·
· Score: 4, Insightful
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?
-- "You cannot find out which view is the right one by science in the ordinary sense." - C.S. Lewis on Intelligent Design
Tonight's Episode sucked a Donkey Cock
by
Voyager+Sucks+Ass
·
· Score: 0, Offtopic
Meld
60 min. When Tuvok uses a Vulcan mind meld on a suspect (Brad Dourif) in a murder investigation, the man's psychotic behavior becomes imprinted on Tuvok.
What a steaming pile of Hannibal-Lechter-wannabe-shit.
Voyager sucks ass.
Re:Bruce Schneier has said:
by
mmusn
·
· Score: 5, Informative
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.
It could be worse... CORBA
by
Anonymous Coward
·
· Score: 0
I think some of the most interesting things that have been written about SOAP have come out of the REST thesis, probably the best two introductory articles on REST and the ones on XML.com by Paul Prescod; Second Generation Web Services and REST and the Real World.
you wash yourself with it, fool. it has 100% xml goodness, and no sodium hydroxide to burn your skin, so its all good.
Re:WTF is SOAP?
by
Anonymous Coward
·
· Score: 0
You must be one of those open source programmers... try this
Re:yes you "can" but its silly
by
Matts
·
· Score: 4, Informative
Actually no, CDATA sections don't win you anything beyond not having to escape the < and & characters. You still can't send non-character data within a CDATA section, such as \0, FF, or BEL bytes.
Corba over HTTP(S)?
by
Baki
·
· Score: 4, Insightful
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:Corba over HTTP(S)?
by
Anonymous Coward
·
· Score: 0
>What's wrong with Corba?
Corba is DEAD!
Re:Corba over HTTP(S)?
by
Anonymous Coward
·
· Score: 0
CORBA is brittle, whereas XML/SOAP is flexible. CORBA interfaces are difficult to extend, and virtually impossible to debug if client and server do not have matching IDL (symptom: program crashes, or continues working but with wrong data). And don't start about interface inheritance - it's a nightmare to use for more than a single addition (image 5 ot 6 additions over the course of a few months). Just say 'no' to CORBA.
symptom: program crashes, or continues working but with wrong data
maybe yours, but if the IDL differs you should get marshalling exceptions.
And don't start about interface inheritance - it's a nightmare to use for more than a single addition (image 5 ot 6 additions over the course of a few months)
you should prefer composition over inheritance anytime. Deep inheritance hierarchies usually signal bad design.
Just say 'no' to CORBA.
I say just say 'no' to speaking without thinking.
CORBA may not be the right tool for the types of tasks that SOAP tries to resolve; SOAP may not be the right tool for some tasks where CORBA shines.
The two overlap in their capabilities and each has strengths and weaknesses. I guess it's up to the discerning architect to decide what should be used. Sadly enough, people with decision power today are too buzzword-driven to be discerning.
Re:Corba over HTTP(S)?
by
Anonymous Coward
·
· Score: 0
CORBA is not dead, vendors just want it to be dead so that they can force their proprietary designs on the population. I'm dealing with CORBA in helathcare (PIDS), the vendors have forced the secure ORB (RAD) out of the picture because it used specifications that were deemed un-implementable by ignorant (the most of them) vendors. Vendors are the reason CORBA is dieing, stupid self-centered vendors.. SOAP is supported by stupid self-centered vendors that don't know the purpose of the word "standard". But defacto standards are not the answer.. Why do you think Microsoft made SOAP (to distract people from standards general industry processes, it seems nobody wants to standardize things like healthcare informatics [which is the priciple reason why healthcare is denied so many, lack of information about drugs, if information was more widely distributable {without a vendor at every network node eager to make 40K off a custom implementation connecting two proprietary or bloated interfaces - which is quite common} then the money wasted on such "means to an end" could be eliminated and used toward helping people and helping distribute much needed information to doctors which are searching for solutions. Otherwise studies have to be performed, which take years to do, and everyone suffers (read dies).. Do you want to really wait 10 years to find out you have drug resistant tuberculosis due to the fact that no hospital can communicate to no other hospital, thus drug therapies can only be tracked on paper records.. ..]).
Hmm I guess CORBA is dead, and us with it..
Re:Bruce Schneier has said:
by
lseltzer
·
· Score: 2, Informative
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, 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, 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, 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"
So if the dirty hippies use SOAP...
by
bubbha
·
· Score: 1
...guess they would be clean hippies....
-- I want to be alone with the sandwich
Re:Bruce Schneier has said:
by
Zeinfeld
·
· Score: 4, Insightful
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.
--
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/
SOAP or BLOAT?
by
selectspec
·
· Score: 2, Informative
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.
--
Someone you trust is one of us.
Re:SOAP or BLOAT?
by
Anonymous Coward
·
· Score: 0
Text encoding is how the Internet started, and how it should proceed, IMO. The natural-language aspect of text encoding is extremely useful.
Simple specs for a simple protocol
by
Sam+Ruby
·
· Score: 1
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.
Re:General Reply
by
Anonymous Coward
·
· Score: 0
What the hell is wrong with Slashdot? This is the best post I have seen, the most even, the most knowlegable and it gets a 1. Great going./
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.
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.
Re:Bruce Schneier has said:
by
gorilla
·
· Score: 2
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.
Re:Bruce Schneier has said:
by
Zeinfeld
·
· Score: 2
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.
--
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/
Re:Bruce Schneier has said:
by
steve_l
·
· Score: 2, Interesting
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
Re:yes you "can" but its silly
by
Splork
·
· Score: 2
*sigh* yes again, then i misinterpreted the xml spec. that means xml is absolutely useless for including large chunks of binary data.
Re:Bruce Schneier has said:
by
Ed+Avis
·
· Score: 2
It's not security avoidance, it's stupidity avoidance. RFC 3093 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.
-- --
Ed Avis
ed@membled.com
Fun with learning SOAP
by
Anonymous Coward
·
· Score: 0
Have you guys checked this site ? Dream Warrior Challenge
Fun way of learning Webservices...
cheers,
Srini
Slashdot Mirror
here.
Is anyone else tired of the old FooBar code examples?
I'm reading a book that is teaching objects with Cows, Pigs and Sheep. How about some real world examples.
What's with that?
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.
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.
- 0202.html
source:
http://www.counterpane.com/crypto-gram
Ummm, I've been in the office for like 16 hours and reading is hard and stuff. Could someone please provide me with like 100 words or less or something?
Apache SOAP, sold with some reservation.
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.
[joke] From my nose's interaction with the Geek community, SOAP is not something that they often come in contact with. [/joke]
SOAP on a ROPE!!
Classified intelligence secrets about the CIA and NSA and alien Greys at : www.fastaxs.com Post and repost this URL in every open forum. Backup and place this data online - it will be covered up quick!!
Bring on true RPC, baby!
I'm glad at least Apache has the sense to embrace SOAP.
I wish those dirty GNU hippies would.
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.
What if Microsoft pulls an embrace-and-extend on this one? Will all copies of Apache stop working? And if you really want to use an MS-sponsored standard, why not run IIS? I mean have your web site on a Linux/Apache box, and SOAP on an IIS box (behind a firewall, of course).
Personally, SOAP reminds me too much of Product Activation(tm)...
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
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!
Got Code?
Hey retard, you can run any service on any port. Now go away.
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.
SOAP is not tied to HTTP, just most of the examples are.
Blar.
All this because Microsoft hates Java RMI and Sun RPC. It's not like we really we need this turkey.
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.
Got Code?
There is a new forum at 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.
--
http://www.macboy.com
Cartoons for Mac Geeks
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 project at apache 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 and SOAP in the future, then you really should take a look at axis. Beta, but worth it ;)
-ryan...In Goatseciah 6:9 "Do not click on the popups, for they are the spawn of Satan!"
Um, that IS the first option : "encode binary to 7-bit (hex, etc.)".
Try reading the post next time.
Next.
Yes we do. (And *BSD is dying)
wow, you linked to a none working domain name, don't you feel proud?
:( :( :(
Yeesh.
The trolls are getting worse and worse around here.
Need help treating your acne? Come here!
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.
On a related note, the google cache of their main page
E C: www.fastaxs.com/ufop.exist.html+&hl=en
:)
.41 millimeters of a dime (a shaving) and beam it anywhere in the world.
:)
http://216.239.39.100/search?q=cache:KX_5ifyYLs
is rather hilarious to read.
"American intelligence, the U.N and the E.U can transmit approximately 4 implants with particle transmission. They can pick up
"
Which makes absolutly no sense since he gives no rate (uh, 4 implants a day, a second, a minute, an hour? Yeesh).
Oh well, seems like a joke page, rather old, is dead.
I hope its a joke.
^_^
Need help treating your acne? Come here!
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.
WHY the FUCK is this ON THE FRONT PAGE?
Gavin Bong is a Java developer from Kuala Lumpur, Malaysia. His areas of interest include service-oriented architectures and wireless Java. You can contact Gavin at gavinb@eutama.com. He would like to thank Ying Pee Eng for her help on polishing up Figure 1.
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, httptunnel and anything else that will get you closer to the goal.
.. err .. may get interpreted incorrectly by less experienced members of comp.sci society, but .. hey! .. you can misuse almost everything.
... 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 ?
I agree that positioning SOAP as firewall-transparent protocol is
.. and (not re: your post, but a thread head) XML-based marshalling ? Give me a break
3.243F6A8885A308D313
A Busy Developer's Guide to SOAP 1.1
If you reply, do so only to what I explicitly wrote. If I didn't write it, don't assume or infer it.
"XMI (XML Metadata Interchange) is an OMG standard for sharing UML models among applications"
What about the OMFG ROFL standard?
"I would say that 99 per cent of what my father has written about his own life is false." - L. Ron Hubbard Jr.
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?
"You cannot find out which view is the right one by science in the ordinary sense." - C.S. Lewis on Intelligent Design
Meld
60 min.
When Tuvok uses a Vulcan mind meld on a suspect (Brad Dourif) in a murder investigation, the man's psychotic behavior becomes imprinted on Tuvok.
What a steaming pile of Hannibal-Lechter-wannabe-shit.
Voyager sucks ass.
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.
What an insanely complicated mess CORBA is!
Can someone point me to a good site that describes what SOAP is?
Tim Smith - Ramblings from Nerd Land
Actually no, CDATA sections don't win you anything beyond not having to escape the < and & characters. You still can't send non-character data within a CDATA section, such as \0, FF, or BEL bytes.
Matt. Want XML + Apache + Stylesheets? Get AxKit.
soap, shampoo and conditioner
clean it..
ah mean it, foo..
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.
In this article, 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, 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, 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"
...guess they would be clean hippies....
I want to be alone with the sandwich
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.
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/
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.
Someone you trust is one of us.
intro, guide, and more.
- Sam Ruby
It was to keep people away from iceland. If greenland was the green one, how bad would iceland have to be?
USE SOAP!
(the above was brought to you humorously)
In the end they will lay their freedom at our feet and say to us, Make us your slaves, but feed us. - Fyodor Dostoyevsky
Hey Bill!
Would you get off the computer? We've got a meeting in 5 minutes!
Steve
*
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.
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 = Sarcasm
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.
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.
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/
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
*sigh* yes again, then i misinterpreted the xml spec. that means xml is absolutely useless for including large chunks of binary data.
It's not security avoidance, it's stupidity avoidance. RFC 3093 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.
-- Ed Avis ed@membled.com
Have you guys checked this site ? Dream Warrior Challenge Fun way of learning Webservices... cheers, Srini