Jayachandra, To date, my team's approach has been to not trust the SOAP toolkits/platforms/sdks. We do exactly what Dims prescribes - run our WSDL (which we design first with Altova XMLSpy) through a WS-I checker and use the WS-I testing tools to check our resulting implementation (WSDL2Java generated service binding) for compliance at runtime. We use Mindreef SOAPScope to perform both the WSDL and runtime WS-I testing, as their product puts a rather nice interface atop the WS-I test suite.
The day may come when you can implicitly trust your toolkit, but we're just not there yet. Regards, -Jon -----Original Message----- From: Davanum Srinivas [mailto:[EMAIL PROTECTED] Sent: Monday, March 07, 2005 8:13 AM To: [email protected]; jayachandra Subject: Re: WS-I compliance of a webservice They way to certify that a service is WS-I compatible using the WS-I testing tools: http://www.ws-i.org/deliverables/workinggroup.aspx?wg=testingtools. Basically you run the WSDL, ensure compliance and then run all messages to check if messages are compliant as well. -- dims On Mon, 7 Mar 2005 17:49:35 +0530, jayachandra <[EMAIL PROTECTED]> wrote: > Hi all, > > Can't one authorizedly say that his/her developed webservice is WS-I > compatible if the framework using which one developed that particular > webservice is WS-I comaptible? > Are there any other criteria that are to be considered to certify that > a web service a developer codes is WS-I compatible? > If so, what are they. Do they restrict the use of certain kind of > datastructures as in/out params. Can someone clarify siting pointers > to useful resources or with some own example? > > Thanks in advance, > Jayachandra > -- Davanum Srinivas - http://webservices.apache.org/~dims/
smime.p7s
Description: S/MIME cryptographic signature
