views:

416

answers:

4

I am a classic ASP developer. I know, I should learn .NET, but only have a couple more years left at this. I would consider myself advanced.

I have a third party application that will export data to a web service if I develop it. I am curious to see I can build it in ASP rather than having to learn .NET.

My problem is I haven't figured out how to retrieve the request it makes.

Neither the Request.Querystring or Request.Form or Request.ServerVariables collection methods reveal anything. I have used CharlesProxy to see what the XML/SOAP request that it sends looks like, but I just haven't figured out how to capture it in ASP.

I have noticed the ServerVariables request of HTTP_SOAPACTION being passed that reveals the operation being called, but I simply can't figure out how to retrieve the XML string being passed.

Any help would be greatly appreciated.

A: 

Such valiance.. I'd probably run screaming for the door if I had to write anything more than trivial webservices this way.

...anyway, have you gone through this article? It seems to be using ASP for the server part.

I'd seriously consider picking up some basic ASP.NET (or just .NET WCF) skills. Use VB.NET if it makes you feel more "at home". If not for yourself, think of the sanity of your successor :) Download Visual Web Developer 2008 Express and just try it.

Thorarin
Thorarin,I really appreciate the information! The URL you provided allowed me to successfully retrieve the SOAP request using the below code...Set objReq = Server.CreateObject("Microsoft.XMLDOM")objReq.Load RequestResponse.Write objReq.textThis will get me started! I agree that I need to learn .NET, but for now, I already have routines for parsing XML code that will let me build this very quickly. I can't express how appreciative I am. Thank you!
So, your service will not have a WSDL?
John Saunders
As far as I can comprehend, it won't be necessary. This will be used internally as a private web service. We have a Windows based inventory system that is capable of exporting the data periodically to a web service. It sends a SOAP request with a block of 100 inventory items and expects a specific SOAP response back. I have already been working on it and I am almost finished. I couldn't have learned how to do it this fast in .Net. This will give me time to learn how to do it in .Net.
A WSDL will be necessary if you don't want to hand-craft the XML to be sent to your service. Of course, since you're using Classic ASP, you may be accustomed to that.
John Saunders
A: 

If they want an actual SOAP web service, then you're going to have to manually create an actual WSDL. That will take enough effort that you'd be better off writing a little web service in .NET.

Do you also know VB6? If so, then I'd advise you to write as much of the guts of the web service as possible as a COM component in VB6. Have the component accept a MSXML2.DomDocument or whatever, and do all the hard stuff using a technology you're familiar with.

The .NET web service part will be trivial, and will only be a modification of the standard "hello, world" service you get when you create a WCF Service project. All you'll have to do is reference the COM component you created and registered, do a trivial conversion from the .NET XML type to the MSXML type, and call your component, and you'll be done.

John Saunders
Agreed, WSDL is barely human-readable, let alone writeable :P
Thorarin
A: 

If you consider yourself "advanced" you should take a few days to study up on VB.NET and implement it as a simple ASMX web service. If you want more pain but infinite variety, build up the intestinal fortitude for WCF and make a WCF service. If you've been in the game long enough you'll understand that creating something more sustainable is less painful overall even if it's a big commitment to get started.

David in Dakota
ASMX is practically dead, and for his purposes, a WCF service is just as trivial as a trivial ASMX service.
John Saunders
I would argue that the flexibility of WCF is what makes it more complex than ASMX. You might feel comfy with bloated config files as a Connected Systems guy but without being used to them they can add a lot of confusion. Nevertheless I agree that WCF is probably the best path for this guy.
David in Dakota
Why does the "bloat" matter, if you never have to look at it?
John Saunders
Kudos for at least admitting it is bloat. I think the bloat matters when the nuances hidden in it break your heart - like a WsHttp's cryptic refusal when you point your Silverlight [or insert non-M$ platform here] client at it.
David in Dakota
I put it in quotes, meaning I was repeating your use of the term. I do not consider it to be bloat. I consider it to be configuration.
John Saunders
A: 

However, WCF has some limitations that you shoudl be aware of - like it refuses connections to clients like IE and other ASP-built clients (since they use the "mozilla" string in the client header) - and configuring a WCF client-server connection correctly is like brain surgery blindfolded in an F-14 at Mach3 with your hair on fire. Not so easy.

My recommendation is ASP with C#. Easy peasy, lemon squeezy.

TheIguana
-1: Your answer doesn't make sense, at least not without more detail. What do you mean, "refuses connections to clients like IE". How is IE an "ASP-built client"? What makes you think there's a problem with "mozilla" in the "client" header, and what is the "client" header anyway? Fix the problems and I'll remove the -1.
John Saunders