With all the hoopla surrounding the Department of Justice's (DOJ's) proposal to break up Microsoft, I could easily have penned a long diatribe regarding the pros and cons of the proposal and my feelings about it. But a news story that I think was much more significant appeared and quickly disappeared.
In this column, I occasionally touch on XML. Because XML is so important to programmers, administrators need to keep a watchful eye on the technology and stay abreast of developments. A big development took place on April 26 when Microsoft, IBM, Lotus, and many other companies released version 1.1 of the Simple Object Access Protocol (SOAP).
SOAP provides the mechanism for passing data through XML-based messages in a distributed and decentralized environment among potentially dissimilar networks and OSs. SOAP messages, also called transactions, are usually one way, but the protocol is open enough to permit responses to the originator. SOAP transactions are built on XML, which itself gives structure to otherwise unstructured data types, such as business data. An XML message might look like this:
<FIND STOCKSYMBOL> <GET COMPANY NAME> </GET COMPANY NAME> </FIND STOCK SYMBOL>
This XML is simple SGML-looking psuedocode, right? The big missing piece is the transport or communications from client to server. Enter SOAP.
SOAP 1.1 lets you communicate using HTTP and FTP. That communication permits the use of a transaction, which can go from vendor to customer, from customer to supplier, or from parent company to subsidiary. Look for SOAP-based applications coming soon on your existing IIS or FTP server. I'm not necessarily promising that you'll implement version 1.1 on your server soon, but I expect you'll hear from your programmers that they want to try it out. E-commerce developers are leaping at the chance to develop for SOAP and XML, and the e-commerce industry depends on this happening.
How does programmers' interest in SOAP 1.1 affect IIS administrators? I'm a security nut, and I take pride in ensuring that the systems I manage are secure. The problem is, the only tools I have to secure those systems are the common tools anyone else has: firewalls, network sniffers, and intrusion-detection systems. These tools work at the packet level on the network. Stateful inspection lets me examine the label on every packet that enters my network. However, SOAP and XML transactions can take place entirely within HTTP or FTP traffic. I can't stop packets based on payload. For example, a malicious user could say
<PURCHASE CAR> <FIND MOST EXPENSIVE CAR> </ FIND MOST EXPENSIVE CAR> <CHANGE PRICE ON CAR> <!Come, on! It's okay, I'm the BOSS. Here are my credentials.> price=1.00 </CHANGE PRICE ON CAR> <TAKE CAR HOME> <!Thanks, been a pleasure doing business with you!> </TAKE CAR HOME> </PURCHASE CAR>
Get my point? The result is that application developers who use SOAP to develop e-commerce applications that connect to business-critical systems and processes have to put more effort into building security into their systems. I can use the conventional tools at my disposal to stop today's threats, but considering what might be coming, I can't help but be a bit nervous. Because security isn't part of the 1.1 specification, developers will have to be more responsible for following your existing security guidelines.
