Let's say Im building an online Poker similar to Zynga's Poker Game.
Is wcf a good backend for that?
Ultimately, you might be best off going with what you know. Since you mentioned WCF, I'm assuming you have some .NET background and it would be easier for you to develop in .NET than learn a new language and framework. If that's the case, several options present themselves:
Go with WCF, since it's the de facto standard in the Microsoft world for building services. Recognize that, with WCF, you have the option of going with a SOAP-based service or a lighter weight RESTful service using WCF WebHttp. As one of the other posters mentioned, you're probably better off going with WebHttp to avoid the overhead of SOAP.
Look at an option like Adobe's FluorineFx which will allow you to program in .NET and gain the benefits of advanced Adobe remoting technologies and protocols (such as the AMF binary protocol) that are otherwise only available on the Java platform.
Practically speaking, I've seen both WCF SOAP and WCF WebHttp services integrate with Flex-based clients nicely. I've never seen Fluorine used in practice with most clients that want to leverage the AMF protocol choosing to go the Java route.
gaming means high traffic and wcf is not lightweight. I recommend simple REST pages implemented on asp.net mvc 3. A more better and simple solution is (if you know java) developing rest pages on playframework with japid module. The best way in my opinion is (if you know scala) implementing it on playframework with scala module. Play with both japid and scala modules is much more performant, light and simple than asp.net mvc 3.
my best,
Serdar Irmak
Related
I want to learn doing RESTful webservices. I have surfed the web some hours and think that I have a good overview over what RESTful services are and now want to build my first service-application. I have a good small project that seems perfectly suited for doing it with a RESTful webservice.
I have seen that WCF has the ability to build RESTful webservices. My question is, if it is reasonable and efficient to write RESTful webservices with WCF or if there are better suited alternatives for writing such services in the Microsoft programing environment.
(As additional information, I already have experience in using WCF, but more in using it in a RPC-way. But I don't think that this is important for my question anyway).
WCF supports RESTful services via the webHttpBinding. This works but doesn't give you alot of control for working with the HTTP protocol itself (although some things got better in 4.0)
The next version is going to have a lot more support for RESTful services. The team are being very open about the new Web API so if you are not about to put something into production then I'd start with the new API
WCF is perfectly valid and very capable of handling REST services - you won't go wrong with that!
And there are a couple of alternatives out there, too - check them out and see which one suits your needs best:
RestSharp
OpenRasta
RestDotNet (clients only)
and probably quite a few more....
I would like to use a technology that is used for communication between services and several thousands of clients. I came to know of WCF and read a little about it. While it looks attractive and has no interoperability issues, i would like to know about other leading technologies which can give me the same features as WCF ? Are there any open source technologies out there ? Also, which is the most widely used technology? I just want this information before i commit myself to WCF.
EDIT: By alternative to WCF, i mean to say that i am looking for a framework that will help me to implement a webservice in linux or any other platform. For example, the wcf simplifies the process of creating a webservice by the use of hard coded .NET applications. Similarly, i need a tool in linux. I came across mono,but found out that it is not complete and not very reliable.
I also provide an Open Source WCF alternative in ServiceStack A modern, code-first, DTO-driven, WCF replacement web services framework encouraging code and remote best-practices for creating DRY, high-perfomance, scalable REST web services.
There's no XML config, or code-gen and your one clean C# web service is enabled all JSON, XML, SOAP, JSV, CSV, HTML endpoints are enabled out-of-the-box. It includes generic sync/async service clients providing a fast, typed, client/server communication gateway end-to-end.
I don't think there is any .net framework with comparable features. But the core protocols of WCF such as WSDL/SOAP are not Microsoft specific so it's not as if you're tying yourself into a particular protocol, you're just choosing an implementation.
To put it another way if you choose to migrate away from .net in the future then I would say the WCF migration would be one of the easiest parts. But if you stay with .net WCF is almost certainly going to be the best implementation available given the investment Microsoft has in it (Azure is built on WCF for example).
I'm working on a project that will have two user interfaces. Web (asp.net MVC) and Desktop (Delphi 2010). It was requested by the customer, so we need to use Delphi.
We're thinking of architecture oriented by services, and so is WCF. To access WCF Services in Asp.Net MVC it is fine but what Need I do in Delphi? My principal doubt is, how to access a service in WCF using Delphi. Is there any way to make it easy?
Can my methods in service return IEnumerable or T[]?
Are there recommendations for this !?
Thanks!
The web services support in WCF provides many features which are not suported by Delphi - MTOM, WS-Addressing, WS-Reliable Messaging and WS-Security just to name a few. If you are designing both parts of the system (web service server and client(s)), you are in the happy situation that you can choose which features to use (as long as they are not dictated by other parties).
WCF fortunately does not 'dictate' to use SOAP. The Interoperability section in this Wikipedia article mentions for example WCF with standard XML (or RSS, or JSON). There is also a WCF binding for REST.
Planning a service oriented architecture is a tough task, so I highly recommend to read through the usual literature for this topic, and find a way to keep it as simple as possible and easy to test and evolve.
Maybe you can take a look at RemObjects SDK: it is a WCF-like solution, and you can use it for .Net, Delphi, Objective-C, PHP, C++, etc.
So you can build a server with RemObjects for .Net, for example TCP + Binary message for best performance (SOAP/XML is much slower!), and a Delphi 2010 client (even FreePascal is supported). Both sides (Delphi and .Net) are compatible with each other, even for the binary message!
My experience with RemObjects is very good: very easy to use and to build services (easier than WCF?), good support and quality etc.
One of the latest SOA framework for Delphi, is our Open Source mORMot framework.
You can use interface to define your Service contract, and access to them locally or remotely using named pipes, GDI messages, or TCP/HTTP. Your contract is defined as such on both client and server side, just like in WCF.
type
ICalculator = interface(IInvokable)
['{9A60C8ED-CEB2-4E09-87D4-4A16F496E5FE}']
function Add(n1,n2: integer): integer;
end;
It handles per-call, per-session, per-user or per-group instance live. See this sample code.
It is secure (with secure authentication at URI level), light and fast.
It uses JSON as communication (lighter than XML), and a RESTful access. It is ready to be consumed by AJAX or WCF clients (the latest after custom marshaling of the interfaces). It was optimized for speed and scalability (with advanced features like balanced custom hosting and per-interface/per-method access security).
The mORMot framework documentation has more than 800 pages, and some dedicated high-level explanation of Service Oriented Architecture design pattern in Delphi. It is integrated with a Client-Server ORM, so you have at hand all needed low-level tools to make a proper Domain-Driven application in Delphi, and other technologies.
at my workplace we are about to start a big project. My boss (a programmer, this is a startup) wishes to use ASMX webservices for this purpose. I do not want to start off a new program using deprecated technology and would like to show him this. I dislike WCF at this moment because it has such an extreme learning curve, but I'd rather learn it than use an unsupported technology.
The problem I'm having is that I can not find any practical list of cons and downfalls when compared to WCF so that I can convince my boss to not use them. And saying "it's not as powerful" is not an adequate explanation. What exactly can it not do that we may need it to do for a webservice that is not meant to be shared externally? (as in, we don't support third-parties using our webservices unless they are using one of our clients. )
In short:
ASMX is
limited to only HTTP as its transport
limited to only being hosted in IIS (no other alternative)
limited to very simple security
limited to SOAP 1.1
WCF is
more flexible in transports: you can use HTTP, NetTCP, MSMQ, many more
can be hosted in IIS, WAS, or self-hosted in a Windows Service, in a console app, in a Winforms or WPF app
has much more security options
supports a plethora of WS-* standards
can interoperate with SOAP 1.1 and SOAP 1.2
In short: WCF is ASMX done right - much more flexible, much more powerful, much more in every respect.
Here's another quite useful comparison of WCF and ASMX: Comparing ASMX and WCF
and last but not least, WCF is also better in terms of performance, as this quite extensive MSDN article quite nicely shows (including performance numbers and graphs): A Performance Comparison of Windows Communication Foundation (WCF) with Existing Distributed Communication Technologies
I've never understood why some people think that WCF is difficult to learn. Try this: create a new WCF Service Project in Visual Studio. Now look at the code. Compare that with the same code you get from creating a new ASMX project. It's not very different.
I have three words for you: WCF. WCF. WCF.
Here are another three about why you should choose WCF: Power. Versatility. Configurability.
ASMX is great if you want to get a quick and dirty web service up and running, although to be honest it only takes maybe a few minutes more to do a WCF one.
The WS-* are really hard to implement with asmx: transactions, reliable messaging, security... etc etc.
And later the bindings: you can change the communication just by configuration, the asmx is just http.
WF exposing services and AppFabric works over wcf.
I would not have doubts, today wcf is the best option for starting a project that needs services.
A .net desktop application will send information to a central server, there will be potentially thousands and thousands of deskop apps sending info to my server(s).
The data will be small in size.
Would .net web services be good for this scenerio or would WCF be better suited?
What are the pros/cons?
I'd go with a WCF REST-based service, because you'll be able to transmit pure data without the overhead of the SOAP header (and other envelope nonsense) that comes with the SOAP-based classic .asmx web service.
the possibilities for throttling, concurrency, etc. are far more developed within wcf.
its a little bit more work in the beginning, but i guess that it's better suited for scenarios where you need to have full control over your bindings.
WCF is a more robust approach to SOA. Microsoft is committed to making it the primary framework for building the next wave of Microsoft business applications. The functionality available already, early in its lifecycle, is superior to plain old web services. It's only going to get better. By going with WCF early, you will be able to ride the wave and take advantage of future new functionality.
In some cases depends on the type and amount of data to send.
WCF will give you more options to tweak your calls.
On the other hand, I can't think of advantages of implementing asp.net web services over WCF. In WCF you could also implement plain 'old' web services
ASMX is like remoting, it's still around because it shipped with 1.0, but you shouldn't use it anymore if you are starting a new project. WCF will give you many more features and better tooling support.