I'm working on API versioning in WCF these days. I've read many articles regarding best practices of doing this. What I've to understand the most important thing is to identify either changes in API are Breaking or Non Breaking in new version. A very nice article/discussion on Changes impact on stackoverflow WCF API Deployment Versioning
To implement custom Serialization requirement I've chosen ixmlserializable technique. Now my question is Either Breaking and Non Breaking concept will remain same in this case? If no, please help me to find out the way to implement API versioning in this context.
My understanding is that new changes will always break when working ixmlserializable because ReadXml method implement the manual way to construct the object.
Please do let me know either my understanding is correct and how to proceed in this scenario. Any help in this regard will be highly appreciable.
/Rizwan
Related
I've done some research into the subject of response serialization for NestJS/GraphQL. There's some helpful information to be found here, but the documentation seems to be completely focused on a code first approach. My project happens to be taking schema first approach, and from what I've read across a few sources, the option available for a schema-first project would be to implement interceptors for the resolvers, and carry out the serialization there.
Before I run off and start writing these interceptors, my question is this; is there any better options provided by nestjs to implement serialization for a schema first approach?
If it's just transformation of values then an interceptor is a great tool for that. Everything shown for "code-first" should work for "schema-first" in terms of high level ideas of the framework (interceptors, pipes, filters, etc). In fact, once the server is running, there shouldn't be a distinguishable difference between the two approaches, and how they operate. The big thing you'd need to be concerned with is that you won't be easily able to take advantage of class-transformer and class-validator because the original class definitions are created via the gql-codegen, but you can still extend those types and add on the decorators necessary if you choose.
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/.
We are developing a LOB application using Silverlight and several team members are advocating the use of the canonical design pattern instead of creating simple WCF services. As the lead, I’m trying to balance best practices with an incredibly tight time line.
Here are the reasons I do NOT think Canonical is a good approach for our project.
We have no immediate (<5 years) requirement to expose any internal services to the enterprise.
Time required for governance. (Developing adapters with data transformation logic, developing XSDs, and developing contracts [fault, data, and operation]).
No need to expose a different data contracts than what exists in the data layer
It doesn’t appear that we can easily use ‘self tracking entities’ with the Canonical approach.
Here are some reasons I’m considering using Canonical approach.
We can use the XSD schemas for data type and length validation.
We will be prepared to allow consumption of our services to the enterprise, whether it’s 5 years or 1 year.
We can feel good that we’re implementing best practices. :)
So, is it advisable to follow the Canonical approach with a Silverlight application? It does not seem that the benefits Canonical provide out weigh the additional work. …or perhaps I’m wrong and it’s not additional work.
I think you should definitely go with WCF RIA services. It's extensible in every point possible, it's fast to develop, it's accessible as regular WCF services, it also has plenty different available end point types, and generally very mature. And implements best practices, and validation process is fully customizable. It really is a no brainer, if you have some additional questions about it shoot away, i'll gladly answer them:)
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.