I know, there are 1000x topics about WCF and security - seems to be a hot topic. I still want to get some up-to-date opinions about this.
I am creating a Webservice (free to use) where clients can register on my website, get a secure token, and can consume the webservice with this token. Consuming the webservice must be very simple independent from what language the client is using (PHP,Java,.NET).
Also I need to have one webservice-call exposed for use in Windows Phone 7.1, Android, iOS.
I've currently implemented the Service in WCF using wsHttpBinding and TransportWithMessageCredential security. Now I have already compatibilty issues trying to consume with WP7...
What, in your opinion would be the best Webservice/Security Framework for my needs?
* REST
* SOAP (With SoapHeaderAuthentication)
* etc...
Any feedback highly appreciated!
Thanks!
If it has to be consumed easily by different frameworks and devices, I would build a Rest service. Take a look at ASP.NET Web API.
You can use Web Api to return Json, which can be easily consumed by Windows Phone 7 apps, Java, php, whatever. You have the possibility to implement https and authentication.
Keep in mind that it's still in a Beta stage and that you'll have some issues accessing it cross domain, but it's a problem that can be overcome. I guess this will be made easy before it hits RTM.
Rest is easier with interoperability. If you do use soap then basicHttpBinding is much better than wsHttpBinding since the latter has some proprietary protocols.
Related
What are the pros and cons of using each technology?
WCF Web Api is now merged into Asp.net
Asp.net web api now supports self hosting.
I still imagine if I want to expose multiple protocol schemas for the same operation I would still lean towards WCF or can Mvc end point do this too?
Also does the new Asp.Net web api expose Wsdl? If not how would the client figure out what operation is available to them?
Arguably the best feature of Mvc is the modelbinder. How robust is the WCF equivalent?
So can someone tell me what advantage does the Asp.net web api bring to the table? WCF seems overwhelmingly the more powerful/scalable choice, imo. About the only thing the Mvc Web Api has over the WCF model is probably ease of development, but that means squat if it ends up being a serious design limitation down the road.
First, I suggest you read my post on the subject:
http://blogs.microsoft.co.il/blogs/idof/archive/2012/03/05/wcf-or-asp-net-web-apis-my-two-cents-on-the-subject.aspx
Regarding your WSDL question - since the WebApi does not use SOAP, it does not require a WSDL, and does not export one. You can use Hypermedia to return resources with a list of possible activity URLs (think of it as a self-describing resource)
The choice depends on what we want to do.
ASP.NET Web API is a framework for building non-SOAP based services over HTTP only - so there aren't more transport protocols available using this framework.
WCF / Windows Communication Foundation is a framework for exchanging SOAP-based messages - here we use a lot of transport protocols: HTTP, TCP, Named pipes, MSMQ, etc...
I am not sure about which one has better performance regarding the amount of data, maybe WCF since we can use low protocols. Any comments are appreciated.
The WCF Web API primarily focuses on REST implementations. If you are setting up a REST implementation, the standard WCF bits are a bit of a pain in the rear. If you are setting up RESTful services, you will find the WCF Web API a much nicer experience. If you are setting up SOAP services, then the WCF Web API is not your best friend, and you are better off using WCF for your services.
Use WCF for intranet/B2B sites n Web API for B2C/C2C/internet sites...SOAP/XML is still the standard for intra-businesses communication n it's not going to go away!!!
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.
I have a web service that is used by many different clients using many different languages.
I want to switch it to wcf to take advantage of the many different endpoints.
However what has been stopping me is that I am afraid that the clients will have to use a special sdk to connect (if they are using java or php or some other language) that is different then the sdk they use to connect to the existing web service.
Is this true? Or is connecting to WCF the exact same as it is for web services in other languages.
The project I am currently working on has multiple WCF configurations, some are using the default SOAP implementation, and some are using a POX (plain-old-xml) style message.
So the short answer is 'yes' you can configure WCF in such a way to work with just about anything.
However, be warned that as soon as you step outside the default little box that WCF has set up for you, it gets pretty complicated. You end up with a lot of custom message parsing and security handling if you go to a POX message format. Its easier if you stick with SOAP though.
As for needing a 'special SDK' you won't. You can communicate with WCF with simple HTTP POST messages if needed.
I have clients that are using VB.NET apps (using SOAP) and Java apps (using POX) to hit my WCF services.
A basicHttpBinding endpoint in WCF is exactly a standard SOAP endpoint, and your Java or PHP clients will not have to change in any way.
I have a Windows Service which performs a certain function, and then needs to send that information off to a webservice for processing. The webservice is hosted by a remote web application. I am trying to ascertain the best way to call the webservice(s) as each web application might be only 2.0, or 3.5 etc. In my windows service, I am defining each "client" in the app.config, e.g.
<Client WebServiceUrl="http://location.com/webservice.svc" Username="" Password="">
</Client>
The web application must implement two web services that are required for my windows service to run, however not sure the best way to implement the "rules" for the web application.
EDIT:
I'll try and rephrase..
The Windows Service runs every 30 seconds and obtains a list of information. The service supports multiple "clients" as shown above. When each client process is run, the data is collected and is then needed to be sent to the supporting web application.
The windows service does not know what to do with the data, it is just sending it. Each web application for a client would be in different locations, and could possibly be built in 2.0, 3.5, PHP, etc. All the windows service cares about, is that when it performs its processing for a client, it is able to send the data to the webservice location defined in the app.config of the windows service.
What I'm trying to determine is how to connect to the webservice (which I'm leaning towards WCF, however Basic or WS not sure), and what rules need to be defined for the web application in how to build the response.
If the Windows service is to support php applications etc, WSHttpBinding would not be an option, which would mean BasicHttpBinding would then work. The other thing to decide is whether or not to utilise a RESTful service or SOAP service.
Hope this makes more sense.
I'm not really clear on what you are doing.
It seems like you have 3 things: A Windows Service, and then a web service, hosted in a web app.
I think your question is, what to use, REST, ASMX, WSE or WCF, when interconnecting the Windows Service app with the remote web service.
ASMX, WSE and WCF are alternative programming models for the web service. REST is not a programming model. It is not like the other three.
ASMX and WSE will require that you use Web services and SOAP.
WCF can allow you to use Web services and SOAP, REST (XML or JSON) over HTTP, or a binary format over TCP, among other options.
Because it is flexible and current technology, I'd recommend WCF. ASMX is now termed "legacy technology" by Microsoft. Doesn't mean it won't work, but it will not get updates. (Much like WinForms versus WPF). WSE is no longer in mainstream support, as far as I know. For these reasons, I wouldn't recommend starting a new project on WSE, nor on ASMX.
WCF is more general than ASMX and can seem more complicated, for that reason. But once you make some choices and zero in on what you want (for example choose HTTP and REST, or choose binary and TCP), it's more powerful. WCF can be used as the programming model on both the client or sender (in your case, the Windows Service, I guess) and/or on the server (the web service hosted in the web app).
Using WCF on the client side does not imply you must use it on the server side, and vice versa. On the other hand, if you control the source code on both ends, I would recommend using WCF on both sides.
As for "how to implement the rules for the web app" - I don't understand what you are asking there. Maybe if you are more specific on the question there, someone will be able to help out.
Update: Based on your additional explanation, I'm going to suggest you look at the REST stuff in WCF for .NET 3.5. In PHP it's very easy to implement a REST-style service, and with WCF, the same is true for .NET. Now in your case the Windows service is the client and it is sending out a request, an update request, to various servers that reside on your customers' networks. According to REST principles, I'd make those outbound requests PUTs or POSTs, depending on the semantics of the call.
Then you could ship some example service code to your (uppercase) Clients, to get them started on building what they need to receive your outbound PUT/POST messages.
Security is a concern though. You didn't mention it at all, which is surprising. Security is not one of those things best deferred, so that you "add it on later". You should think about it early - it may affect the protocol choices you make. For example, if you need to mutually authenticate the clients and servers (the latter at your "uppercase" Clients' networks), then you may want to go with SOAP, which gives you good options on the protocol side for security. Secure Web services extensions (WS-Sec, etc) are well supported in WCF, but not sure about the status of this capability in PHP.
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.