Calling web services hosted outside of your application with “Atlas”

UPDATE: I changed the question I am answering through this post in an effort to be less confusing. There is some good feeback going on in the comments. Feel free to chime in with your opinions. What scenarios do you think you would use one approach over the other? Why?

One of the things I love about my job is when customers ask me questions I can’t answer. Customers always ask the hard questions and make you think through scenarios you may not have tried before. I love that! Here is a question I have been asked about “Atlas” a few times that I finally got around to trying:

“How do I call a web service I created that is not hosted in the same web app from ASP.NET ‘Atlas’ without using a server side bridge?

First of all, if you didn’t create the web service, you don’t have the flexibility to make a few changes to the code/configuration, or it wasn't written using asmx (2.0) or WCF, then you will have to use the “Atlas” bridge technology.

On to the solution to the question…

The web app in which the web service is hosted MUST have the “Atlas” bits deployed and configured. I blogged about adding “Atlas” functionality to an existing ASP.NET web app here. Why? If you are asking that question, then it’s probably because you are assuming that the “Atlas” client script libraries call ASMX and WCF web services using SOAP. They don’t. They actually use the JavaScript Object Notation (JSON). Because of this, you have to have the “Atlas” server bits deployed to serve JSON to and process JSON from “Atlas” clients. Once you have “Atlas” properly configured for your web application you have to make sure the following http handler is configured in the <httpHandlers/> section of the web.config:

<add verb="*" path="iframecall.axd" type="Microsoft.Web.Services.IFrameHandler" validate="false"/>

The web.config file that comes with the June CTP has the following comments that you must take into consideration:

“The IFrameHandler enables a limited form of cross-domain calls to 'Atlas' web services. This should only be enabled if you need this functionality and you're willing to expose the data publicly on the Internet. To use it, you will also need to add the attribute [WebOperation(true, ResponseFormatMode.Json, true)] on the methods that you want to be called cross-domain. This attribute is by default on any DataService's GetData method.”

Next, as stated in the comment quote above, you need to adorn the web service web methods you want to call from your “Atlas” client with the following attribute:

[WebOperation(true, ResponseFormatMode.Json, true)]

WebOperationAttribute is in the Microsoft.Web.Services namespace (which is in the Microsoft.Web.Atlas.dll assembly).

There is a “gotcha” for the development environment with this scenario. Your “Atlas” client web app and “Atlas” enabled web services app will be in different Visual Studio projects. By default, Visual Web Developer uses the new ASP.NET Development Server (the local web server that starts up and displays an icon in the notification area of the taskbar) feature. The local server is configured by default to randomize ports. The default configuration will cause you to update your web service URLs in your client apps each time you open Visual Studio 2005. You need to switch this to have a static url. To do this, change the “Use dynamic ports” setting of the web app to “false” and give a predefined port. You can now use the new url in your client app.

I put together a trivial Visual Studio 2005 solution here that implements all the things I explained in this post.

I hope those of you who have asked me this question are subscribed to this blog. HTH.

-Marc

Technorati Tags: Microsoft, .NET, Atlas, AJAX, Web 2.0