I would like to start using the WCF Rest Starter Kit's HttpClient to build clients for my Restful WCF services and I was wondering...
If anyone is currently experience
any problems with it
Can I be confident that future versions of
the component (just the HttpClient,
not worried about the rest of the
kit) will not contain significant changes to the API?
It seems like a pretty straight-forward component so I can't imagine any major changes with it, but maybe somebody here who is more "in the know" could give me a heads up.
Thanks in advance.
I work on the WCF team and I wrote most of the HttpClient code.
No major known issues. The public issue tracker is at http://aspnet.codeplex.com/WorkItem/List.aspx (search for HttpClient or WCF REST).
Microsoft does reserve the right to change it. That being said, I don't think there will be significant changes to the API that has shipped. (Maybe some minor renaming.) We're mostly considering adding features/capabilities, which shouldn't break your existing code.
A great way to tell us about your usage is via the forum: http://go.microsoft.com/?linkid=9632199 .
Until it's released, Microsoft will surely reserve the right to change it.
On the other hand, if you make sure they know you're using it, you're somewhat less likely to be, ummmm, inconvenienced by any changes.
Related
I want to create an OAuth 2 Server mainly for self education purposes. I do understand the concepts the OAuth framework is based on and I do understand the the authentication process(what is send/received and why).
I'm pretty familiar with java and the Spring framework as such my intentions are to use this technologies.
My question is, In order to implement an OAuth 2 Server:
Do I just follow the rfc6749 to the letter and write my code based on this? Handling everything by my self? from the data and how its stored in the database(if a database is used) to serving the same error/message response?
Do I use a dependency or a library maybe, which will prevent me from reinventing the wheel (as far as OAuth 2 is concerned)?
Or is there and already free service which I can install and does exactly with some minor configurations.
Thanks in regards. :)
If you're writing something new from scratch, I would recommend you would take a look at the upcoming OAuth 2.1 spec. Largely compatible with OAuth2, but there's a few features removed and some stuff added. It might be worth starting off with something that's immediately the bleeding edge.
Yes, probably. Unless you can't find a good one?
Yes, there's open source implementations and free hosted services.
I think what you want is Keycloak.
Thanks.
Is it even possible more or less natively consume WCF service from Go application?
I can imagine it should be possible to execute SOAP calls in Go, but WCF is a bit more than that only, for example authorization will probably be a problem also...
Have anyone at least approached this area, or maybe someone can give useful me advice in this "wheel reinvention task"?
Thank you in advance for all your input, ideas and suggestions.
I think you should expose a RESTful Service. I myself have the problem with exposing a WCF Service too many clients using PHP, Go, Ruby and all kind of languages. We never ever got it right, to automatically generate a proxy.
The maybe simplest way is to use WCF, like described in this example:
https://www.codeproject.com/Articles/105273/Create-RESTful-WCF-Service-API-Step-
By-Step-Guide
But I recommend to switch to ASP.NET Core (Migration is not that hard) or if you have the budget I would consider https://servicestack.net/
It may be well beyond the wait time for this. However, here is something really interesting that could help. The situation the authors found themselves is relevant even today in some organizations.
https://github.com/khoad/msbingo
Here's the motivation provided by the authors:
Application/soap+msbin1 encoding was a blocking issue for modernizing services from WCF to platform-agnostic technologies such as Go. We needed to be able to make calls to dependency services that spoke msbin1 and were not going to be updated or even reconfigured, but we did not want to introduce unnecessary complexity such as workarounds like .NET-based WCF request translator proxies or deploying Mono with our service instances. Initially we tried the Mono deployment route, which, while it would have worked well enough, significantly complicated our deployment pipeline, thus erasing one of the major advantages of golang.
I found it a useful starting point to begin experimentation.
I have recently been thinking about how to get my webframework/application-stack right. I'm slowly moving over to scala and functional programming (coming from Python with CherryPy). So it was natural to look into Play as it is the most widely supported framework (now that even Typesafe adopted it). Feel free to correct me if I'm missing something here.
So play is really embracing the idea of stateless webapps and I have a hard time wrapping my head around it in terms of authentication and authorization. Now after some online digging (The definitive guide to form-based website authentication) I came to conclusion that authentication and authorizing must be done on each and every call to my backend (JSON-RPC or whatever), getting away from the old session-cookie idea.
Now whats the best approach to achieve this with todays technology?
And what about:
I thought about "simple" DigestAuth as it is proven and widespread but then it has this similar feel to the old and rusty basic auth.
Thank you!
You can easely get a work solution. But, not a good one. It seems that the advantage of stateless to stateful is no needs of sharing sessions. Easy to scale up. But, do authentication for each call is costly. Sometimes even add some extra database reads ops. This will slow down the response. If you want to cache the authentication result, then there will be no difference with a stateful session solution.
As my opinion. You can not implements a Role Based Access Control in a stateless way!
As for me I use this in my current project https://github.com/t2v/play20-auth, works fine.
This topic may look like it has been discussed already but I have few more things to say and ask.
The obvious question is; I want to know what AOP library shall I go for a .NET 4.0 enterprise application? As per the post What Aspect-Oriented Programming (AOP) libraries for .NET are still actively developed, one should choose PostSharp or Spring.NET or Microsoft's Policy Injection Application Block. But there are problem with each one.
PostSharp: This is best but not open. I need one whose source is open.
Spring.NET: This is too heavy and has limitations like it can intercept only those classes that is not static, must be non-sealed, properties and methods must be virtual, etc...
Microsoft's Policy Injection Application Block: As per the post Policy Injection Application Block, this is a legacy component now and may stop being supported by MS and since it is implemented through the Unity interception mechanism hence it has same limitation as that of Spring.NET (Alternatives to PostSharp)
I came across the post Aspect Oriented Programming: learn step by step and roll your own implementation!. I have not used it yet but reading through the post gave me an idea that it should serve my purpose. I want to know if anyone has tried it and if it is advised to go for it?
I have one more question to ask; I have used Unity for DI and it is all cool but for AOP, unity is not a good option for my purpose hence I will definitely go for some other tool/library (maybe the one I suggested above!). Is it good to have Unity and something else for AOP in the same application, will there be any problem?
Can anyone please help me here? Thank you in advance!
I think you'll find few good options once you preclude PostSharp and also want to intercept static code.
Some options that you might check out are SheepAspect and Fody, which both take a similar approach to PostSharp (post-compile weaving). Both are very nice and show promise, but are relatively young compared to PostSharp.
I'm starting to find myself getting more and more in to using WCF for projects I implement for internal use (automating company tasks, making sure all clients are on the same page, etc.) This is largely due to the 3-10 clients I am automating at once whenever I do implement a solution, and (even if it was a small sample) the company is growing which continually adds more clients in the pool and thus a higher demand for reliability/consistency. With that said, I'm recognizing how important it is to make sure I make things expandable as (previously) pushing a release was getting harder the more clients I have depending on the service.
My latest project has a potential of being externalized. Until now I've done it the way I know works, but I'd still like to travel down the "right" path in terms of future updates. How should I be setting up my project file to make this as easy and seamless as possible to keep maintained, up-to-date and expansive? Should I be placing version numbers in to the namespace (as in Company.Interfaces.Contracts.June2011.IMyService), using pseudo folders, ...?
I just don't feel confident in this aspect of moving forward. I'd like to know that whatever ground work I have in place now won't place burdens on future expansion/customizing later. I'd also like to stick to the "development norm" as much as possible as it's getting more plausible that we'll hire additional programmers to help the work load.
Does anyone with this kind of experience have any thoughts, suggestions, guidance in this field? I would really appreciate any examples, books, documentation, etc. that you can provide.
Update (06-17-2011)
To give some insight, I'm also looking for some specific questions. These include:
How do you decorate a service class vs a DTO in terms of namespace? I've seen http://service.domain.com/ServerName/Version used on the Service class itself & http://types.domain.com/ServiceName/Version used on the DTOs. Is this common? (Separate the namespace in to a type and service collection?)
Should I be implementing IExtensibleDataObject on all my objects on the basis that they could potentially be evolved in future released? (Lay the ground work out now)
If my database has constraints on it for (e.g.) string length, I should be extending IParameterInspector and using that method for validity (keeping logic and validation separate), correct?
Should the "actual service" be broken out in to its own class so, as I version, the Service Contract classes just call the code (keeping each new version release with an minimal code as possible?) Or should I keep it within the service class and inherit from it with any new methods (likewise, what happens should you remove a method?)
I'm sorry if I have a lot of questions, I just see two ends of the spectrum in documentation. I see "Setting up wcf" then directly to "this is a versioned WCF"--no segue/steps between. I'm assuming it's going to just "click" once I get enough information, but I'm (sadly) not there yet.
tl;dr
When you start writing a WCF service that you know is going to hit several iterations, how do you setup your project(s) to make it as easy as possible in the future (on yourself and teammates)?
I have had success using a "strict" versioning policy (it seems from past experience you are heading in this direction anyway) where you simply create new endpoint/s each time a new definition is released. This means you won't have any contract backwards compatibility concerns for legacy clients - older versions can easily be turned off once logging indicates all clients have upgraded. It is generally necessary however to write bridging code for any legacy endpoint/s so they can continue to call into the modified business logic.
In terms of project organisation, I would create a new project for each version so they can easily be deployed separately. Namespaces using v1, v2 are normally works well enough. The endpoint names can also include a version number which should easily distinguish them from each other.
Alternately you could try using a "lax" versioning policy where you can have the ability to add or remove data members by implementing the IExtensibleDataObject interface in all your services. Some useful MSDN article links can be found in a popular response to a similar question: WCF client's and versioning.
Another "lax" kind of option is to move more towards a messaging solution (which WCF can support through message contracts and/or the MSMQ binding). Here podcast by SOA guru Udi Dahan that provides an interesting perspective and is definitely worth a listen - there is no IDog2.
Finally here is a good blog post with some further more fine-grained guidelines on whichever strategy you end up using:
http://wcfpro.wordpress.com/2010/12/21/wcf-versioning-guidelines-2/.