I'm confused about the usefulness of WCF in consuming non-UTF services. I decided to try and give it a go, in lieu of .NET 2 web services, and quickly discovered that out-of-box it cannot consume ISO-8859-1 web services. After googling a bit I learned that you need to create a custom message encoder (i.e. http://msdn.microsoft.com/en-us/library/ms751486.aspx).
Comparably, if I wanted to use .NET 2's web service model, I just add a reference and it works - no need to write a custom encoder. I've decided to use the easier of the two methods, since I can't justify writing and testing a bunch of code I don't need.
I am however curious why anyone would use WCF when they could use the faster 2.0 method. This is a rudimentary question - I'm new to web services, and just using them to pull data from several third party vendors. All I need is the ability to consume the service, throw some credentials, call methods, and get objects back - I'm assuming WCF goes above and beyond that, somehow.
Classic web services are by no means 'faster' to employ than WCF services. WCF has only a small learning curve to get going with stuff we used to do with webservices in the past.
Maybe in very simple scenarios you can accomplish the same thing with an asmx web service as you can with a WCF service using a basic HTTP binding, but among the numerous benefits of the framework (industry wide standards, multiple protocol support), is the fact that alot of the plumbing has already been done for you (in terms of communication, security etc), allowing you to focus on your business logic.
Maybe asmx provides what you need, but the technology is deprecated. If you do a google search, there is tons of websites comparing the two. I would advice to take the oppertunity to start learning WCF!
Hope this helps.
If all you're doing is consuming an existing non-WCF service, then the choice to go with WCF is probably only going to depend on other factors, like if you anticipate consuming WCF services in the future and want to have a uniform codebase.
WCF is an umbrella with a single interface for multiple "bindings" such as HTTP-with-REST-or-SOAP, named pipes, MSMQ, TCP (formerly .Net Remoting), all mixed in with different options for security, authentication, transactions, reliability, etc. So if you were consuming multiple services that were exposed in a variety of ways, then WCF would help you tame them all with a single API.
Related
I have been developing n-tier applications using .NET for many years. But I still have no idea how to distribute the tiers/layers (dll) to other servers.
Let say, I have an MVC web application with 4 projects, i.e. MVC (UI), Business, Service and Data. Everything works fine if all class library dlls are in one server.
If I want to scale out the application by distributing the Service layer (dll) and Data layer (dll) to other 2 servers, should I convert the class library to WCF Service Library project (with TCP or pipe as communication protocol for better performance) ? Or should I use other technology like .NET remoting or Web API?
Will that be a lot of work?
Is that one of the purpose of creating multi-tier application?
Thanks.
Update:
Do you have any links (from Microsoft) that explain in detail how to scale out an n-tier architecture application to multiple server by distributing the DLL?
If I want to scale out the application by distributing the Service layer (dll) and Data layer (dll) to other 2 servers, should I convert the class library to WCF Service Library project (with TCP or pipe as communication protocol for better performance) ?
Yep, since they are on different machines, you need some kind of communication mechanism that goes beyond simply DLL invocation.
Or should I use other technology like .NET remoting or Web API?
Which approach you choose depends on many factors like complexity, performance...There are many options like
WCF webservices
Simple REST calls with WebApi
a message bus i.e. NServiceBus
...
Obviously remote calls will also be slower having a potential impact on performance etc.
Will that be a lot of work?
It will be more work and in my opinion that "more work" should really be justified. Keep your architecture as simple as possible or better, only as complex as really needed.
An alternative approach could be to have some deployment pipeline that deploys your entire application on different server instances and have some intelligent load balancing strategy. The only thing you need to pay attention to in that case is to properly share the sessions between your instances (stateless would be better ;) ).
My 50 cents...
As far as I know WCF replaced .NET Remoting (MSDN).
Anyway... Someone before me said. If you don't have to scale the application, do not do it. Communication cost alone between services of any kind will slow things down considerably. Probably to extent, where it would be slower than it is now (which I am assuming is the reason for scaling).
Prior to scaling, I would first see where the bottleneck really is. For instance, if the problem is your DB server, then moving services and data layer to another server is useless, as you will still be using the same database. So, you need to first find out what your bottelneck is.
The easiest and least painful way to scale (in my opinion) would be to just add another IIS server and a load balancer that would direct traffic to either one of them. You would need to store sessions in a database or use dedicated server, but that is about all the change you will need. Plus, if one of your server fails, one will still operate.
By default, avoid premature optimalization.
If you have a only web site, I would keep it as simple as possible and only create logical layering. There are a number of options: typical 3 tier, onion architecture etc. The key is that later, if really really needed, you could still refactor your code and make your data layer a separate physical layer. But unless you are creating a new Amazon or something, this will probably not be the case.
If you are in the situation, for example, that you have a web site, but also have to expose a web api; you could choose to have the web site consume the web api. In fact, your web site would then become a very thin layer (maybe not even using ASP.NET MVC) because most of the logic would be in the web api.
PS - .NET remoting is old technology, consider WCF or Web API instead.
I am at the start of a new project but I am not sure about some architectural choices.
I was hoping that you guys could share me your vision on this.
The client wants an internal website to manage their clients, projects, stock/products,…
Next to this they also want a website for their clients where they can view the products and order them. So for the external website only a small part of the db will be queried while the internal website will be much bigger.
At first I was thinking about using a WCF service for all businesslogic and repository.
But now I am not sure since I know that only a small portion of the actual logic will be used for the external part.
Using WCF as an extra layer always brings a shitload of extra work and complexity to the project. Is it better to just reference the business/repository layer in both website projects or make use of webAPI in the external website?
Really I need to hear some other opinions before I decide what to do.
There is nothing inherently wrong with going WCF, business layer assembly, or Web API. All have pluses and minuses.
WCF would make the most sense if you may someday have a many different clients needing access to the data/business logic and these clients may need to communicate differently (i.e. HTTP, MSMQ, full duplex, etc.)
Business Layer assembly would make sense if you are quite sure the data/business logic will not need to be accessed by clients other than the 2 web applications you are developing. That's not to say you're boxed in doing this though either. You could always start here and later remove reference to the assembly, encapsulate access to the assembly within WCF or Web API, and then reference WCF or Web API from web applications.
Web API is a good choice for several reasons. It provides the ability for many different clients access to the data/business logic without all of the overhead that comes with WCF. Additionally, if you have non .NET clients you need not worry about some of the tweaks you would have to potentially make on WCF bindings. You can also take advantage of some of what MVC provides you within the Web API such as model binding and validation.
I am looking to get into doing some iOS development for a nice addition to a project i am running.
The main project is currently written in C# and is mainly asp.net with a few windows services.
I would like to incorporate this to be able to develop a basic iPhone app as a proof of concept.
From what i have read and understand, its generally best practice to use JSON as a communication medium for iOS.
I am thinking about using WCF to create the API methods so the iOS app can connect to these services to get the data.
Are there any nice tutorials to do this?
Take a look at:
Developing RESTful iOS Apps with RestKit
I do this all the time. WCF Data Services (OData) are the way to go. With OData services, you can specify that you want JSON response by passing (Accept - Application/JSON) in the HTTP Header and OData will return JSON to you.
I have used several libraries for getting OData (which are REST services) from iOS. Microsoft's iOS OData implementation is pretty lame. RESTKit does a really good job for what it handles, but is really painful if you have to do something that it doesn't. I have also used ASI - it is much more flexible than RESTKit, but is not without problems. I ended up writing my own and it suits me just fine.
For a beginner, I would recommend using ASI over RESTKit. RESTKit, while doing a lot of the heavy lifting for you, takes a bit to get working right.
There are two things that are not standard when receiving JSON responses from OData.
1. All responses are captured in a JSONDictionary with the key of "D".
2. Dates are serialized to the JSON standard (number of seconds since 1970), but they are placed in a string like so: /Date(1212353), so you will have to parse out the Date() part of the string before you can use it.
RESTKit doesn't handle either one of these issues natively, so you will have to deal with them if you choose that route. Personally, I would go the ASI route until you learn enough to write your own.
I am considering open sourcing my solution - if I do, I will update this response with the link to it.
---UPDATE----
Just to be clear - if your server side system uses WCF Data Services, otherwise known as OData, then with minor tweaking, RESTKit plays nice with it. If your services are traditional WCF Services (i.e. SOAP Binding), then you will not be able to get JSON out of them because they are bound to the SOAP protocol (Unless you create a custom Behavior to translate it - which I wouldn't do). It all depends on what your services do in essence. If your services are typically data exposure/manipulation (i.e. addCustomer), then you should expose them as OData. If they are truly operations, then you should maybe consider exposing them as actions from a MVC site. Either of them can get you REST services using your existing infrastructure and platform.
If you're using Objective-C to develop the iPhone app, I'm not sure WCF is the best web service technology to use on the server. Check out ServiceStack to create a RESTful service.
Refer following link:
http://www.kotancode.com/2011/04/26/backing-your-ios-app-with-wcf-json-web-services/
It has included comprehensive code samples as well.
I'm developing an ASP.NET web site with a n-tier backend utilising nHibernate - all good. As part of the development a large portion of the Interface will be written in Flash or more specifically Flex 4.5. In previous projects I would've created a webservice to broker data and actions between the Flash Interface and the business logic, however I'm looking for a more flexible solution that would allow data / objects to be easily passed to and from the service endpoint without too much redevelopment and with the onus of easy consumptionby Flex and others.
Enter WCF that seems to provide a robust server-side solution where we can use the existing POCOs in the business layer that can be easily serialised across the wire, amongst other things. Unfortunately I'm unsure (and inexperienced in this field) at the best direction to enable the communication from my C# WCF webservice to my Flex application, there certainly seems a few directions but without a clear and concuse path to take.
I would also like the service to be able to communicate to other non-Flash clients so locking myself into one particular route is something I would like to avoid. After some research I believe the best approach is for the WCF service to output lightweight data (i.e. JSON) or POX that should be easily consumed by Flex and other clients. Unfortunately my prototyping has been rather frustrating where the only end to end route I've got working is to Import the Webservice into the application and setting the WCF service to use basicHttpBinding, something I believe I should be avoiding as we need to implement somekind of security and the desire to keep communication as lightweight as possible. In addition, File Uploading would have to be factored in at some stage.
In short, what is the best method to have Flex communicating with WCF (and that's even if WCF is better than say ASMX) given the brief scenario above? In addition, I would really appreciate any tutorials or links that would demostrate an end-to-end system.
Thanks in advance - S
Flex has all problems and I wish flex and flash die soon if adobe is not keep up with today technology. I had a same problem to integrate ArcGIS-flex > WCF > CRM(Oracle). I found a solution with third party. This may help you if you decide to implement your solution using WebOrb
http://cookbooks.adobe.com/post_Connecting_Flex_4_with_WCF_Services-17006.html
http://www.themidnightcoders.com/products/weborb-for-net/developer-den/technical-articles/flex-net-integration.html#c1057
I searched a lot, apologies if I missed something obvious. And thanks for reading the looong text below.
I have a 3rd party (read: No way to access/change the source) application here. It consists of a server (Windows service) and an API, that talks to the server via remoting.
For several reasons I'd like to expose this API over WCF (see subject: One reason is a WCF client).
The problem is, the API is
unchangeable (follows 3rd party rule)
using no WCF itself (it is serializable/MarshalByRef where necessary for Remoting)
using lots of interfaces and internal implementation classes
Following 1 I cannot use the (quite intrusive) WCF attributes myself.
Following 2 the API itself can be used "over the wire" (they support remoting via TCP and HTTP), but remoting is not good enough for me.
Following 3 I have mostly interfaces (which WCF won't handle well, cannot (de-)serialize). The implementation classes could be sent over, but - I cannot access them.
The general usage for this API is based on a single interface (and its members/properties), so the typical usage is like
var entryPoint = new ApiClientEntryPoint();
entryPoint.SomeMethodCall();
entryPoint.PropertyExposingAnInterface.SomeOtherMethodCall();
and so on.
What I'd really like to do is generate (with as little effort/code as possible) a proxy (not in the typical WCF sense) that I expose via WCF and that serializes this hierarchy mapping every call/property on the client to the real thing on the server.
The closest I've come so far is stumbling upon this project, but I wonder if there are more/other tools available that take a medium to large part of this work off my shoulder.
If there are any general other advices, better approaches to wrap something preexisting and unchangable into WCF, please share.
My advice is to use a facade pattern. Create a new WCF service that is specific to your usage and wrap the 3rd party service. Clients would talk to your service and you would talk to the 3rd party. But clients would not talk to the 3rd party directly.
This would work in most but not all scenarios. I'm not sure of your particular scenario so YMMV.
BTW you can look at WCF RIA Services which is good for exposing services to Silverlight where you can avoid doing a lot of the hand coding of service stuff. But again depending on your particular scenario it might not be the best way to go.
Edit:
It's now clear that the API is too big and/or the usage patterns of the clients are too varied in order to effectively use a facade. The only other thing I can suggest is to look at using a code generation tool. Use reflection (assuming it is a .NET API?) to pull apart the API and then codegen new services using the details you gathered. You could look at the T4 templates built into Visual Studio or you could look at a more "robust" tool such as CodeSmith. But I'm guessing this would be some painful code to write. I'm not aware of an automated solution for this.
Is the API well documented? If so, is the documentation in a parseable format such as XML or well-structured HTML? In that case you might be able to codegen from the documentation as opposed to reflecting through the code. This might be quicker depending on the particulars.
Okay, hair brained scheme #1 on my side:
Use Visual Studio Refactor menu to "extract interface" on 'ApiClientEntryPoint'.
Create a new WCF service which implements the above Interface and get VS to generate the method stubs for you.
'For PropertyExposingAnInterface.SomeOtherMethodCall' You will have to flatten the interfaces as there is no concept of a "nested" service operation.
Your only other option will be to use T4 code gen ,which will probably take longer than the above idea.