I've very new at WCF, and I'm creating a prototype application to learn, which might turn into a commercial application. I understand the very basics of WCF, and I have my application WCF functional, at a basic level.
What are some tips experienced WCF users can give regarding pitfalls and steps I can take to make the app rock solid, at least regarding the WCF layer?
Couple of points to ponder:
make sure to implement rock-solid exception handling on your server side - implement the IErrorHandler interface on each service, define proper fault contracts
make sure to enable WCF tracing on the server side - those message logs are eminently useful when diagnosing problems!
make sure to think about versioning - make sure to use namespaces for both your service contracts and data contracts that will allow you to distinguish later version from the older ones (by means of the contract namespace)
think hard about your production hosting - IIS seems like a logical choice, but it's typically plagued by too many issues and problems that you don't have if you self-host. It's a bit more work yourself to create all those hosts - but it pays off with increased stability and better control on your side
Use security for your web service, particularly those bindings that support digital certificates.
Ensure your web service is interoperable with other web service frameworks, so that potential clients do not necessary need to be created using .NET and WCF.
Allow for endpoints (methods) to be retired in case they become obsolete. This allows clients of your web service to be informed of these retired endpoints so that they can be updated accordingly. Your retired endpoint could inform callers of what endpoint they should be using instead.
i am new to WCF but i learn this recently and thought to share with you.
if you are hosting your services on IIS then its best practice to make this a new account that you can control the direct privileges too, since NT AUTHORITY\NETWORK SERVICE
uses the default and can have a bit higher level of permissions. You can change this under the Application Pool in IIS that your website hosting WCF is running as.
my2cents
Related
I need to create a web service to collect data from my customer’s applications.
Those applications are programmed with different technologies and they all have one thing in common: they can consume plain SOAP Web Service.
I already have a WCF Service that could be exposed but as it was built for internal purpose only, I never had to secure it.
I did read a lot of articles on how to secure WCF service and how to consume it from a Microsoft client application. However, I'm really concern about the customer’s non-microsoft applications abilities to implement a standard WCF Service security. I must keep in mind that some of them might be stateless and unable to hold on to a session or anything that might be required by a secure WCF Service.
So here are the options I have right now.
1) Add username/password parameters to each WCF function and perform a credential check on every call. (I do have an SSL certificate... is it enough to consider this option as secured?)
2) Drop my WCF Service and create a plain SOAP Web Service with username/password parameters as mentioned in option #1 to be closer to my customer’s applications capabilities.
3) Implement standard WCF security and let the customers find a way to deal with it on their own. (The real question here: is WCF security simple enough to be implemented by any SOAP client?)
4) Change my name and move to Jamaica with my customer’s money before they find out that I’m a Web Service security noob.
5) Something else…
So what is the my best option here?
Yes, I can offer the option we use. It sounds like you want basicHttpBinding.
We have a WCF web service using basicHttpBinding and set IIS to use basic http authentication.
Therefore non-.NET clients can consume it easily (basicHttpBinding) and we can give them an Active Directory domain account that allows them access via IIS. No usernames / passwords to constantly send back and forth through the web service and it runs over HTTPS for security.
It's currently being consumed by PHP, Java and .NET clients. Yes, .NET clients can still import this as a service reference which makes thing like trapping FaultExceptions easier.
No solution is perfect for everyone but works great for our needs.
Yes, but certain configurations favour certain vendors. See the WCF Express Interop Bindings project on CodePlex:
http://wcf.codeplex.com/wikipage?title=WCF%20Express%20Interop%20Bindings
They offer settings for interop with:
Oracle WebLogic
Oracle Metro
IBM WebSphere
Apache Axis2
The Oracle Metro (previously known as SUN WSIT) stack is by far the most advanced as regards the WS-*/Oasis standards.
Please advise me on this.
I have both Wcf service (which will be responsible for highly secured data manipulations) and Web App in same Server and i will access this Web application (Which will consume this Wcf service for data manipulation) over internet.
1) Is this a good practice to have both in same server.
2) What WCF Security i have to choose either Transport or Message security.
3) What type of architecture i have to use (Eg: 3 tier or N- Tier)
I use VS2010 and .Net framework 4.0 and Sql Server 2008 for development.
Thanks in advance.
It is not a simple question to answer if it is a good practice to have the WCF service on the same server as the app. If you want ot shield the service as much as possible you could of course put it on a separate server behind the firewall only allowing the web app to access it. But then it does sound somewhat superfluous to create a service at all. Does it provide methods that should be accessible to a client? -- When determining the deployment scenario you also have to measure cost to security and scalability. More servers means higher costs both for buying the servers and for maintaining them.
I think you can use both transport and message security, but using message security you could transfer the messages on http, which means less traffic than https.
About the number of levels in your application, this also depends on the nature of the application. You might even consider CQRS or similar architectures. But if you have proper segregation of the layers and they only depend on the next layer you can always insert new layers if needed. Speaking of which: If you plan to use the WCF service as an internal DAL, you could also prioritize to just create a simple DAL with a proper interface, which could later be changed to a WCF service.
There are many good reasons for creating a web service and it gives you the opportunity of scaling on more servers later on, so I am definately not recommending against a web service, just saying that it might be overkill or introduce a larger attack surface in your application.
Performance wise you might get a boost by using tcp bindings rather than http, but connecting external applications is easier on http if some non wcf client is involved.
Perhaps this post contains more questions than answers, but you are the only one who can decide given the brevity of your description :)
I have two related questions about Web services:
(1) I'm currently writing a set of applications, and it occurred to me that maybe I'm not using the right tool for the job. Here is the spec:
There are many Windows servers behind different VPNs and firewalls.
Each of the servers has a Windows service running, that reports various information about it to a centralized server, via a Web service, both of which I've written, and have access to.
So I'm both the producer and the consumer, and I'm staying on the same platform (.NET). Maybe a web service isn't the way to go? I'm using one purely because it's easy to write and deploy, and I'm the most comfortable with them. Should I really be using WCF for this?
(2) In the web service, I'm creating a State object to represent the state of the server, and sending it as a parameter. However, adding a service reference creates a proxy of the State class. It seems gacky to copy the properties of the State object to the proxy, and then send the proxy. Should I just replace the proxy class with the real class in the auto-generated code (i.e., include a reference to the State class instead)?
By "web services" I assume you mean an ASMX? I would go with WCF is possible, simply because you lose nothing but gain lots of flexibility. You could, for example, switch from XML-over-HTTP to Binary-over-TCP through a simple config change.
I would suggest to use WCF and use the Net.Tcp binding. It should be efficient enough for 300 clients. For the proxy class issue use the /reference option for the svcutil tool when you generate the proxy. This will allow you to share classes between server and client. I would not use this option if interoperability was a concern but since you stated that you develop both the clietn and the service and all in .Net it is a valid use in your case.
Your distinction between "Web Services" and WCF is a false distinction.
ASMX Web Services is the original .NET SOAP Web Service technology, introduced in .NET 1.0. It has been replaced by WCF, which can everything that ASMX can do, plus a whole lot more (including support for the WS-* standards).
Microsoft now considers ASMX Web Services, and the XML Serializer they're based on, to be "legacy technology". See "Microsoft says: ASMX Web Services are a “Legacy Technology”".
With WCF, since you have control of both sides of the operation, and can share the .dll in which the service contract is defined, you can and perhaps should be using ChannelFactory<IYourServiceContractHere> instead of auto-generating those ugly proxy classes with service references.
Here's the first hit I found on this topic: http://blogs.msdn.com/juveriak/archive/2008/02/03/using-channels-vs-proxies-in-wcf.aspx
If it is platform independent, I would certainly recommend WCF.
I've done exactly what your describing to great effect across more than 300 locations. I don't think you made the wrong call.
Another thing you could consider that would work well is using MSMQ. In this case, however, you'll either need to write event triggers (COM) or an event queue processing service.
I am learning wcf but I have trouble understanding the benefits. Is there ever a time I would want to use traditional web services?
I read another thread with these benefits:
Opt in model for members using a certain attribute
Better security
No need to worry about binding (can't understand how this is true)
No need to worry about the xml
I read Programming WCF Services however this was an advanced book a bit like CLR via C#. I am now reading Learning WCF Services and will read Essential WCF (is recommended).
What would happen if I use a normal class to try to talk to a web/service reference? I know this sounds really naive, it's just my lack of experience in web services.
I am coding some WCF services so I am getting exposed to the specifics. They are interacting with a SOAP web service provided by my web host so I can get stats on my site. Is there anything wrong in this approach?
Thanks
WCF is a unified programming model for developing connected systems. What this means is that you use a single framework to develop service-oriented solutions. WCF allows you to keep your service implementation relatively unaware and care free of what's going on under the covers as far as how your service is consumed by clients and communication is handled. This allows you to take your service implementation and expose it in various ways by configuring it differently without touching your service implementation. This is the unified part. Without WCF, you have to get familiar with a framework specific for a particular communication technology such as ASP.NET asmx web service, .NET remoting, MSMQ etc and usually those frameworks impose on your service implementation and creep in such as using WebMethod attribute or having to derive from MarshallByRefObject object etc and you just can not take your service implementation and easily expose it over another communication stack. If I have a service that adds two numbers, why can it not be exposed over http or tcp easily without having to worry about low level details? This is the question in your post regarding binding. Binding allows you take a service and configure it so that it can be exposed over different transports and protocols using different encodings without ever touching your service implementation.
Is there ever a time I would want to use traditional web service?
Web service uses well defined, accepted, and used standards such as HTTP and SOAP. So if you want your service to be consumed by wide range of clients, then you would want to expose your service as a web service. WCF comes with pre-configured bindings out of the box that allows your service to be exposed as a web service easily: basicHttpBinding and wsHttpBinding. You may also want to consider RESTful services which is an architectural style that fits more natural with the HTTP model. WCF supports RESTful services as well
What would happen if I use a normal
class to try to talk to a web/service
reference? I know this sounds really
naive, it's just my lack of experience
in web services.
WCF service can expose the wsdl for a service just like ASP.NET asmx web service does. You can generate a client side proxy by simply adding a service reference to your client project. There is also a command line tool called svcutil that also generates the client side code that allows you to easily communicate with the service. The client side service class basically mirrors the service interface. You create an instance of the client side proxy for the service and then simply call methods on it just like any other .NET object. Under the covers, your method call will get converted to a message and sent over the wire to the server. On the server side, that message will get dispatched to the appropriate service method.
I hope this helps a bit.There are lots of online content such as videos on MSDN and channel 9 that you check out. The more you pound on it and expose yourself to it, the clearer WCF will get I am sure. Also, WCF is THE framework Microsoft recommends to develop connected system in .NET. The other technologies ASP.NET asmx, WSE, and .NET Remoting will most likely still be available going forward but may not be supported and developed further.
There are a number of existing approaches to building distributed applications. These include Web services, .NET Remoting, Message Queuing and COM Services. Windows Communication Foundation unifies these into a single framework for building and consuming services.
Here is a link from MSDN Why Use Windows Communication Foundation?
WCF is really the "new" standard and new generation of web service - and even more generally, communications - protocols and libraries for the .NET world.
Whenever you feel the need to have two systems talk to one another - think WCF. Whether that'll be behind the corporate firewall in your company LAN, whether it's across the internet, by means of a direct call or a delayed message queueing system - WCF is your answer. Mehmet has written a really nice summary of how WCF is the unification of a great many communication standards that existed in the Microsoft world before WCF.
I would think with the "Learning WCF" book, you should be a lot better off than with Programming WCF - that's quite advanced stuff already!
One of the mainstays of WCF is the architecture that you always talk to your service through a proxy - whether that service runs on the same machine using NetNamedPipe binding or halfway around the world in Down Under on a server - no difference, you always go through a proxy. That then also allows WCF to be so extensible - thanks to the proxy always being between the client (your application) and the service, it offers excellent ways of extending the behavior and the inner workings of WCF to your liking and needs.
WCF basically builds on SOAP communications - so interfacing and using existing SOAP services should be no problem at all. With the WCF REST Starter Kit and in the upcoming .NET 4.0 release cycle, WCF will also extend its reach into the REST style web communications, if that's ever going to be a requirement of yours.
All this really shows one of the biggest strenghts of WCF: it's a unified and extremely flexible and extensible communication framework, that can handle just about anything you throw at it. That alone is more than enough reason to learn WCF (which can be dauting at first, I agree!), and you won't regret the effort you put into this endeavor.
Marc
Have you a specific application you are writing for, or just getting your feet wet?
Google protocol buffers, is a very good choice of communications. John Skeet & Marc Gravell have both done C# implementations. See here
I need some direction related to this topic; maybe I am missing the obvious.
I dont see a contrast between WCF bound to HTTP and strongly typed web service. Why would this be any different?? I agree there are some development nuances especially related to XmlSerializer in ASMX vs WCF and a plethora of Microsoft jargons. Short of these; i only see parallels
DataContract=WSDL Type
ServiceContract=WSDL (aka service definition)
OperationContract=WebMethod
Operationally, I understand the binding can be numerous with WCF instead of getting locked down to HTTP, which can involve heavy construct and tear down. But for loose coupling it will all be web services.
Are there other operational differences??
Can someone show me the light and put me out of my misery?? :))
Well, if you reduce your discussion to only HTTP, then there's still a slew of advantages that WCF has over ASMX:
more and better security settings (ability to use either transport or message security)
much more flexibility - a lot more can be configured and tweaked in WCF, either in configuration files or code
ASMX web services can only exist inside IIS - IIS is a must-have requirement; you can self-host your WCF services in a console app or Windows NT Service
the clear focus on using Service and Data Contracts in WCF makes for a much cleaner interface and a much better separation of concern (better code, in the end)
support for things like reliable messaging and transaction support (even over HTTP)
In short: even though the differences might be smaller when you restrain WCF to just HTTP, I still think it's superior and if you have the choice to start something new today, by all means, use WCF instead of ASMX!
Rick Strahl puts it very nicely in his blog post:
I would argue that using WCF for any new services is probably a good idea even if you stick with pure HTTP and SOAP because by creating your service with WCF you can decide later on to publish this same service using WAS and also provide the more high performance TCP/IP transport. Or you might be asked to provide some of the advanced features of WS- protocols like transactions, attachments, session management, encryption etc. By using WCF you are building your service with a view to the future so you can easily move up to other protocols-some of which may not even exist today. Certainly new technologies will come along in the future and WCF protects you somewhat through its abstraction layer and common API.*
Marc
Another point for the consumers of the ASMX web service, which ever platforms will consume the web service will have to implement a SOAP stack. If you're goal is for wide reaching consumption, WCF is preferable and will allow you to expose the WS in more universal ways.
The other big distinction between the two technologies is that Microsoft now considers both ASMX web services and XML Serializer to be "legacy technology", and is no longer fixing bugs in them.