I have to integrate with a third-party web-service (behind firewall), and I do have their WSDL and proxy class.
I want to develop the client stuff outside the firewall.
What is the best approach to mock the web-service to ease integration with them?
Do I create a web-service project on my side? Somehow use their proxy classes ad mock the methods? This would create the service references so I can just change the target URL when the time comes.
Or do I create a service layer that returns mock classes in my dev. environment but would use real web-services at run-time?
The former approach would take a lot of work, I would think.
Any ideas?
With just the WSDL, you could host a mock service using soapUI.
I've used the latter approach to good effect in our projects. I've usually found that my apps use a subset of the functionality exposed by a given web service's API, to it's usually made good sense to expose a simpler API to my client code that's more streamlined and that reflects the workflow of my client better. So, since the way I typically use web services already involves writing an abstraction layer, replacing the endpoint on the other side of my adapter classes with a mock service is a very low-friction way to test interaction with the service.
Related
I have an ASP.net Core application which needs to call a service using service remoting.
Is it a good idea to do something like this in my Startup?:
services.AddSingleton<IHelloWorldService>(ServiceProxy.Create<IHelloWorldService>(new Uri("fabric:/Demo/HelloWorldService")));
As far as I'm aware, all ServiceProxy.Create() is pretty "simple" and just proxies the calls -- so this sounds safe enough to do?
That's safe to do in the sense that the proxy object will always work. The nice thing about this is that you have a very familiar pattern where you inject a service interface like you do in a domain-driven application.
If fabric:/Demo/HelloWorldService is partitioned though, then this won't work out too well, because you need a new proxy for each partition. In that case, you should inject an IServiceProxyFactory, which can be used to create proxies for different partition and can still be mocked out for unit testing.
I need to calling our C# Methods from another server to perform some Action. I use C# in both servers. One is our Service Application, another one is a WPF application where I consume my Service.
Prefer I use a WCF or WebAPI service for Service Application?
Most People prefer to use Web Api, but web doesn't expose metadata for creating proxy by service.
which one is simple and better choose?
You may use either WCF or WebAPI, if multiple platforms (Mobile, Web, Other Service) are going to interact with your service, then I would recommend Web API, otherwise you may use WCF. Similar discussion has already happened in another question, please refer this link, hope this will be useful
Getting a web service and using android to consume them?
My issue it regarding creating a dummy WCF service which can be used at development side, when the REAL WCF service is not available or is down.
In my current assignment, the issue is that the web hosted WCF service from client is not always available for developer side. This hampers the development work as we are not able to verify/unit test the client side code.
Any solutions in sight? I have been searching /reading about mocking wcf with different available mocking frameworks, but still not clear about the right way.
Thanks in advance !
Without talking about frameworks - to call your srevice, you create client (proxy) instance, right?
You can move its generation to separate method, which will return your mock (injected by DI, injected by setter property in Unit test,. . .).
I'm implementing a WCF web service based on WF. This web service consumes other web services which I'm not in charge of. So basically my service workflow contains several Send activities.
I'm following the TDD approach, so the service implementation is to be covered by unit tests. I want to test proper invocation of 3rd party services.
In a non-workflow case I would mock the external services via NMock. But in my case I cannot control the instantiation the workflow instance and I have no idea on how to trick the Send activities to use the mock objects instead of real services endpoints.
Although Unit Testing Workflows And Activities article on MSDN mentions mocks I couldn't find any complete example of mocking the remote end of Send activity.
Any idea on how to do that?
please try Moles framework. http://research.microsoft.com/en-us/projects/pex/
There are samples about how to mock the sharepoint service. I believe the same trick should apply to WF workflow.
I have tried to mock the sqlconnection, Entity framework, web service call, it works very neat. Basically, it can mock almost any .net objects.
Using ServiceAgents wrappers for your web services would be one possible way of doing it.
This is a pattern i have followed in previous projects of mine.
Since they are interface based, you can easily mock out the services.
There are other advantages to this pattern (besides unit testing) including being able to abstract your application from external dependencies to a certain extent. However it does add the overhead of creating another class layer on top of the services.
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.