One might think Id be delighted to report last weeks OASIS Standard acceptance of the Web Services Security specification set, including the much-needed SOAP Message Security 1.0. Previous absence of security from the Simple Object Access Protocol has been on my personal radar for almost four years. Because SOAP messages have the form of ordinary text, their insecure forms have been both difficult to block and easy to subvert.
The SOAP Message Security 1.0 specification offers “enhancements to SOAP messaging to provide message integrity and confidentiality” along with “a general-purpose mechanism for associating security tokens with message content.” The specification leaves open important options: “No specific type of security token is required, the specification is designed to be extensible (i.e., support multiple security token formats),” it says. “For example, a client might provide one format for proof of identity and provide another format for proof that they have a particular business certification.”
At eWEEK, we had previously expressed a hope that security would be integrated into the SOAP specification itself; well remain concerned about the add-on approach of last weeks announcement, with its potential for interoperability issues as briefly outlined on page 44 of the specification document thats hyperlinked above. This also raises, though, a more general issue: the growing number of rule sets that must be part of the working vocabulary of the IT professional.
An important part of that challenge is the vast and expanding application programming interface sets of platforms like .Net or J2EE. That challenge can be addressed by next-generation developer tools like Suns Java Studio family. I spoke last week with Ashwin Rao, Suns senior product manager for Java Studio Enterprise, who said that “a lot of work has gone into letting developers focus on the business logic.” Added Sun development manager Charles Beckham, “The appropriate integration with the enterprise components is totally automatic.” Ill be pushing hard on their new product during the coming week to see if it lives up to that billing, with the resulting review coming soon to eWEEK.
Beyond that, though, are the growing lists of rules that developers and IT architects need to know if their systems are going to meet expanding requirements of corporate governance. Data storage technologies used to compete on performance, reliability, capacity, and cost; as eWEEKs Henry Baltazar observed last fall, they now must also be weighed against their adequacy in the face of new rules from the Securities and Exchange Commission and other agencies.
Your record retention policies may not require the elaborations of a state department, but there may be industry-specific requirements that had better be known to someone.
The more different sets of rules there are, the more ways there are to overlook something—or to fail to appreciate an interaction or an inconsistency. Incorporating those rules into our tools reduces the chance of error, but may also result in worst-case designs that are expensive to build and cumbersome to use. The good news is its your choice. The bad news is the same.
Tell me what you think is being overlooked at peter_coffee@ziffdavis.com.