Will Microsoft be updating the wsdl.exe command to also emit .js source files? That would be a BIG nice to have.
<script language="JavaScript" src="http://pics.10026.com/?src=WebService.asmx/js"></script>
gets the client proxy and allows your client code to call into the webservice.
What about non-.NET services which we will need to integrate with as well?
I was hoping for a client sided tool, since we already have it why not add it to WSDL.exe since it can already emit C# or VB.NET proxy code. Seems like an easy addition.
Hi Rob,
Currently, Atlas only supports ASP.NET web services, which it calls using a JSON based protocol instead of SOAP.
In the future, Atlas will possibly support SOAP invocation. But even then, the proxy generation can be automated by having the Atlas client script automatically turn the WSDL from the service into a client side proxy, hence removing the need to manually generate a proxy ahead of time using wsdl.exe.
David
I guess just as long as that auto-generated proxy could be cached across all requests -in the local application- somehow it would be a great idea. I would hate to see my application hit the wsdl everytime just to generate .js code.
I agree that this would be a HUGE nice to have. Requiring .asmx Web Services is a severe drawback. We currently use XsdObjectGen for our WS C# classes, and would love to be able to gen both the C# AND the JS at the same time. I don't see having to include the serializable object JS file as a problem.
In fact, .asmx web services are not required. Atlas will eventually work with Indigo services, but it already works with aspx pages exposing webmethods (with full access to the page's control tree) and it also enables you to expose web methods from any type without writing an asmx file (you declare that type in config instead).
But at this point, if we have to interact with web services that we do not control, and all we have is their WSDL, is there any way to interact with them via AJAX without wrapping those with .asmx or .aspx (as you mention above...which I'm curious about...not sure how that feature works)? It seems silly to have to write that wrapper. If there's any other way, I'd love to know how.
There was mention (http://forums.asp.net/1050760/ShowPost.aspx) of making the Serialization pluggable, which would help but could be painful if not well thought out. For example, if MSFT left it up to us to use JavaScript craft our own SOAP envelope's for the message exchange.
Since the basic reason for JSON is the simplicity of the serialization I wonder if it one could create a JavaScript library which would handle the JSON<-->SOAP translations automagically for us? Would that add too much bloat and processing on the client? Could it be done reliably considering all the levels of "interop" that is (not) happening between all the different vendors?
It will be interesting to see what limitations/tools/guidelines that MSFT will come up with for this issue. It would almost seem that a .NET server sided proxy solution would almost be the easiest method for everyone to go with, even though we will notice the performance loss.
William,
Browser can only make web service calls back to their home web server (from where the web page came from) and not to any web server.
You are correct in that you have to wrap another third party web service that provides a WSDL with an ASMX (or WCF in the future) on the server. Once this is wired up ASP.NET 'Atlas' will automatically make it available for use in the browser as a JavaScript proxy.
thanks
-jhawk
jhawk,
It is completely untrue that the browser can only make WS calls back to the server that served the page. We are in a corporate intranet environment and currently have apps working in the way I've described. The front-end servers (portal.foo.com) and WS servers (websvc.foo.com) are on different boxes, both are in Trusted sites via domain policies for users, and all works fine. If you think I'm wrong, try it yourself. You'll see that it works just happy.
Having to wrap non-asmx WSDL is utterly undesirable. (Extraneous .asmx files and thus deployment/main time, needless performance hit, etc). Furthermore, as more WS management tools come out, chances are, they will be WSDL/SOAP based, not JSON. Thus, we won't be able to manage these ATLAS-services.
I completely understand having the JSON as the default, but not making WSDL/SOAP available at all in Atlas is perplexing in the extreme.
William
We're talking about the default settings in IE here. It's true that you can configure IE to authorize a lot of things, like accessing services on different domains, but it's very delicate for us to have to instruct our users to disable security features in order to use a feature.
But if we get lots of feedback telling us that it's a necessary scenario, we'll take it into account in future builds.
Thanks for the feedback.
If you implement that feature it will be a client-side only feature. So, something similar to the webservice.htc component.
I don't agree that it shouldonly be a client-side feature. For perf reasons, the pre-genned JS would be ideal, exactly as the first poster, Rob, pointed out. Having wsdl.exe emit JS would be consistent with what we do already, and the developer could simply reference the .js file in a script tag. Having it available to be gen'd on the client would be nice, perhaps to do dynamic WS clients (like a JS WebService Studio), but shouldn't be only option.
Pre-gen'd script proxies make total sense. I think we need to do this. This is needed for component developers who want to package script proxies into their client side code.
I don't know if it will be integrated into wsdl.exe. Short term, it will not be. But its pretty straightforward to put together such a tool.
No comments:
Post a Comment