Richard Seroter has a few good recommendations here on how to diagnose the confusing "Internal SOAP Processing Failure" message you get when a call to a WebService exposed from BizTalk fails. As he mentions, it can be quite confusing and sometimes quite hard to get to the root of the cause if you're not familiar with the system.

Other recommendations I'd add to Richard's list would include:

• Make sure the URL specified in the receive location matches the one where the service is actually deployed. An simple typo here can make your life miserable.
• Make sure the receive location is enabled (it never hurts to mention it )
• If the service is request/response, make sure the orchestration is not taking too long to send the response message back and is not causing the service to fail with a timeout.
• Make sure that you haven't done any changes to the schemas used by the orchestration and didn't run the Web Service Publishing wizard again to generate the WebService and the associated messaging. I've seen plenty of people having their exposed Web Service failed because of a schema change that causes the incoming message not to trigger the right subscription, or have it cause the orchestration to fail when it tries to access a missing field.

Besides this, I always recommend developers that any orchestration that is going to be exposed as a Web Service should have extremely strong error handling built-in, hopefully to ensure it always returns a response message (either a real response or a failure message). Otherwise, an unhandled exception will cause the orchestration instance to be suspended which will cause the Web Service to timeout.