I'm just developing my first WCF WebMethod, and am looking at error handling.
After having spent a week reading up on this, the general consensus seems to be that errors within WCF WebMethods should be thrown as either WebFaultException, or FaultException. Furthermore, many tutorials teach that using FaultException(Of T) provides even better functionality. This seems straightforward enough...
I then found a source stating that throwing CLR Exceptions is not good when the WebMethod is being consumed by a non-.NET application, e.g. Java etc, and that a SOAP Fault should be used.
Can someone please clarify whether the logic is built-into WCF 4.5 to automatically convert FaultException and FaultException(Of T) to a SOAP fault that can be processed/understood by external systems?
In general, how do other people communicate errors to external systems please?
If you use FaultException(Of T), it will interop with other SOAP technologies like Java. This SO post explains it - WCF/WebService: Interoperable exception handling. This is how I've done it for Java clients. Let me know if you need more detail.
Related
I have inherited supporting and making BizTalk applications as part of my development role.
I'm a general C# developer so I was pleased to see I can create Classes and call the Methods from the Expression shape of an Orchestration.
This means I can do all the data manipulation using code I am familiar and faster with rather than learn the BizTalk ways.
At this point I am not concerned with if it's a good idea or not.
Are there any purely technical reasons I should not do this?
You would have to make sure that whatever external methods you are calling is muli-threading capable and can handle high throughput.
If you don't achieve the above then you will either get some very strange issues (caused by cross thread contamination) or you will cause a bottle neck in BizTalk which will reduce message throughput.
You also need to make sure that errors are handled, retried and propagated back correctly to the calling Orchestration on failure. I came across one solution where the developer for some reason had decided to call a web service using an external class. Every so often this web service would throw an error, but the class would just pass the error message as it was back to the Orchestration as if it was a valid response message. This would cause a failure later on in the Orchestration when it tried to use the message and it did not match the expected message. When I got allocated budget I replaced this class with a properly configured send port, which also automatically retried the message when it encountered the web service error and then it successfully processed.
Technically you are adding deployment and maintaining complexity with the externals assemblies, for example any change in some contract will require changes in the assembly and the orchestration.
And you're losing all the advantages of the BizTalk mapping engine for data transformation which is in general an easy part to learn.
I say this, it's very important for future maintainability to develop BizTalk apps in the "BizTalk Way".
For example, if you did message manipulation in an external class that should have been done in a Map or with XPath, I would fail that in Code Review and you'd have to refactor.
The reason is because whoever might take this over from you should expect a BizTalk app. I've seen situations such as you describe and it does make it harder to upgrade, enhance, support new business requirements because now the developer has to accommodate the BizTalk and external processes.
Technically using .NET classes does not break anything in the BizTalk. Lots of BizTalk components are based of .NET framework such as Adapters, pipeline components etc. In my view, use the best of both BizTalk and .NET depending on the scenarios. e.g. if you need to map an inbound XML to outbound XML use BizTalk maps as they are lot easier and quicker to implement, in this scenario using a .NET class is more tedious then using map. I don't think there is a big learning curve in using BizTalk features such as Maps, orchestrations, pipeline components.
What is the pros and cons of webservices (.asmx) vs handlers (.ashx) for ajax calls.
Is there any? I think handlers are kind of better because you don't get so much bloat as you would with webservices. Any advice or suggestions of either practice?
I would recommend using handlers primarily for the reason you suggest. There's additional overhead with web web services, which were designed for heavier SOAP operations, as opposed to an HttpHandler.
Additionally, a lot of that SOAP information isn't often needed for AJAX calls. Let's say that I just want to return some JSON to the page. Building a .NET web service which does this, in my opinion, breaks the concept of what a .NET web service is. A handler can indeed be anything, but a web service generally implies a SOAP or WCF contract of some kind. Not just outputting some JSON and ending the response. (Maybe I've missed a JSON web service feature somewhere, that's entirely possible. This is just the approach I've taken.) So, again at least for me, it's also a matter of separation of concerns in the design.
The intent is to create a set of web services that people can reuse. These services mostly interact with a backend DB creating, retreiving and processing data.
We want to expose services so that people can use to create data mashups and other applications.
End users are webpages that can be within our domain or outside our domain. For pages outside the domain we plan to release widgets that would be configured to retreive and display the data.
One requirement - application should be extremely scalable in terms of the number of users it can handle.
Our code base is .net and we are looking at ASPX webmethods (or ASHX), ASMX webmethods and WCF (starting to read up on WCF).
In terms of security/access I found that maintaining sessionid, memberships is doable in all three. WCF seems a bit complicated to setup. I could not immediately see the value of asmx when we can get all done just using a webmethod in aspx (with a little tweaking).
Also, assuming that with the ASP.NET MVC2 I might be able to get clean urls as well for these webmethods.
Questions
Which one will be the most effective in terms of performance and scalability?
Any reason why I should choose WCF or ASMX?
Thank you for taking the time to read through this post and apologies for the naive questions since I am new to .net.
EDIT I kind of understand that WCF is the way to go. Just to understand the evolution of the technologies it would be good if someone can throw light on why a aspx webmethod is different from an asmx when similar things (apart from discovery) can be accomplished by both. The aspx webmethods can be made to return data in other formats (plaintext, json). Also, it seems that we can build restful services using ashx. Apologies again for the naive questions.
You should use WCF for developing webservices in .Net. WCF is highly configurable with many options for security, transport protocols, serialization, extensions etc. Raw performance is also significantly higher. Also WCF is being actively developed and many new features being added in version 3.5 and 4. There are also variations like WCF data services and WCF RIA services. WCF 4.0 also has better REST and JSON support which you can directly use in ASP.Net / JQuery.
ASMX is considered deprecated technology and replaced by WCF. So if you are going to start new development which requires exposing reusable services, WCF is the way to go.
I am not necessarily disagreeing with previous answer. But, from a different perspective, WFC is tricky to configure. It requires bindings, endpoints, packet sizes, a lot of confussing parameters, etc in your configuration files, and there are many serialization/deserialization issues reported. Also WCF is a relatively new technology (therefore still exposed to bugs and patches needed).
The client-generated [Reference.cs] files might have unwanted interfaces, and each public property client class exposed in the WSDL gets generated with the same observer pattern that LINQ to SQL or Entity Framework uses ( OnChanged, OnChanging, etc) so this adds a lot of fat to the client code, as opposed to the traditional SOAP Web client way.
My recommendation, if you aren't using Remoting over TCP or if you don't need the 2-way notification mechanism for remote changes - all these are very cool features of WCF - you don't need to use it.
I have https://mysite/myservice.asmx which is consumed fine with Flashbuilder. When i ported it to https://mysite/myservice.svc, and generate proxy objects, flash proxy objects fails to call any operations. I guess, during web service call, operation contracts are got by https://mysite/myservice.asmx?op=myOp, but in WCF, https://mysite/myservice.svc?op=myOp gives disco file reference. Is there anything done it? Has anyone called WCF from Flex?
It depends on the WCF Config that you have setup, if you provide that I may be able to answer better, but for now try to access the WSDL from https://mysite/myservice.svc?wsdl
I have seen lots of documentation on how Agile Asp.Net Request handling is? I want to know is the case same with WCF Request handling. Can we rely on the fact that the Thread that starts Wcf request handling will finish it?
I am maintaining a Wcf Application where at lots of places ThreadStatic variables are used. Although the code is working but is it reliable? Is it worth changing it or should I keep it as it is?
When creating a WCF service you can set the threading and service instantiating behaviour, by decorating the service implementation class with a ServiceBehavior attribute:
[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Single)]
class SingleCachingHttpFetcher : IHttpFetcher
The above code snippet is from http://msdn.microsoft.com/en-us/library/system.servicemodel.servicebehaviorattribute.concurrencymode.aspx
EDIT
I dit a bit more research and found this article: http://blogs.microsoft.co.il/blogs/applisec/archive/2009/11/23/wcf-thread-affinity-and-synchronization.aspx. It basically says that no, you cannot be sure that the same thread starting the request will be the one finishing it.
EDIT 2
This question has been discussed before at StackOverflow. It links to How to make a WCF service STA (single-threaded) where there is a description on how to create an OperationBehavior which will force a single threaded apartment. The example deals with calling GUI components, but it should work for other single threaded requirements as well.