I want to host multiple WCF services in windows service but I am unsure if hosting multiple WCF services is an expensive process? Can someone please guide?
It depends on the complexity of the service itself, but generally, they are not resource intensive.
It will also depends of the number of connected clients and requests you will get.
The rule is very simple here. You need to decompose your system requirements into the right level of granularity that minimizes the cost of implementation versus the cost of integration. Too many services and your integration costs will suffer. Too few services and your implementation costs will suffer. My personal experience is that if any service has more than 10 methods you really need to start looking into your design and the methodology you have used to design it like that. Also please note that services with too many methods do not scale that well neither.
Related
I wonder if anyone could share their thoughts on my question regarding web based APIs (we use Microsoft stacks)..
We are currently in the process of building an infrastructure to host web apis across our business.
As a organisation we have seperate business areas that provide services to our customers. These individual areas of our business generally have their own best of breed IT system. Offering APIs is something we've long thought about and we have started the design process.
The APIs we aim to offer shall be web based (.NET/webAPI/WCF etc.) and will largely (99%) be consumed within our organisation but some may be exposed externally in the future should the requirement arise (new mobile app may need to use the services etc.)
I'd love to hear your thoughts and experiences around how you architected yuor farms. I understand its quite an open question without understanding the crooks of our requirements but its more general advice/experiences I'd like to hear.
Particularly we are trying to decide whether we should design the infrastrcuture by:
1) Providing each area of the business with their own API server whereby we shall deploy each web API within a new application inside IIS.
or
2) Setup up a load balanced web api farm whereby we have say 2/3 iis web servers, all built the same, hosting the same web apis but the business areas will all share the same server effectively. Each area would have a segregated site within iis and new APIs shall be setup under new applications inside their respective web sites.
I dont foresee us having thousands of APIs but some will be business critical so I'm certainly bearing resilience in mind which is why as much as I like each business area having their own API server, I'm being swayed towards the option of having a load balanced farm which the whole business shares.
Anyone have any thoughts, experiences etc.?
Thanks!
That's a very interesting question, and i'd love to hear what others might think. I'm no big expert, but here are my two cents.
It seems to me, that the answer should be somewhere in between those two options you specified. Specifically, each critical business area, should get their own resilient, load balanced farm, while less critical services can utilize single machine deployments. Critical business area may not mean only one API, but can actually be a group of APIs, with high cohesion among themselves.
Using option 1 environment to full extent can be hard to maintain,
while utilizing option 2 fully, can be inefficient in terms of redeployment if (or better yet, when) business logic changes. Furthermore, i think it will be possible for greedy APIs to hog resources in peak traffic, making other services temporary less performant (unless you have some sort of dynamic scaling mechanism).
There are different approaches to implement brokered messaging communication between services using Service Bus Queues (Topics):
CloudFX Messaging
QueueClient
WCF integrated approach
Which of those approaches are more useful in which cases?
Any comparison of performance, abstraction level, testability, flexibility or facilities would be great.
OK, now that I understand your question better, I see where the confusion is.
All 3 of the options that you are looking into are written by Microsoft.
Also, all 3 of those options are simply an abstraction - a client interface into the service that MS is providing.
None of them are faster, slower, etc. However, I would say that if you went the WCF route, then you can more easily abstract the technology choice a bit better.
What I mean by that is - you can develop a "GetMessage" contract in WCF that points to the service bus... and then later on change the design, and configure WCF to point to some other service and you wouldn't have to change the code.
So, that's one advantage for WCF.
That being said, CloudFX is built by Microsoft to give extra common functionality around the usage of the Azure Service Bus ... so don't ignore that. Look into the benefits of that API and decide if you and your team need those features.
Lastly, QueueClient is simply what CloudFX improves on, but adds no benefits like WCF. So you probably don't want to go with this route (considering your other 2 options).
Keep in mind that Azure uses a REST API under the hood for most of the communication... and so you might hit some unexpected performance issues if you don't configure your application correctly: http://tk.azurewebsites.net/2012/12/10/greatly-increase-the-performance-of-azure-storage-cloudblobclient/
I have a question. I would like to serve a series of services made with WCF. The client that consumes the services is also .NET with WCF. I would like to have high speed of access, fast response, transport medium to small Data Contracts (primary .net basic data types). The distribution will be over internet, I´m looking for reliability, availability and basic security.
I don´t want to use WsHttp, because my only client is based on .net and I will have almost 150 clients requesting the services.
What do you suggest to use for binding? Are there any disadvantages, risks, etc?
Thanks in advance!
Since you plan to use simple types and small data contracts, the binding you use is nearly irrelevant compared to the latency introduced by going over the Internet. So, the right answer is to use the one which is easiest to manage and the most secure.
I recommend that you host the app in IIS and use a wsHttpBinding and take all the manageability goodness that goes along with it. It will also happen to be interoperable, and while that is irrelevant today, it is just free, so why not?
And, please consider the granularity of your service. You know your customers better, but on the wide open Internet, stuff happens. Because the round trip time over the Internet is variable and impossible to control, it could take milliseconds or seconds or may not get there at all. So, you should take fewer trips with larger payloads if possible, and use all sorts of caching and async operations to make the app appear "fast".
There is a good article on choosing a binding by Juval Lowy here:
http://www.code-magazine.com/article.aspx?quickid=0605051&page=3
Generally the advice is not to use net tcp binding over the internet. Have not heard of anyone doing it. Although it may work if the ports are open all the way and no one blocks the calls.
Test it with nettcp, if it does not work you just need to change the configuration.
The most important thing is to consider your security needs. Do you just need point to point, then basichttp over ssl. Do you need end to end, then wshttp with message encryption.
According to your scenario, NetTcpBinding is the binding of choice. As you are sure that client will be WCF, no need for interoperability.
Have a look here in Programing WCF Services book.
The only thing I'm not sure about is firewalls. If you have to get trough on of theses, maybe some WS binding could be more appropriate.
Looking to hear from people who are using WCF in an enterprise environment.
What were the major hurdles with the roll out?
Performance issues?
Any and all tips appreciated!
Please provide some general statistics and server configs if you can!
WCF can be configuration hell. Be sure to familiarize yourself with its diagnostics and svcTraceViewer, lest you get madenning cryptic, useless exceptions. And watch out for the generated client's broken implementation of the disposable pattern.
I've been recently hired to a company that previously handled their client/server communication with traditional asp.net web services and passing dataset's back and forth.
I re-wrote the core so now there is a Net.Tcp "connected" client... and everything is done through there. It was a week worth of "in-production-discoveries"... but well worth it.
The pain points we had to find out late in the game was:
1) The default throttling blocked the 11th user onward (it defaults to allow only 10).
2) The default "maxBufferSize" was set to 65k, so the first bitmap that needed to be downloaded crashed the server :)
3) Other default configurations (max concurent connections, max concurrent calls, etc).
All in all, it was absolutely worth it... the app is a lot faster just by changing their infrustructure and now that we have "connected" users... the server can send messages down to the clients.
Other beautiful gains is that, since we know 100% who is connected, we can actually enforce our licensing policy at the application level. Before now (and before I was hired) my company had to simply log, and then at the end of the month bill the clients extra for connecting too many times.
As already stated, configuration nightmare and exceptions can be cryptic. You can enable tracing and use the trace log viewer to generally troubleshoot a problem but its definitely a shifting of gears to troubleshoot a WCF service, especially once you've deployed it and you are experiencing problems before your code is even executing.
For communication between components within my organization I ended up using [NetDataContract] on my services and proxies which is recommended against (you can't integrate with platforms outside of .NET and to integrate you need the assembly that has the contracts) though I found the performance to be stellar and my overall development time reduced by using it. For us it was the right solution.
WCF is definitely great for enterprise stuff as it is designed with scalability, extensibility, security, etc... in mind.
as maxidad said, it can be very hard though as exceptions often tell you nearly nothing, if you use security (obvisously for enterprise scenarios) you have to deal with certificates, meaningless MessageSecurityExceptions and so on.
Dealing with WCF services is definitely harder than with old asmx service, but it's worth the effort once you're in.
supplying server configs will not be useful to you as it has to fit to your scenario. using the right bindings is very important, as well as security, concurreny. there is no single way to go when using wcf. just think about your requirements. do you need callbacks, what are your users? what kind of security do you need?
however, WCF will be definitely the right technology for enterprise scale applications.
I've inherited this really weird codebase where they've built an external web service over a bunch of internal web services just to add authentication/authorization using WS-Security, WS-Encryption, et al. Less than a month into this engagement, I'm already feeling the pain of coupling volatile components through rigid WSDL, esp considering some of them use WCF and other choose to go WSDL first. Managing various versions of generated proxies and wrappers at various levels is a nightmare!
I'll admit the design is over-complicated and could have been much better, but my question essentially is:
Would you ever build a web service just to provide a cross cutting concern over a bunch of services?
Would this be better implemented as web service handlers?
and lastly...
Would you categorize this under the Web Service Gateway pattern?
I saw that very thing being built one year ago. I almost cried when the team took months to build 4 web services, 2 of which simply wrapped other internal ones, using WCF and some serious encryption. The only reason they wrapped the internal ones was to change the potential error numbers coming back.
So, would I ever intentionaly do that? Nope.
Would it be better implemented as almost anything else? yep.
Would I categorize it under the WTF pattern? absolutely.
UPDATE:
One thing I just remembered is that there is an architecture called "Enterprise Service Bus" It's purpose is to provide a common interface into other SOA systems. This way it doesn't matter what the different applications use for their end point mechanisms (WCF, WSE 1/2/3, RESTful, etc).
BizTalk is one example of an ESB and there are many other off the shelf programs that can be used. Basically, your app passes a message to the ESB and it handles sending that message, in a reliable way, to the other systems as well as marshalling any responses back.
This also means that you could insulate other applications from many types of changes to the end points. Of course, if the new end points require additional information, then you'd have to modify the callers. However, if all they are changing is the mechanism then a good ESB would be able to handle those changes without impacting your app.
I have seen similar implementations if you are exposing the services to the outside world and if you need to tighten down the security..check this MSDN column..