How can I achieve reliability of web service in CXF ?
It is used in financial domain and involved in payment system, so requirement is that it must be 100% reliable and secure. for security I have added username/password authentication using ws-security (intercepter).
Do I need to use any Middleware (ActiveMQ) for transprot so that MQ provide reliability and security ?
I do not fully understand your question; however, I assume your requirements for reliability do not extend beyond the regular WS-* specifications.
Apache CXF does conform to WS-ReliableMessaging specification. Additionally, it also supports WS-Security and WS-Addressing. I believe this should be enough for most reliability and security requirements.
Related
I am reading security concepts of WCF in 'Programming WCF Services' book. In that i got points like generally transport security is good for intranet scenarios because of point-point etc.
For internet scenarios, we can use message security as the better choice. I already worked at basic level in REST based wcf. So i use webHttpBinding. As i knew that the Message security is based on WS standards and the webHttpBinding is rest based it is not possible to apply Message security in the webHttpBinding.
But if take a scenario like i am creating a public API (for internet) in REST wcf as the methods are used in handheld devices also. Here how transport security is better than message security. Is my understanding right or in the REST transport security is different concept?
Please explain
Message Security is implemented via the WS-Security specification. And the WebHttpBinding enables REST-style APIs.
REST delegates all security concerns to the Transport layer, typically via SSL, so Message Security does not apply.
I have worked with both technologies yet I’m about to build a new backbone services layer and thinking about WCF vs Web-Api.
The idea is to create a layer of services that will be consumed by both internal .NET components and by front applications.
The following are issues are not relevant to this case:
TCP, UDP
Proxy generator
WS-* standards like Reliable Messaging, Transactions
I'm considering about 2 approaches:
Web-api for app front application above n-tier WCF services
Web-api for app front and for a flexible services layer, thus avoiding HTTP hop between services
Our system is financial oriented, some services will operate as data services using the using some kind of OData and some will perform complex financial transaction (using complex types).
I've read about the new stuff that was recently added to Web-Api 2 and it seems to be a leading platform. I've Googled a lot about pros and cons and that WCF is still alive (or frozen).
A few of the relevant references:
http://www.codeproject.com/Articles/341414/WCF-or-ASP-NET-Web-APIs-My-two-cents-on-the-subjec
http://msdn.microsoft.com/en-us/library/jj823172.aspx
Under the assumption that all the services are on the same LAN and this is targeted to enterprise system, what would you recommend and why?
Here's the question... Do you need transport layer flexibility or are you fine with them being http(s) only services? If the services are HTTP-only and (as you say) you don't care about proxy gen and WS-* then I can't for the life of me think of a reason why you'd use WCF.
The programming model for REST / plain old http(s) is just so much leaner, the MVC "style" much more natural and not to mention that WCF can just get really complex really fast, makes me think that I would need a really good reason to choose WCF in 2013...
Not to throw a spanner into the works, but have you considered Service Stack:
https://servicestack.net/download
That's what I'd be using... (btw I'm not affiliated with them in any way / shape / form).
If you need multiple endpoints/transport protocols, or the ability for other applications to consume your services in .NET and work with them as you would any other referenced library (via web reference and a SOAP endpoint) the WCF should be your choice.
If you're looking for something lightweight and convention-based and/or you're looking to create a RESTful API, and HTTP(S) is an adequate transport, then Web API is the way to go. In this case, if you want the strong typing that you'd get with a SOAP web reference you'd probably be wise to write a reusable library that acts as middleware for consuming the services and providing data.
I'm about to start a project where we have a back-end service to do long-winded processing so that our ASP.NET website is free to do quicker requests. As a result I have been reading up on services such as WCF and Web API to get a feel for what they do. Since this back-end service will actually be made up of several services communicating to each other and will not be publicly available to our customers, it seems that WCF is the ideal technology for this kind of scenario.
But after doing a lot of research I am still confused as to the benefits and differences between WCF and Web API. In general it seems that:
If you want a public and/or a RESTful API then Web API is best
WCF can support far more transports than just HTTP so you can have far more control over them
Web API development seems easier than WCF due to the additional features/complexity of WCF
But perhaps my question boils down to the following:
Why would a REST service be more beneficial anyway? Would a full blown WCF service ever be a good idea for a public API? Or is there anything that a WCF service could provide that Web API cannot?
Conversely, if I have a number of internal services that need to communicate with each other and would be happy to just use HTTP as the transport, does Web API suddenly become a viable option?
I answered a couple of related questions:
What is the future of ASP.NET MVC framework after releasing the asp.net Web API
Should it be a WebAPI or asmx
As an additional resource, I would like to recommend you to read:
http://www.codeproject.com/Articles/341414/WCF-or-ASP-NET-Web-APIs-My-two-cents-on-the-subjec
If you want to learn more about REST, check this Martin Fowler article
Summaring up:
As far as I know, both technologies are being developed by the same team in Microsoft, WCF won't be discontinued, it will still be an option (for example, if you want to increase the performance of your services, you could expose them through TCP or Named Pipes). The future is clearly Web API
WCF is built to work with SOAP
Web API is built to work with HTTP
In order to take the correct choice:
If your intention is to create services that support special scenarios – one way messaging, message queues, duplex communication etc, then you’re better of picking WCF
If you want to create services that can use fast transport channels when available, such as TCP, Named Pipes, or maybe even UDP (in WCF 4.5), and you also want to support HTTP when all other transports are unavailable, then you’re better off with WCF and using both SOAP-based bindings and the WebHttp binding.
If you want to create resource-oriented services over HTTP that can use the full features of HTTP – define cache control for browsers, versioning and concurrency using ETags, pass various content types such as images, documents, HTML pages etc., use URI templates to include Task URIs in your responses, then the new Web APIs are the best choice for you.
If you want to create a multi-target service that can be used as both resource-oriented service over HTTP and as RPC-style SOAP service over TCP – talk to me first, so I’ll give you some pointers.
One combersome bit of WCF is the need to generate new client proxys when input and/or output models change in the service. REST services don't require proxys, the client simply changes the query string sent or changes to parse and/or use the different output.
I found the default JSON serializers in .Net to be a bit slow, I implemented http://json.codeplex.com/ to do the inbound and output serialzation.
WCF services are not that complex, REST services can be equally challenging as you're working within the confines of HTTP.
ASP.net Web API is all about HTTP and REST based GET,POST,PUT,DELETE with well know ASP.net MVC style of programming and JSON returnable; web API is for all the light weight process and pure HTTP based components. For one to go ahead with WCF even for simple or simplest single web service it will bring all the extra baggage. For light weight simple service for ajax or dynamic calls always WebApi just solves the need. This neatly complements or helps in parallel to the ASP.net MVC.
Check out the podcast : Hanselminutes Podcast 264 - This is not your father's WCF - All about the WebAPI with Glenn Block by Scott Hanselman for more information.
In investigating federated authentication, I've been running into a protocol alongside SAML: HTTP-FED.
Curiously, I can't find any technical documentation for this protocol.
What is it? Is it, like I suspect, a claims-based protocol for use with HTTP instead of WS- services?
HTTP-Fed appears to be a creation of a commercial vendor (Symplified). It has not been ratified by any standards bodies (that I've found) which is why you probably can't find much on it. From what I've read on their website, it appears to essentially be a fancy name for credential caching/credential replay across the internet. From their site -- http://www.symplified.com/http-federation/
"... HTTP-FED leverages the existing HTTP login mechanism at the SP.
The implication of this is that no changes to the SP (destination
application) are required and no special software is needed by SPs,
thereby reducing the effort required to federate domains."
It's not a standard so there's no info on how you'd implement it outside of buying their product. If you're looking at Web SSO for Cloud Applications, I'd stick with actual standards (SAML, OpenID, OAuth, Open ID Connect) that are designed with security in mind for this type of activity.
I am a beginner in WCF and want to take some help in creating a WCF for my project.
I have to create a WCF service which can support 10,000 users simultaneous hits.
The job of the WCF service is to fetch a cached up XML object (we are using Enterprise Lib caching) and return it to the caller.
This WCF service will have to be publicly exposed. So I was thinking that we may have to use basicHttpBinding... I don't know, I may be wrong.
Can anyone please suggest the best way of going ahead with this?
Thanks a lot!
Don't use reliable messaging
Don't use sessions
Don't use transactions
Don't use Duplex
Don't use message security
Use BasicHttpBinding or NetTcpBinding
if you need security on HTTP, use HTTPS (TCP already implements encryption)
My personal view, don't use WCF if you need performance! :) Use ASP NET MVC with JSON message format and if you need security, use HTTPS.
This article might be useful - http://mikehadlow.blogspot.com/2011/03/7000-concurrent-connections-with.html