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.


Technorati Tags: , , , ,

Comments (9)

  1. John Hall says:

    You could also just make a web service in your app that calls another web service and returns the results.  Call it a "proxy" web service if you will.  Thats how I’ve done it.  This method will work when the web service you’d like to consume is completely outside your control and not an "Atlas" web service…  

  2. rugha says:

    had this issue a few months and atlas ctp’s ago

    I implemented the bridging stuff and after some twiking i worked fine,

    all said and done and imho i think that calling a callback code-behind method that will call the web-service is much easier and cleaner approach.



  3. FederalDev says:

    Sorry everyone, I should have been clearer…

    This blog post was to answer the question of "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?"  There are two approaches to server side bridging or what John Hall refers to as a "proxy" in his comment.  One is to roll your own web service that just calls a web service on another server or domain.  You can then call the web service YOU CREATED from the atlas script.  The other approach is to use the bridging technology I linked to in this post.  The bridging technology effectively does the same thing John Hall mentions, but does it in a declarative manner.

    I have updated the post to reflect the question more accurately.

    Rugha – I agree that bridging (whichever approach you use) is cleaner.  You get the ability to do things like caching, narrowing down the amount of data sent to the browser, etc.  Nonetheless, this is a frequently asked question so I figured I’d answer it:).

    Thanks for the feebdack!


  4. rugha says:


    great work 🙂

  5. Federal Developer Weblog からです。


    Calling web services hosted outside of your application with…

  6. Federal Developer Weblog からです。 Calling web services hosted outside of your application with “Atlas” 斜読みしただけなのですが、どうやら

  7. Etienne Brouillard says:

    It seems like a nice approach. Is it compatible with declarative markup blocks? I’ve been trying to use the technique but it seems limited to javascript… is that so?

  8. Tim says:

    I’ve tried implementing this solution however it doesn’t seem to be working as I don’t have the [WebOperation] attribute available to me.  

    I think this is because I am using a more recent version of AJAX which no longer contains the ‘Microsoft.Web.Atlas.dll’.

    Can you advise?