Can someone explain the difference between the two, when to use WebScriptServiceHostFactory vs WebServiceHostFactory? I understand when used they setup certain default behaviors on the endpoints so I don't have to. Otherwise the differences, is it just the WebScriptServiceHostFactory defaults to JSON messages, while WebServiceHostFactory defaults to XML (soap messages)? Using WebGet and WebInvoke, do both work on them, or does one not allow it? Also can I use UriTemplates, to build REST services, with either one?
The WebScriptServiceHostFactory is used almost exclusively to define services that will be consumed by the ASP.NET AJAX framework (it gives the JS client a "proxy" which can be used to call the service). If you're doing general-purpose WCF web (REST) programming, you should stick with the WebServiceHostFactory.
Some differences:
As you mentioned, the default response format is different (JSON in WScriptSHF, XML in WSHF)
UriTemplates are fully supported in WSHF, not in WScriptSHF
WebGet and WebInvoke work on both, but on WScriptSHF the only supported body style is WrappedRequest
Responses to calls to an endpoint created by WScriptSHF are wrapped in a JSON object; if the response to an operation (in JSON) was [1,2,3], the endpoint will return it as {"d":[1,2,3]}.
There may be others, but essentially, the guidance is to use the WScriptSHF only if you're using the ASP.NET AJAX framework (with the <asp:ScriptManager>) and the WSHF for everything else.
Related
I am already using the standard WebAPI and returning JSON objects to my client. Now I saw an application that returned OData.
Can someone explain if there is any reason for me to use OData if I do not want to query my data from anything other than my own client running in the browser. Are there advantages that I could get through using OData ?
If you are only using your data in your own browser application, there is only few advantages to use OData in your situation:
OData is able to provide metadata about your service interface that can be used to generate client code to access the service. So if you have lots of client classes that you need to create, this could speed up your process. On the other hand, if you can share your classes between the server and an ASP.NET based client or if you only have a few classes, this might not be relevant in your situation.
Another - bigger - advantage in your situation is the support for generic queries against the service data. OData supports IQueryable so that you can decide on the client side on how to filter the data that the service provides. So you do not have to implement various actions or use query parameters to provide filtered data. This also means that if you need a new filter for your client, it is very likely that you do not have to change the server and can just put up the query on the client side. Possible filters include $filter expressions to filter the data, but also operations like $skip and $top that are useful when paging data. For details on OData and queries, see this link.
For a complete overview about OData and Web API see this link.
Here are few advantages of OData.
OData is a open protocol started by Microsoft is based on Rest Services so we can get data base on URL.
It suppport various protocol like http,atom,pub and also support JSON format.
No need to create proxy classes which we used to do it in web service.
You will able to write your own custom methods.
It is very light weight so the interaction between client and server will be fast compared to web service and other technologies.
Very simple to use.
Here are few reference links.
http://sandippatilprogrammer.wordpress.com/2013/12/03/what-is-odata-advantages-and-disadvantages/
http://geekswithblogs.net/venknar/archive/2010/07/08/introduction-odata.aspx
http://www.zdnet.com/blog/microsoft/why-microsofts-open-data-protocol-matters/12700
I agree with the answers already posted, but as an additional insight...
You mentioned that:
... if I do not want to query my data from anything other than my own
client running in the browser...
You may not wish to run it normally through anything but your own cilent, but using oData you could use other querying tools for debugging. For example LinqPad allows you to use oData endpoints (such as that provided by stackoverflow).
It's probably not a good enough reason to implement oData if you don't have another reason to do so, but it's an added bonus.
I'm reading the OWIN 1.0 spec at http://owin.org/spec/owin-1.0.0.html and just can't wrap my head around how it works. I've downloaded Katana source, but that's huge and didn't help any. I'm familiar with the somewhat standard way of having a project/assembly with interfaces only, which allows to integrate two projects without direct regencies. But I can't understand how the web server will call into the web app with only Func<> and Action<> definitions.
OWIN boils down to two things:
1) an "environment" dictionary
2) a method that processes requests and sends responses.
For #1, this is just a property bag that gives you access to the request headers, request stream, response headers, response stream and server data. Think of this as your HttpContext for ASP.NET or HttpListenerContext for System.Net.HttpListener. In fact, in more recent builds of Katana (https://katanaproject.codeplex.com/, which is an open source implementation from the ASP.NET team, there have been improvements (more to come) to simplify this down to an easier to use object model, including an OwinRequest, OwinResponse, and IOwinContext.
For #2, this is often called the "AppFunc" and the signature is:
using AppFunc = Func<IDictionary<string, object>, Task>;
This signature is used for "Middleware" that is in a pipeline of request handlers or it can be the end application which is generating HTML, is a WebAPI, etc.
In Katana, there is a class you can inherit from that simplifies this signature to consume the IOwinContext I mentioned previously. Take at look at OwinMiddlware
You can also read this article which gives an overview of the Katana/OWIN effort: http://www.asp.net/aspnet/overview/owin-and-katana/an-overview-of-project-katana
OWIN just defines how the web server and web application will talk to each other. Your application must implement one side of this contact, the other side which connects to the web server must be provided by installing a NuGet package specific to the web server. There is one for IIS, one for self hosting (stand alone application) etc.
We have a Flex application which relies heavily on data driven content supplied via asp.net. Currently the majority of this data is provided via asp.net objects which are then XML serialised and sent via a simple ASHX handler. This is then parsed via e4x in singleton classes to populate either its self or arrays of sub classes which are then available to the rest of the application without making additional data calls.
This works but is it the best way? I've read quite a few articles discussing the subject but couldn't really find any consensus.
Should I look into converting these to Web Services? If so, how should I manage the bindings, automatically import them via Flex or build my own? What are the pro's and con's. An important factor in this decision is speed, lowest latency and highest throughput is essential
As a separate matter our application doesn't sit at the root of the domain, and when in local development makes data calls to our development servers. As a result we add flash vars to the application to specify the appRoot which is then appended to the service url as necessary.
MyService.url = GeneralData.ApplicationRootUrl + "Services/foobar.ashx";
Is this the best way? I have since discovered the rootURL property, should I be using this, how does it work in this context? If I were to convert the services to web services how would I go about implementing the same functionality to allow local development?
Many thanks
This works but is it the best way?
Best is very subjective based on your situation. If at all possible, I would recommend you use an AMF gateway. That way your objects can immediately convert from server side objects (.NET Classes) to client side objects (AS3 classes). This is a big time savings because you don't have to manually create your XML on the back end, nor manually process it in the front end. Also the binary format of AMF is going to give much smaller packets than XML or a SOAP WebService would.
For .NET AMF options, I'd look into WebORB or FlourineFX
Flex Application is always loaded in browser, and you can use relative URL, so that your application will connect to same server from where it is loaded.
MyService.url = "/Services/foobar.ashx";
"/" will certainly append host where it came from. And it is always good practice to connect to same host where the flash is loaded from.
Secondly, SOAP web services use xml serialization, so if you use your handler to do e4x serialization or you use SOAP web service generator of Flash Builder, speed will be almost same. SOAP web service will certainly be little slower, but the difference will be in micro seconds to milli seconds.
However, with Web services, your development will speed improve as you will not have to create proxy classes.
Why doesn't a ASP.NET web method allow default parameters ?
The reason ASP.NET WebServices don't support default parameters or method overloading is not a shortcoming of ASP.NET or C#. The reason is because WebServices themselves, no matter the language or platform of implementation do not support default parameters or method overloading.
WebServices are a lowest common denominator technology. You cannot guarantee what technology the consumer will use to consume your WebService, and conversely, if you're consuming a WebService, you often have no idea what platform or language it was implemented with. Because of this we have to use a feature-set that we're pretty sure any platform will be able to work with.
Unfortunately, even though in .NET 4 C# has finally received the ability to have optional parameters in methods, the WebMethods still do NOT support them. Also, overloading methods doesn't work either. This means you'll have either multiple methods with different names, or the same method with all the parameters, and the optional parameters being nullable.
I was rather disappointed by this as well :(
Is it required to use a RESTful
service to be able to make a ajax
call to a wcf service (for example: by using
WebInvoke attribute on Operation
contracts)
Once a service is made RESTful by adding a webHttp binding on the service host, can the host have other endpoints as well? (wsHttp or netTcp)
Is it required that the aspNetCompatibilityEnabled be set to true for a service that has webHttp binding (and can this setting coexist for other endpoints)
I understand I can use both JQuery and ScriptManager for making WCF calls on the client. Why should I use one over the other?
Answers
No.
AJAX is typically used for sending simple HTTP GET ("REST") requests. It doesn't have to be so. You could also format a payload using a SOAP envelope, and POST it to the endpoint. In that case the WCF service would have to be wsHttp or basicHttpBinding, at least. Here's an example of using VBScript to create and send a SOAP request, but you could do the same in Javascript. You can't use the more advanced SOAP extensions, like WS-Security, XML DigSig, and so on. Well, you could but it would be impractical. For example, I don't know of any XML canonicalization library in Javascript, which is essential for doing WS-Security or digital signatures. There are 17 similar obstacles. Result: you can't use the more advanced SOAP extensions when calling from Javascript.
.
If you use jQuery ajax, you'll need to use the beforeSend callback on the ajax request to set the SOAPAction header.
.
Having said that, it's a lot easier to process json in a Javascript program, than it is to walk the DOM of an XML document. In other words, you're better off using JSON/REST when connecting from Javascript to WCF, instead of SOAP. Sometimes it's not an option, I guess.
Yes
A WCF service can have multiple endpoints and they can listen on the same or different transports such as HTTP, net.tcp, net.pipe, or net.msmq.
No. aspNetCompatibilityEnabled just enables some ASMX-like features on the server. It affects how the service is designed, and it is independent of the message signature. It does preclude the use of non-HTTP protocols. For more on this, see Wenlong Dong's article.
as for which framework to use on the client - which is easier? I don't have experience with ScriptManager, but the decision criteria is pretty simple. jQuery works just fine, and is appropriate if you already use jQuery. If you don't have or want jQuery, you can use XmlHttpRequest to send SOAP or REST requests. If those are somehow inappropriate, use something else.