Over the past 5 years or so, using webservices or SOAP as the underlying transport has been under discussion. At first, it was just a recurring thread that seemed to pop up in every face-to-face meeting and was quickly quelled. Now the concept has evolved to the point that there is a working group, SIF WebServices, that is looking into the possibility of using SOAP, for at least parts of the SIF Spec.

When the idea of using SOAP for SIF first came up, I have to admit: I didn't see the point. At that point in time, SOAP was a burgeoning technology that was the buzzword of the day and it seemed to be the coolest thing since ARPANET. But, I didn't see what it would really bring to the table that would really help the SIF Specification. Quite honestly, at that point in the game it really didn't have anything to add.

Now, however, times have changed and SOAP has matured and added many new building blocks that can fill in a lot of the missing pieces that are necessary for making interoperability work. SIF, on the other hand has really evolved their data model over the last 5 years, but the actual infrastructure messaging protocol has really not changed a lot or added new features.

Some people see SOAP as a threat to SIF and kind of wonder if it's going to make all that SIF is today, obsolete. Certainly, that could not be farther from the truth. SOAP is only a raw messaging protocol, nothing more. SIF is about a lot more than just raw messaging. The concepts of a ZIS, subscribing, request/response, eventing, all still need to be there, not to mention the rich data model that really is what SIF is all about.

All SOAP brings to the table is a lot of new tools that SIF would not have to build themselves. In fact, the way I see it fitting in, the SIF Specification would remain largely unchanged. Instead of being based on HTTP/HTTPS, a new protocol would be added, namely SOAP. All of the existing messaging such as request/response, provisioning, and events would all look largely the same as they do today, they would just be wrapped in SOAP envelopes.

What does SOAP bring to the table and how would it help SIF? One example, announced just a few days ago, the newest submissions[1] to SOAP, including WS-Trust and WS-SecureConversation. These additions, along with previous submissions, such as WS-Transactions, are building blocks that fill in the messaging chinks and provide enhancements that SIF will have to someday build on their own, if they keep the SIF spec anchored solely atop HTTP/HTTPS.

A couple of my favorite things, just off the top of my head, that SOAP could add to SIF are:

• A higher level of security than SIF Authentication level 3, which is not strong enough IMHO


• Add support for signing of messages


• Possibly help to solve the missing transaction piece in SIF, known in SIF circles as "Proposed Events"


• Provide a more interoperable solution to encryption of individual elements