views:

1795

answers:

4

Clarification: this is not about user agent calls to pages, but Classic ASP calling ASP.NET!

I have applications that are midway through a transition from Classic ASP to ASP.NET. There are a half million lines of code, so a complete rewrite of everything at once was simply not plausible, or frankly prudent considering that the vast majority of Classic ASP pages work just fine. We translate pages and functionality as they come up for revision anyway, not just because it is "cool".

Now that about half the pages have been converted we have moved some of the key functionality over to ASP.NET. Instead of keeping the legacy versions of this functionality (which means two places to maintain instead of one) I have been moving towards using SOAP to expose this functionality.

Well... not really. Instead, we have been using what I used to call "Poor Man's SOAP", although today it is trendy to call it REST. I have been using ServerXMLHTTP to contact the destination page, bundling up a ball of XML and POSTing it over to the ASP.NET side. For the result I have been bundling up some XML and using XPATH to tear it down into variables.

All of this works surprisingly well. However, I have been contemplating the built in ASP.NET SOAP features, which would seem to remove the need to custom write landing pages for my cross platform calls... but when I look at consuming SOAP from Classic ASP most suggest using the seemingly depreciated Soap Toolkit.

The question is; do any of you have experience with this kind of setup and if so are there any better ways to do it than custom REST pages or Soap Toolkit? I think being able to expose more of the ASP.NET functionality quicker would help with the migration, but I don't want to get myself mired in legacy technology like Soap Toolkit unnecessarily.

+2  A: 

I have found this site to help me with AJAX and Classic ASP. Maybe it can help you as well?

Optimal Solutions
We do some light AJAX with our newer code, but this is more about calling ASP.NET directly from the Classic ASP side as I don't want to trust a user agent with the tasks that need to be handled across codebases.
Godeke
Gotcha. Have you considered building some sort of middleware type of DLL that you can trust?
Optimal Solutions
I have used DLLs in the past, although we moved away from them due to the IIS restart requirement when they change. These days with multiple webheads it isn't so bad, but I like the fact that when the code is updated, all callers get the new version immediately with HTTP.
Godeke
I read those two links you provided. They were very interesting and I've got them bookmarked. Best of luck to you. If I encounter anything else I'll post back here.
Optimal Solutions
+1  A: 

I use Prototype with a lot of classic ASP pages for AJAX calls. I prefer working with JSON than XML for my data layer. Ajax + JSON is much lighter and faster and easier to deal with than SOAP + XML.

Diodeus
This isn't about client side SOAP, but Classic ASP calling ASP.NET SOAP on the same machine.
Godeke
+4  A: 

Doing a bit more searching I found

http://stackoverflow.com/questions/11219/calling-rest-web-services-from-a-classic-asp-page

which in turn linked to

http://www.aspfree.com/c/a/ASP/Consuming-a-WSDL-Webservice-from-ASP/

This is pretty much how I'm doing things now, so perhaps this is the best solution?

Godeke
+1  A: 

I was able to do this with the following code, obviously you will need to change some things, but hopefully this can get you started:

Set xmlhttp = CreateObject("MSXML2.ServerXMLHTTP")                          
xmlhttp.open "POST", soapServer, False
xmlhttp.setRequestHeader "Content-Type", "text/xml; charset=utf-8"
xmlhttp.setRequestHeader "SOAPAction", char(34) & "WebPlatform.WebServices/ISessionTokenServiceV1/CreateSessionToken" & char(34)

xmlhttp.send soapMessage

soapMEssage will be the soap request you are sending. soapServer is the url of the web service, such as: http://localhost:8000/WebServices/SampleService.svc/BASIC

wwilkins