I have been tasked with working out a versioning strategy for a new suite of WCF services. Much of the reading I have done recommends the use of an intermediate routing service to forward on calls to the appropriate service version. I understand how this works but am questioning how much benefit this gives in terms of shielding clients from breaking changes.
For example, I have two versions of a service with different endpoints:
mycompany.com/API/v1.0/GetCustomer
mycompany.com/API/v2.0/GetCustomer
A routing service solution would look for a custom 'version' header in the SOAP message and route the call to the appropriate service. If no version header is found then the latest version could be used.
Alternatively, I could just expose both endpoints and the consumer can call the required version.
How is one solution better than the other? Adding the routing service seems to add an extra level of configuration. Both solutions require the consumer to change their code if they wish to upgrade...
It may be better to ask this in a separate post but maintaining multiple versions of a service means we will need concurrent versions of contracts in our source code. Is there any recommended way of managing this (e.g. namespacing)?
Thanks
You can use routing in combination with WCF Action filtering. You can look at http://www.dotnetcurry.com/ShowArticle.aspx?ID=470
You can rebuild your service by sending a version parameter to the GetCustomer operation and maintain it as a single Service.
Related
I followed directions of other users to create a service that can run both REST and SOAP. At first glance I see no issues. Are there any concerns about running both concurrently?
There is no issue having a service that can process SOAP request and other more REST style requests. However, the resources that you create for SOAP will be completely different than the ones you create for REST. Also, it is rare to find a web framework that supports both styles effectively.
I have a third-party Java web service listening at three SOAP 1.1 WSDL endpoints. One of the endpoints is used to initiate the session and perform some high-level tasks, and the other endpoints are for subject-specific tasks reusing that initial authentication.
I'm building a C# WCF application to talk to the service, and I'd like to share the session cookie among the three client objects.
What's the VS2010 'best practices' way of sharing this cookie?
If this article is still the best answer, I can go with it, but I would appreciate some additional feedback, especially if .NET 4 introduced a simplification that I'm not finding on-line.
http://megakemp.wordpress.com/2009/02/06/managing-shared-cookies-in-wcf/
I can pretty easily create the first client and retain the session (new BasicHttpBinding myBinding; myBinding.AllowCookies = true), but I couldn't find an elegant way of saving off the cookie from the Connect response and reusing for the two auxiliary clients.
Any insights are appreciated.
I should note that I'm aware of CookieContainer and using Add Web Reference instead of Add Service Reference. That method is labeled as 'legacy' in most posts I've read, and I'd prefer to stay current...or as current as possible when working with SOAP 1.1.
The mentioned article is still valid. You have to use OperationContextScope and access message properties to get protocol specific data. This complexity is based on the fact that WCF architecture is protocol independent whereas ASMX architecture was HTTP protocol dependent.
It is true that ASMX (WebReference) is legacy technology but it is still present in .NET framework so if you know that you will never need nothing more the basic SOAP messaging without any advanced WS-* standard you can still use it and make your life little bit simple. Once you need anything more you can still refactor your code and use WCF with mentioned code to work with cookies.
Folks,
I'm building a pretty standard workflow that I want exposed via a WCF endpoint - I'm using the "WCF Service Application" project template and I've got a .xamlx service. This is a very simple document interchange workflow service - I want consumers to POST me a blob of XML as the body of an HTTP post (with HTTP headers containing authentication tokens). In response, these consumers will get a blob of XML containing the reply. 2 goals for me using REST/POX here are the document/message-based nature of the interaction AND I want to make client development easy for non-.NET environments (especially limited environments like Silverlight and iPhone).
I don't really see how to make this possible using out of the box features (unless I'm missing something). Does anybody know how to create a RESTful (or even REST-ish, I'm not picky) endpoint for a WF4 service-hosted workflow? Any info leading in the right direction here would be great.
There is an unreleased item on CodePlex to cover this, which includes source code. Also see this SO answer which contains another idea for achieving this.
If you'd like to see the CodePlex activity released, please up-vote the UserVoice request.
Using a REST Pass-Through Service
As #Maurice mentions, you can also treat the WF service as a back-end service and expose a REST service that simply calls through to the WF service.
This method is a bit clumsy, but has the advantage that it doesn't use anything unreleased or really complicated.
If the back-end service runs on the same machine as the REST service (which is probably what you'd do), you should expose the WF service using the named pipes binding. This binding is fast, but only works when the caller and callee are on the same box.
A further thought: your REST pass-through service is blocked while the back-end service is being called. If your WF service is not very fast, you'd benefit from making your REST service asynchronous so it doesn't block a thread pool thread while the WF service is being called.
There are no out of the box activities that will allow you to use REST with WF, the Receice is pure SOAP.
You can either build a custom REST Receive activity and use that with your workflow. Depending on your needs this is going to be quite a handful to a lot of work. The easy option is use use a standard REST WCF endpoint and convert the REST data to SOAP, pass rhe request on to the workflow, and do the reverse on the result message.
I have been handed a wsdl file + a number of xsd type definition files - the service I need to code against is not ready yet and I need to put together a fake service (so called a stub or mock) in order to be ready when the real thing comes along.
My question is - once I get the interface I need to implement from the wsdl, how do I setup dependency injection so that whenever the new service comes along I can add a service reference or a web reference and just edit the spring.net config file to swap in the service I want in the consumer? Is it even possible?
I found this article, specific to WCF, It's pretty good but he seems to have access to the service code and he's doing dependency injection on the service side rather than on the consumer side - in my case I will most likely just get a url, I will have to swap it with the fake local one and go from there.
Also is there a way of doing this only dependent on the way I consume the service but not on the way the service was put together? I mean, I shouldn't care less which technology was used to develop the service as long as I get a url to the wsdl.
Any pointers appreciated!
Just create an interface which maps to the webservice methods and use that on the client side. It doesn't matter if it's a local service, webservice, or whatever.
I've done what you are trying to do before, you can read about it here.
I have two related questions about Web services:
(1) I'm currently writing a set of applications, and it occurred to me that maybe I'm not using the right tool for the job. Here is the spec:
There are many Windows servers behind different VPNs and firewalls.
Each of the servers has a Windows service running, that reports various information about it to a centralized server, via a Web service, both of which I've written, and have access to.
So I'm both the producer and the consumer, and I'm staying on the same platform (.NET). Maybe a web service isn't the way to go? I'm using one purely because it's easy to write and deploy, and I'm the most comfortable with them. Should I really be using WCF for this?
(2) In the web service, I'm creating a State object to represent the state of the server, and sending it as a parameter. However, adding a service reference creates a proxy of the State class. It seems gacky to copy the properties of the State object to the proxy, and then send the proxy. Should I just replace the proxy class with the real class in the auto-generated code (i.e., include a reference to the State class instead)?
By "web services" I assume you mean an ASMX? I would go with WCF is possible, simply because you lose nothing but gain lots of flexibility. You could, for example, switch from XML-over-HTTP to Binary-over-TCP through a simple config change.
I would suggest to use WCF and use the Net.Tcp binding. It should be efficient enough for 300 clients. For the proxy class issue use the /reference option for the svcutil tool when you generate the proxy. This will allow you to share classes between server and client. I would not use this option if interoperability was a concern but since you stated that you develop both the clietn and the service and all in .Net it is a valid use in your case.
Your distinction between "Web Services" and WCF is a false distinction.
ASMX Web Services is the original .NET SOAP Web Service technology, introduced in .NET 1.0. It has been replaced by WCF, which can everything that ASMX can do, plus a whole lot more (including support for the WS-* standards).
Microsoft now considers ASMX Web Services, and the XML Serializer they're based on, to be "legacy technology". See "Microsoft says: ASMX Web Services are a “Legacy Technology”".
With WCF, since you have control of both sides of the operation, and can share the .dll in which the service contract is defined, you can and perhaps should be using ChannelFactory<IYourServiceContractHere> instead of auto-generating those ugly proxy classes with service references.
Here's the first hit I found on this topic: http://blogs.msdn.com/juveriak/archive/2008/02/03/using-channels-vs-proxies-in-wcf.aspx
If it is platform independent, I would certainly recommend WCF.
I've done exactly what your describing to great effect across more than 300 locations. I don't think you made the wrong call.
Another thing you could consider that would work well is using MSMQ. In this case, however, you'll either need to write event triggers (COM) or an event queue processing service.