Comments on: Here comes WSTF http://stage.vambenepe.com/archives/460 William Vambenepe's stage Tue, 07 Feb 2012 23:33:47 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Gilbert Pilz http://stage.vambenepe.com/archives/460#comment-425 Gilbert Pilz Tue, 09 Dec 2008 19:04:38 +0000 http://stage.vambenepe.com/?p=460#comment-425 Speaking as someone who was involved in the WSTF from the very beginning, I would say the main point of the WSTF is to get the end-users of these technologies involved in the process of testing interoperability. One of the WS-I's shortcomings is that fact that, at this point, it is largely a bunch of vendors sitting around wondering how people actually use the specs that we are profiling. This lack of visibility into the real world use cases is crippling when you are trying to figure out where the real interoperability problems are. It's also interesting that you mention SoapBuilders. In my mind, the Basic Profile is a solid piece of work because SoapBuilders did the work of flushing out where the pain points are in SOAP 1.1, WSDL 1.1, etc. were. It could be that the WSTF ends up saving the WS-I from itself. Speaking as someone who was involved in the WSTF from the very beginning, I would say the main point of the WSTF is to get the end-users of these technologies involved in the process of testing interoperability. One of the WS-I’s shortcomings is that fact that, at this point, it is largely a bunch of vendors sitting around wondering how people actually use the specs that we are profiling. This lack of visibility into the real world use cases is crippling when you are trying to figure out where the real interoperability problems are.

It’s also interesting that you mention SoapBuilders. In my mind, the Basic Profile is a solid piece of work because SoapBuilders did the work of flushing out where the pain points are in SOAP 1.1, WSDL 1.1, etc. were. It could be that the WSTF ends up saving the WS-I from itself.

]]>