We have to implement a number of integrations with VSO from different applications using BizTalk Server 2013 R2.
Can someone help me decide which will be the best approach among the below three options:
WCF Service:
We can create a WCF service which will have reference of library provided by VSO and have common methods to interact with VSO. We will use extensible client library for dot net provided by VSO.
Utility Class:
This class will have same methods as in WCF service above, but I guess this will be faster as it will be added inside the BizTalk Solution and will be called from orchestration.
Common BizTalk Orchestration using Web-Http Adapter for calling REST APIs provided by VSO.
Please help me decide among these approaches.
It really depends on your scenario and the need of reuse of VSO functionality within BizTalk or outside BizTalk.
If BizTalk if the only consumer of VSO functionality, then you can directly use .NET library provided by VSO. From design perspective, its a good practice to wrap a third party library within your own .net library with your specific functionality, which will allow you to reuse the functionality across different applications if required.
WCF Service you would only want in case you want to expose this functionality outside BizTalk environment or if you have multiple BizTalk environment in which you want to share the same implementation.
Related
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?
I'm trying to create some tool for testing WCF services. I'm aware of such products, but the goal is creating of mine one.
Main trouble is in calling wcf methods without having contracts. I've found solutions using scvutil.exe, but I need to make it on the on demand, as soon as I receive service address.
Any advices or links are appreciated.
Thanks.
Visual Studio provides a tool (the WcfTestClient) that will create a proxy for any WSDL based service (it doesn't have to be a WCF service). There are a few limitations with enumerations as data types and a few other quirks but it's a very useful tool. Here is the documentation for the tool.
I would like to use a technology that is used for communication between services and several thousands of clients. I came to know of WCF and read a little about it. While it looks attractive and has no interoperability issues, i would like to know about other leading technologies which can give me the same features as WCF ? Are there any open source technologies out there ? Also, which is the most widely used technology? I just want this information before i commit myself to WCF.
EDIT: By alternative to WCF, i mean to say that i am looking for a framework that will help me to implement a webservice in linux or any other platform. For example, the wcf simplifies the process of creating a webservice by the use of hard coded .NET applications. Similarly, i need a tool in linux. I came across mono,but found out that it is not complete and not very reliable.
I also provide an Open Source WCF alternative in ServiceStack A modern, code-first, DTO-driven, WCF replacement web services framework encouraging code and remote best-practices for creating DRY, high-perfomance, scalable REST web services.
There's no XML config, or code-gen and your one clean C# web service is enabled all JSON, XML, SOAP, JSV, CSV, HTML endpoints are enabled out-of-the-box. It includes generic sync/async service clients providing a fast, typed, client/server communication gateway end-to-end.
I don't think there is any .net framework with comparable features. But the core protocols of WCF such as WSDL/SOAP are not Microsoft specific so it's not as if you're tying yourself into a particular protocol, you're just choosing an implementation.
To put it another way if you choose to migrate away from .net in the future then I would say the WCF migration would be one of the easiest parts. But if you stay with .net WCF is almost certainly going to be the best implementation available given the investment Microsoft has in it (Azure is built on WCF for example).
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.