views:

95

answers:

1

My company is considering working with another company on a particular module. Information would be sent back and forth between us through my web service. Thing is, my web service uses ASP.NET, and they use classic ASP. Everything I've found online says (it's a pain, but) they can communicate, but I'm not clear on some details.

Specifically, do I have to enable GET and POST on my web service? If I don't have to, but could, would enabling them make the communication significantly easier/better? And finally, GET and POST are disabled by default because of security. What are the security risks involved in enabling them?

A: 

My first question should be "Why use Soap?". The simplest common demoninator that you have between the two is XML so thats a given. However the choice of transport can be as simple as an single .ashx or as clever as WCF service.

Since your first consumer is using ASP why use a technology that makes it difficult for them?

The true bottom line here is what are your security requirements?

AnthonyWJones
They're not my first consumer of my web service, they're just the first consumers of about 3 functions in my web service. That said, if there's a simple way to allow them access to those 3 functions by taking them out and putting them in their own service/handler/whatever, I'm all ears. Mostly, I need to be able to verify username and password before they can use the functions, and I need the solution to be simple enought that I can get them a working version by next week.
thchaver
Are all requests expected to be verified with a username and password or just an initial one? Is plain text passing of the password sufficient? Is there a VPN or SSL involved that might make such plain text usage sufficient? Do the ASPers on the other end have access to VB6 and the SOAP Toolkit? The list detail needed to make a success of this may continue.
AnthonyWJones