Does anyone know of a good article or tutorial on the Internet demonstrating the use of GWT leveraging a (ASP.NET) web service cross domain?
To my knowledge, interacting with either XML or JSON should be possible from GWT, but becomes a lot more difficult when the web service is on a different domain. I've tried finding an article that demonstrates this setup, but without any luck.
There are a few options available:
use the Cross Site linker - it should make cross domain request easier, simply add <set-linker name="xs"/> in your module file (*.gwt.xml)
window.name hack :) Be sure to read the post with the original dojo proposal
JSONP
many others ;)
But first I recommend reading http://code.google.com/webtoolkit/tutorials/1.6/Xsite.html - it should get you going :)
I was initially going for a JSONP approach (as suggested by Google), in order to do cross site AJAX calls in JavaScript, but ended up with too many hacks that I had to incorporate into the ASP.NET web service in order for it to work.
The solution, in my case, was instead to use GWT RPC to a JAVA servlet, acting as a proxy, which then would call the ASP.NET Web Service using SOAP. The SOAP Java classes was generated using the wslist tool that is part of JAX-WS project (as demonstrated here).
Using the GWT RPC, I was still able to call the JAVA servlet asynchronously, giving the user a seamless experience.
Related
I want to use HTTP methods (GET/PUT/POST/DELETE) with an Azure resource and even have the URIs to do so. I understand that this practice utilizes RESTful web services.
What file type or programming language do I use to call these? On every documentation site that I have found, the only thing I see is something like the following, without any context:
Method Request URI
POST https://media.windows.net/api/Channels(‘*channelid*’)/Stop
So, where do I include this? HTML? C#? Do I create an ASP.NET web app and place it somewhere in there?
This would be very helpful to know so that I can utilize these methods!
You can use any programming language that has http support, or indeed your browser (most have native support to alter requests).
A more convenient alternative to test the api might be a rest client, a popular one being postman, a browser plugin.
I'd like to access some web api's using .net code, but am not sure if there's a way to generate a client side wrapper of some kind for these? Perhaps a code generator that can look at the web api documentation or through sample calls and generated .net classes and methods to encapsulate the api?
There isn't. REST-based APIs do not have a WSDL or service contract that could be used to generate a client stub.
That said, consider the following alternatives:
REST Coder: this is interesting research but no definitive tools yet.
Google for .NET WCF REST client: it turns up a lot of interesting results.
As far as I know, there isn't.
However, you can try one of the many wrappers available, that makes your life easier once you have to write less code.
Check this one out I've written a few months ago:
http://webapiclient.azurewebsites.net
We've recently been working on a fairly modern web app and are ready to being deploying it for alpha/beta and getting some real-world experience with it.
We have ASP.Net based web services (Web Api) and a JavaScript front-end which is 100% client-side MVC using backbone.
We have purchased our domain name, and for the sake of this question our deployment looks like this:
webservices.mydomain.com (Webservices)
mydomain.com (JavaScript front-end)
If the JavaScript attempts to talk to the webservices on the sub-domain we blow up with cross domain issues, I've played around with CORS but am not satisfied with the cross browser support so I'm counting this out as an option.
On our development PC's we have used an IIS reverse proxy to forward all requests to mydomain.com/webservices to webservices.mydomain.com - Which solves all our problems as the browser thinks everything is on the same domain.
So my question is, in a public deployment, how is this issue most commonly solved? Is a reverse proxy the right way to do it? If so is there any hosted services that offer a reverse proxy for this situation? Are there better ways of deploying this?
I want to use CloudFront CDN as all our servers/services are hosted with Amazon, I'm really struggling to find info on if a CDN can support this type of setup though.
Thanks
What you are trying to do is cross-subdomain calls, and not entirely cross-domain.
That are tricks for that: http://www.tomhoppe.com/index.php/2008/03/cross-sub-domain-javascript-ajax-iframe-etc/
As asked how this issue is most commonly solved. My answer is: this issue is commonly AVOIDED. In real world you would setup your domains such as you don't need to make such ways around just to get your application running or setup a proxy server to forward the calls for you. JSONP is also a hack-ish solution.
To allow this Web Service to be called from script, using ASP.NET AJAX, add the following line to the first web service code-behind :
[System.Web.Script.Services.ScriptService]
You can simply use JSONP for AJAX requests then cross-domain is not an issue.
If AJAX requests return some HTML, it can be escaped into a JSON string.
The second one is a little bit awkward, though.
You have 2/3 layers
in the web service code-behin class, add this atribute : <System.Web.Script.Services.ScriptService()> _
maybe you need to add this in the System.web node of your web.config:
<webServices>
<protocols>
<add name="AnyHttpSoap"/>
<add name="HttpPost"/>
<add name="HttpGet"/>
</protocols>
</webServices>
In the client-side interface
-Add web reference to the service on the subdomain (exmpl. webservices.mydomain.com/svc.asmx)
Visual studio make the "proxy class"
-add functionality in the masterpage's|page's|control's code behin
-Simply call this functions from client-side
You can use AJAX functionality with scriptmanager or use another system like JQuery.
If your main website is compiled in .NET 3.5 or older, you need to add a reference to the namespace System.Web.Extensions and declare it in your web.config file.
If you have the bandwidth (network I/O and CPU) to handle this, a reverse proxy is an excellent solution. A good reverse proxy will even cache static calls to help mitigate the network delay introduced by the proxy.
The other option is to setup the proper cross domain policy files and/or headers. Doing this in some cloud providers can be hard or even impossible. I recently ran into issues with font files and IE not being happy with cross domain calls. We could not get the cloud storage provider we were using to set the correct headers, so we hosted them locally rather than have to deal with a reverse proxy.
easyXDM is a cross domain Javascript plugin that may be worth exploring. It makes use of standards when the browser supports them, and abstracts away the various hacks required when the browser doesn't support the standards. From easyXDM.net:
easyXDM is a Javascript library that enables you as a developer to
easily work around the limitation set in place by the Same Origin
Policy, in turn making it easy to communicate and expose javascript
API’s across domain boundaries.
At the core easyXDM provides a transport stack capable of passing
string based messages between two windows, a consumer (the main
document) and a provider (a document included using an iframe). It
does this by using one of several available techniques, always
selecting the most efficient one for the current browser. For all
implementations the transport stack offers bi-directionality,
reliability, queueing and sender-verification.
One of the goals of easyXDM is to support all browsers that are in
common use, and to provide the same features for all. One of the
strategies for reaching this is to follow defined standards, plus
using feature detection to assure the use of the most efficient one.
To quote easy XDM's author:
...sites like LinkedIn, Twitter and Disqus as well as applications run
by Nokia and others have built their applications on top of the
messaging framework provided by easyXDM.
So easyXDM is clearly not some poxy hack, but I admit its a big dependency to take on your project.
The current state of the web is that if you want to push the envelop, you have to use feature detection and polyfills, or simply force your users to upgrade to an HTML5 browser. If that makes you squirm, you're not alone, but the polyfills are a kind of temporary evil needed to get from where the web is to where we'd like it to be.
See also this SO question.
Let me start off by stating that I am a novice developer, so please excuse the elementary nature of my question(s).
I am currently working on a Flex Application, and am getting more and more confused about when to use server side scripting, and when to develop web services. For most of the functionality I am working on, I am taking various files from the user (client), uploading to the server for processing/conversion, then sending back to client in new format.
I am accomplishing most of this using asp.net generic handlers (ashx) files, but not very confident this is best practice. But at the same time, does making web services make any more sense? What would be considered best practice for this? Any suggestions would be greatly appreciated.
The way I look at it is as follows:
Web Services mean Established Best Practice.
For most of our development, we don't need to create "Web Services", or what I'm thinking when I think REST, SOAP, and the Twitter API. You only need to start doing that once you've got something you're going to be using every day for years.
Clean and DRY code will Lead you to Creating a Web Service
If you spend the time to clearly define the parts of your upload-process-render Architecture, and you find that it can be applied to almost everything you are doing, then all you need to do to make it a Web Service is define a clear, 1-2-3 set of rules for using the system (GET/POST data, etc.). As long as you are consciously building an architecture the whole way, you'll end up creating a Web Service if it's worthy. Otherwise there's no need.
It sounds like you have a clear workflow going, I don't know anything about asp.net though.
As far as it being confusing sometimes, and best practices, I suggest the following:
Create a Flex Library Project for your "generic ashx file handling" Flex classes. Give it a cool, simple name.
Create a .NET Library Project that encapsulates all the logic for your server-side file processing. Host it online and make it open source. I recommend github. Test it as you go, and document it, its purpose and the theory behind it.
If you don't have to do anymore work at this point, and it's just plug and chug, then you've probably arrived at something that might become a Web Service, though that's probably a few years down the road.
I don't think you should try to create a Web Service right off the bat. Just make some clean and reusable code, make a few examples, get it online and open source, have others contribute and give feedback, and if it solves a specific problem, then make it a web service. You can just use REST for now probably, and build your system around that. RestfulX is a great library for that.
Best,
Lance
making web services without any sense make no sense ;)
Now in the world of FLEX as3 with flash version 10, you can easily read local files, modify them with whatever modifcation algorithm and save local files without pinging server.
You only have to use webservices if you want to get some server data or to send some data to server. that's all.
RSTanvir
Flash / Flex uses a simple HTTP POST approach for file uploads, so trying to do that using SOAP web services will be problematic. Your approach of using ASHX here sounds reasonable to me.
To send / receive data that isn't file based (e.g. a list of files the user has uploaded previously), I would recommend looking at the open source Fluorine FX library. Fluorine uses AMF which is a highly performant way of doing data transfer with Flash. It's also purely configuration-based, which means you don't need to code against any of its APIs, just configure Fluorine to expose your .NET service classes. You could easily add attributes to those same classes to expose them as SOAP web services via WCF if you need that in the future. I would not recommend using SOAP with Flex however, due to the performance losses and also because the Flex implementation of SOAP has a history of bugs and interoperability problems.
I use the ASP.Net ScriptManager to load the scripts needed for calling WCF services via HTTP/JSON. I am optimizing the total size of my pages (including scripts) and I see that Microsoft's AJAX library is the biggest file that I have at 96KB. Is there anyway that I can get a version of this file with just the features I need loaded?
Or since I already have jquery, should I use that to call my WCF JSON service instead?
Cheers,
Jon
WCF JSON services degrade gracefully down to working as a standard webservice, so you should have no problems using jQuery to post and retrieve data from them. You may lose some of the integration bells and whistles, but as someone who has taken the path you're suggesting, I can say that I don't miss it at all.
The only problem might be if you're using advanced WCF feature like 2 way connections, or guaranteed connections.