I'm looking for a WCF implementation of U-Prove that was formerly on the Microsoft connect website for test and experimentation purposes.
I've seen several videos that mention U-Prove in conjunction with WCF/Cardspace, but it seems that all of those plugins have been removed and not replaced.
I would like to see those samples just to I can understand
If the WCF binding was "upgraded" to support UProve for authentication
If WCF was used to issue and renew a UProve token
How and where the serialization was done (was it a custom binding or a simple service)
Any other WCF-specific technology that may have been improved with UProve
Ultimately I want to take the "outdated" WCF examples and modernise it so a JSON token will have the same affect as what I assume the binary-based Cardspace demo used to do.
Any archived link to the outdated Microsoft Connect project, or a FOSS replacement would be a great help.
Although this isn't the implementation per-se, it is a document that describes the implementation
http://research.microsoft.com/apps/pubs/default.aspx?id=166974
Related
I am new to Single Sign On concept and I am trying to implement SSO for wcf service web applications using OpenSSO with SAML protocol. I couldn't get the clear idea from the internet sources that how i should proceed/start. Can u guys help me out.
If new to SSO and WCF, you're probably not going to like the answer: write your own Binding.
WCF is awesome because Microsoft built the whole thing extensibly. So in theory you can do exactly what they did with netTcpBinding or wsHttpBinding. Say you have a VAX mainframe sitting around - you could theoretically write a Binding for it. Same with "Protocol XYZ" and OpenSSO. Since I don't see an OpenSsoBinding available out there, I conclude you'll have to whip up your own.
Implementation details are beyond my knowledge and the scope of the OP, but you can get the starting guidance here: https://msdn.microsoft.com/en-us/library/ms730305(v=vs.110).aspx
HTH!
We have an established WCF SOAP service. Its interface is defined in WSDL, from which C# classes are generated for our server (customers generate client-side bindings in various languages, from the same WSDL). The WSDL has a current version, which we can change a bit, and old versions, which we can't change or drop without a deprecation period, consultation etc. The SOAP requests tend to be complicated, having multiple XML namespaces within the same request.
The WCF SOAP service has a lot of "smarts" in it, and provides exactly the kinds of fetching and reporting facilities that we need for a new Web application that we need to make. We hope to use AngularJS for the client side of that. But these complex SOAP requests aren't easy to make in JavaScript world. If only we had a REST service, we could use angular Resource service. If not that, then a server that spoke JSON, albeit in an RPC style like SOAP, would run a fairly close second.
I've had various ideas for how the impedance mismatch between our server and client might be mitigated. But nothing sounds quick or easy.
I've thought of: -
Write a new REST service. Exactly what the client-side wants, but a serious piece of new development.
WebHttpBinding looks to offer something. But seems to me like it requires C# markup of custom attribute (how to achieve when our C# is generated from WSDL) and possibly wouldn't support our complex types
Obtain or write loads of client-side JS to abstract away calling SOAP services. But, unless this can be auto-generated from the WSDL, it's a huge amount of client-side code to write.
Write an IDispatchMessageFormatter for the server, to accept some JSON format of messages that I invent. Sounds hard, especially as good examples of people implementing and integrating IDispatchMessageFormatter seem hard to come by.
Write a MessageEncoder to swap between JSON and XML. But this isn't really an encoding operation, as became very clear when I tried to write it!
I'm searching for suggestions.
Generally, I recommend a REST service for any AngularJS development and have wrapped a number of legacy systems with Node.js API servers. Of course there is a massive amount of "it depends", but generally most projects will be happier and more productive following that route.
Some Things To Think About
How well does your current SOAP API fit the user interface requirements?
Are you experienced with Express, Sinatra, Flask or other micro-framework that allow rapid development of REST APIs? I find I can build a solid Node.js Express API server in a couple of hours and then extend it as I build the AngularJS application out.
How experienced are you with AngularJS? It's a more advanced project to build a complex data layer client-side.
Six Reasons Why REST is Important for AngularJS
It's much faster to write Angular code using $resource and $http. Get the API right is a good recommendation for effective AngularJS development. Indeed, you could argue that AngularJS is designed for REST, and that's why plain JavaScript works for the model (see 2).
Angular's plain-old JavaScript object data model works well with a REST API that speaks JSON that matches the user interface. However, issues arise when there isn't a good fit- Angular doesn't have a formal data model so you end up writing an lot of code trying to rationalize your API to work well with Angular. 3rd party libraries like breeze.js may offer some solution, but it's still awkward.
You can scale easily with caching. It's easy to add Redis or memcache or Varnish or other common HTTP caching solutions into the mix. Resource-based abstractions are perfect for caching strategies due to the transparency and idempotency of a REST api.
Loose coupling of front-end and server- it will be easier to support changes to the backend if you migrate off SOAP or need to integrate with other services.
It's generally easier to test JSON APIs separately from AngularJS logic, so your test suites will be simpler and more effective.
Your new REST API will be easier to leverage for future AngularJS and JSON-oriented projects.
I hope that helps.
Cheers,
Nick
Recently I've been working with MVC4 and have grown quite comfortable with the View > View Model > Controller > Service > Repository stack with IoC and all. I like this. It works well. However, we're moving towards company wide application platform that will serve the majority of all business applications needs within the company.
Basic architecture goals:
Client facing MVC site
Internal Admin web site
Plethora of scheduled jobs importing/exporting data/etc to third parties
Service Bus sitting in the middle to expose business events
Public API for customer consumption
My initial thoughts are to introduce an "enterprise service layer" by applying my service interfaces to WCF contracts and registering the WCF proxy classes in my IoC. This would allow me to reuse the same pattern I'm currently using, butt I've not found a lot of examples of this in practice. Except this guy.
Admittedly though, I'm unsure what the best solution is for a project this scale.
1) What are the considerations when centralizing business services?
2) How does this affect cross cutting concerns like validation, authorization, etc? I thought I had that figured out already, but putting DTOs between the layers changes all this.
3) I'm experienced with WCF, but I hear Service Stack is all the rage...Should SS be a consideration with its RESTful goodness?
This guy here. I am not an expert in this area by any means, but hopefully I can provide a bit more context around things.
The main problem with using IoC to resolve WCF ChanelFactory dependencies as per my post is that the client also needs to have access to the service contracts. This is fine for a View > View Model > Controller > Service > Repository type architecture but is not likely to be possible (or desirable) for a shared public API.
In an attempt to cover your other questions:
1) Some of the concerns are already mentioned in your second question. Add to that things like security, discoverability, payload type (XML, JSON etc), versioning, ... The list goes on. As soon as you centralize you suddenly gain a lot more management overhead. You cannot just change a contract without understanding the consequences.
2) All the cross cutting stuff needs to be catered for in your services. You cannot trust anything that comes in from clients, especially if they are public. Clients can add some validation for themselves but you have to ensure that your services are locked down correctly.
3) WCF is an option, especially if your organisation has a lot of existing WCF. It is particularly useful in that it supports a lot of different binding types and so means you can migrate to a new architecture over time by changing the binding types of the contracts.
It is quite 'enterprisey' and has a bewildering set of features that might be overkill for what you need.
ReST is certainly popular at the moment. I have not used Service Stack but have had good results with Asp.Net Web Api. As an aside, WCF can also do ReST.
I've previously provided a detailed explanation of the technical and philosophical differences between ServiceStack and WCF on InfoQ. In terms of API Design, this earlier answer shows the differences between ServiceStack Message-based approach and WCF / WebApi remote method approach.
SOAP Support
ServiceStack also has Soap Support but you really shouldn't be using SOAP for greenfield web services today.
HTML, Razor, Markdown and MVC
ServiceStack also has a great HTML Story which can run on stand-alone own with Razor support as seen in razor.servicestack.net or Markdown Razor support as seen in servicestack.net/docs/.
ServiceStack also integrates well with ASP.NET MVC as seen in Social Bootstrap Api, which is also able to take advantage of ServiceStack's quality alternative components.
What is the difference between WCF Services and Web Services in .netWhen should I use WCF and when to use Web Services.Is REST and WCF service the same? Thanks
Web Service is an abstract term encompassing a large variety of data providers for distributed systems. Perhaps you are referring to ASMX web services, which can still be found in the wild but aren't really widely used in new development these days.
WCF Service is Microsoft's implementation of SOAP. There are others implementations or you could roll your own (not recommended).
SOAP is a kind of stateful, session-based, message-based web service. It's good if your service is designed as a set of complex actions.
REST is a stateless, sessionless, resource-based web service. It's good if your service is designed to access data and perform simple CRUD operations on it. SOAP and REST are mutually exclusive. A service cannot be both. There are ways to manipulate vanilla WCF to make is RESTful but these techniques are becoming deprecated. If you want to implement a RESTful web service there are two main choices in the Microsoft world: WCF Data Services and ASP.NET Web API.
REST is an architecture
WCF is a API in .NET Framework to build connected service oriented application.
In olden days a functionality developed as Web Service was accessible via internet and the same to be available on local network was available via Remoting.
Using WCF we don't need to develop different code for it to be accessible over internet and on local network. Just configuring it with bindings would be enough.
That is a very wide question...I am going to just give a brief high-level answer and suggest that you do some more searching as there are is already a lot written on each subject. But, hopefully this should give you a push in the right direction.
First, typically when people refer to WCF Services and Web Services, they are referring to the newer WCF conventions that make service calls fairly generic (they can be SOAP, REST, etc) and the old .asmx SOAP method of Web Services. So, along these lines, I would suggest looking more into WCF and SOAP/.ASMX for the difference of WCF and older Web Services.
As to WCF and REST, they are not the same. REST is more of an architecture, whereas WCF is a framework. As I already mentioned, WCF can be used to make SOAP calls or REST calls. I am not sure I can add much more without going into greater detail.
I will see if I can find some good articles on REST and WCF a little later, though. Personally, I do not see a reason to even pursue very far into the older way of calling web services (.ASMX pages) as WCF has pretty much made that obsolete. However, learning many different ways to skin a cat can be useful in an endeavor to find what fits you best.
Again, this is VERY high level, but these are very general topics with a lot surrounding each, so hopefully a high level overview will help direct you in studying deeper on each subject.
Some people mean "ASMX" when they say "Web Services".
Others just use "Web Services" to mean the generic technology, and consider WCF to be the current way to create Web Services on the .NET platform. The other kind are "ASMX Web Services", as distinguished from "WCF Web Services".
The "other kind" are a legacy technology, supported only for backwards compatibility. They should not be used for new development, so there's no point in you learning about them.
As others have stated, "REST" is an architecture style, not a technology.
WCF is multifaceted, so I'm going to speak of it with respect to its most common usage. The general difference between WCF and REST services is centered around the content. A REST call is usually more message/document/entity centered (With customer entities, find those starting with M; With order entities, get order 12 and is tied to the HTTP protocol. WCF tends to be more operation centered (Invoke find operation with params, Invoke get operation with parameters). WCF also isn't tied to HTTP.
FYI, there are extensions to create REST based services using WCF (WebInvoke, WebGet attributes).
Wcf:wcf is a technology as part of .net framework which provides environment to work with different distributed technologies an by following unified programming model.
wcf create a proxy.
wcf support data contract serializer.
records shown xml format.
**Rest:**Rest is an architectural style.which says use the existing features of the web in more effective,efficiency and simple manner.verbs like insert,update and delete.
Rest cannot create a proxy.
rest records shown jason format.
Web Service:a service which is hosted on website is called as webservice.
web service support xmlserializer
I see this is quite an old thread, but I have asked a similar question recently.
The answers given have all similar relevance, but in my opinion Ray was the closest to what was actually asked.
When designing or refactoring a web based solution, you always get the question should we go with SOAP or REST. The answer lies in the complexity of the business logic required behind the service. REST is good for simplistic API calls that usually contains small sets of requested data or over night processing with large sets, but mainly for data requests. SOAP is more of an interactive day to day service with business logic as well. For example many methods with plenty of parameters.
What we do as part of our web based solution, is to try and make use of both. For internal methods and primary functionalities we use SOAP, but for exposed APIs we prefer REST.
Framework related, definitely WCF as preferred choice, irrespective if SOAP or REST.
I am bit confused about ADO.Net Data Services.
Is it just meant for creating RESTful web services? I know WCF started in the SOAP world but now I hear it has good support for REST. Same goes for ADO.Net data services where you can make it work in an RPC model if you cannot look at everything from a resource oriented view.
At least from the demos I saw recently, it looks like ADO.Net Data Services is built on WCF stack on the server. Please correct me if I am wrong.
I am not intending to start a REST vs SOAP debate but I guess things are not that crystal clear anymore.
Any suggestions or guidelines on what to use where?
In my view ADO.Net data services is for creating restful services that are closely aligned with your domain model, that is the models themselves are published rather then say some form of DTO etc.
Using it for RPC style services seems like a bad fit, though unfortunately even some very basic features like being able to perform a filtered counts etc. aren't available which often means you'll end up using some RPC just to meet the requirements of your customers i.e. so you can display a paged grid etc.
WCF 3.5 pre-SP1 was a fairly weak RESTful platform, with SP1 things have improved in both Uri templates and with the availability of ATOMPub support, such that it's becoming more capable, but they don't really provide any elegant solution for supporting say JSON, XML, ATOM or even something more esoteric like payload like CSV simultaneously, short of having to make use of URL rewriting and different extension, method name munging etc. - rather then just selecting a serializer/deserializer based on the headers of the request.
With WCF it's still difficult to create services that work in a more a natural restful manor i.e. where resources include urls, and you can transition state by navigating through them - it's a little clunky - ADO.Net data services does this quite well with it's AtomPub support though.
My recommendation would be use web services where they're naturally are services and strong service boundaries being enforced, use ADO.Net Data services for rich web-style clients (websites, ajax, silverlight) where the composability of the url queries can save a lot of plumbing and your domain model is pretty basic... and roll your own REST layer (perhaps using an MVC framework as a starting point) if you need complete control over the information i.e. if you're publishing an API for other developers to consume on a social platform etc.
My 2ΓΈ worth!
Using WCF's rest binding is very valid when working with code that doesn't interact with a database at all. The HTTP verbs don't always have to go against a data provider.
Actually, there are options to filter and skip to get the page like feature among others.
See here: