This article has some good content on what emerging technologies like SOAP may learn from past successes and failures, but it appears to be more commercially motivated than anything else. The usual suspects (complexity, bloated specs, lack of features, and Microsoft) are rounded up as conspiring to constrain CORBA's growth. Of course, the reality is that CORBA serves lots of mission critical functions today.
The lack of features section contains this:
CORBA provides quite rich functionality, but fails to provide(....):
Security. CORBA's unencrypted traffic is subject to eavesdropping and man-in-the-middle attacks, and it requires a port to be opened in the corporate firewall for each service. This conflicts with the reality of corporate security policies. (Incidentally, this shortcoming of CORBA was a major factor in the rise of SOAP. Not having to open a port in the corporate firewall and sending everything via port 80 was seen as a major advantage, despite the naïvete of that idea.) The OMG made several attempts at specifying security and firewall traversal for CORBA, but they were abandoned as a result of technical shortcomings and lack of interest from firewall vendors.
Now I am not a "let the network firewall solve all your app security problems" guy, but I am sure it will come as quite a surprise to pundits like Schneier ("SOAP is designed as firewall friendly protocol, this is like a skull friendly bullet"), et. al. that SOAP's ability to traverse firewalls is actually a boon for security. Schneier circa 2000:
That's right. Those pesky firewalls prevent applications from sending commands to each other, so SOAP lets vendors hide those commands as HTTP so the firewall won't notice.
Let's continue the DCOM example. So what if DCOM runs over a firewall?
DCOM is Microsoft's main protocol for inter-application communication. It's not just used by programs that are intended to be servers; it's used for all sorts of desktop communication and remote access. The result is that an average machine has dozens of programs using DCOM. Mine shows 48, ranging from "Microsoft PowerPoint Presentation" to "logagent" and including the catchily named "{000C101C-0000-0000-C000-000000000046}"; you may be able to list yours by bringing up a Command Prompt and typing "dcomcnfg".
Now, there are lots and lots of ways to secure DCOM applications, so maybe all of those applications are happily responding only to authenticated requests from the local machine. On the other hand, there are lots and lots of ways to make DCOM applications insecure, so maybe one of them is just waiting for somebody to send it an entirely unauthenticated request to overwrite selected files on my hard disk.
Firewalls have good reasons for blocking protocols like DCOM coming from untrusted sources. Protocols that sneak them through are not what's wanted.
SOAP was also not generally seen, at the time the ACM article refers to, as an improvement over DCOM and CORBA security, quite the opposite. So anyway, SOAP is not the death of distributed security either or even the death of firewalls, and I think WS-*, SAML, et. al. contain some valuable improvements for security but these nothing to do with firewalls, and I have not seen security as a reason for organizations moving to SOAP Web Services and away from CORBA. And in either case, the tricky bits like IAM and input validation remain.