I have a 3rd party web service, which I intend to use from 2 different applications:
a Windows Workflow (WF) project
a website
Right now, from these 2 apps I manually add the reference to the 3rd party web service & call the required method. This means I have this proxy layer generated in 2 places.
What am looking for is a way to create (am not sure about the correct word to use, sorry guys) the 3rd party web service in one place & have the 2 applications re-use it.
Can this be achieved using WCF, something like wrapping the 3rd party web service in WCF.
Is this approach right?any help or pointers would be a great help, haven't done much service based development.
Environment: The website, the WF project resides on 2 different servers (windows 2003 R2).
Environment(development): windows 7 enterprise/vs 2010 / c#
Thanks
More detail:
Think I dint use the right words in my first query, the following is what am looking for & why I need it that way,I need to call the 3rd party web service from a new WCF service.This new WCF service will be called from other applications(winforms/WF/website) instead of calling the 3rd party service.The idea is to able to switch the 3rd party service(vendore) without changing the implementation & in one place.We use an hr-xml format for request/response & all our vendors(exisiting or future) support the hr-xml format for the industry we are in.If we use a class library, then to change vendor, we should recompile & distribute the dll correct,we dont want to do that. I am not sure about an architecture to be followed to achieve this whole functionaity.Any pointers in the right direction would be a great help.
Thanks
Your quest makes great sense indeed - and I think it should be quite easy to accomplish:
create a new class library assembly ("WebServiceClient" or whatever you want to call it)
inside that new project, do you Add Service Reference - this will create the necessary WCF proxy classes and the config file
compile that class library
From both your apps, you should be able to reference that web service client assembly, and use it - you have the code for the client side proxy only inside that common assembly, but you can use it from any number of apps.
One point to remember: you will need to copy&paste the config for the web service to the main application's config (app.config for a Winforms/console app, web.config for a website/web app) since it cannot be read directly from a class library's config file (that won't be used by .NET).
In this case, I think, WCF service will be the gr8 idea. You dont want to recombile the client applications if the vendor is changed.
Related
I have created a silver-light website.
Silver-light has part for the client side and part for the server side.
Now, I want to crate another site in .net MVC 4.
I can't really understand two things.
The first is, where the site will be executed?? Client side or server side??
for example if i have a LINQ function in the controller, where it will be executed??
The second is, may i use WCF like in silver-light?? Or i can just add .edmx file(ado.entity file) in the project??
Yes you can able to use WCF service in silver-light application. You must need to add the reference of the WCF application
The answer to your first question is that MVC is a server-side technology. You can utilize JavaScript and other methods to utilize the technology for client-side functionality, but it requires the controllers, views and models to execute on the server.
The answer to the second question is that WCF can be used just like Silverlight in MVC, although depending on how you utilize it, depends on if it is consumed on the client-side or not. If you access WCF through the Controller, its done on the server side. If you consume it through AJAX/jQuery then you are handling it through the client-side.
I'm a bit new to WCF, so please bear with me. I have a very simple REST Service written up using .NET 3.5, which is exposed through a asp.net web application through a SVC file. Everything is working as expected.
What I would like to know is if it is possible for me to create a plugin structure in WCF, so that I can have third party developers write up expose their functionality through my service. I'm hoping it's possible to dynamically create my endpoints through code, at the moment everything is in my web.config and service.svc files (as far as exposing the contract).
In the end, what I would like to have an active running service that auto checks for new assemblies (if added to the plugins directory), and would automatically add new endpoints, which could have completely different functionalities. One could be a file transfer plugin, another could be a calculator, etc.
But first I need to know if it's even feasible... currently I'm looking into MEF to see if that might help out, as I'm used to just loading DLLs manually (in Desktop apps).
It is possible to use MEF through WCF, I have worked on a similar project in the past. You could expose functions from the plugin DLL's through MEF assume the implementer of the MEF interface is implimenting a function that starts a new WCF service with it's own end points, then call that function from the main service.
See some sample projects below, although none of them are doing what you are asking it is possible that the MEF plugins could have a service host that's starting their very own service with their own end points.
Creating WCF Service Extensibility through MEF
A sample demonstrating how WCF and MEF play together
I have a WCF deployed on IIS. Now by adding web reference of it i am using it on my app.
So I have two questions:
Is it the best method of consuming WCF.
If the answer of first question is yes then what is the role of svcutil.exc, I mean what is the use of creating wcf proxy class. and if the answer is "No" then why?
It is the easiest solution if you develop with visual studio and have access the remote WCF service.
If you are developing using another IDE, you might want to use SvcUtil to generate your proxies.
If you prefer to have a simple CS file containing the generated client, you might also choose to generate it using SvcUtil.
You may also completely ignore SvcUtil and the Service Reference wizard and use the ChannelFactory class to generate proxies dynamically.
You should use "Add Service Reference" in Visual Studio (not Add Web Reference) for WCF.
It is the easiest way - since you can do it right in Visual Studio. What it does under the covers is basically call svcutil.exe (or you can do that manually, from the command line yourself), and create a service proxy class for use on the client side.
The use of svcutil.exe is many fold - you can create a client proxy class from a running service (or from an existing WSDL/XSD file), you can verify services, you can export metadata from a service for clients to consume, and a great many more options. It's the "Swiss Army Knife" of WCF tools.
WCF uses a concept that all calls to your service must go through a client proxy - this is the place where the entire WCF runtime lives, and where all the WCF extensibility points are located. This proxy converts your call to a method on the client into a serialized message that gets sent across the network to the server for processing, and it also handles "unpacking" the response from the call back into classes and objects on your client side for your use.
Adding a service reference is the quickest and easiest way but not always the best way. If you want performance then using ChannelFactory<T> is the way to go. You should know different ways to create a client side proxy and customisations that you can do.
An excellent resource is WcfGuidanceForWpf. Don't let the WPF in it scare you as it is really an excellent guidance for general WCF as well.
We currently have a WCF Service which is beginning to reach it's limits performance wise.
We have decided to add another server which will host another instance of the WCF Service.
We have web applications which must communicate with a specific server based on context... e.g. If the web application is dealing with objects from ServiceInstance1 then requests must be directed to ServiceInstance1's EndPoint. If the web application is dealing with objects from ServiceInstance2 then requests must be directed to ServiceInstance2's EndPoint.
I initially thought that a "Intermediate Service" or "Service Manager" could be created, the web application's Service Reference would be updated from the individual Service Instance to the "Intermediate Service" or "Service Manager" and said service would act as a "Broker" to the various Service Instances.
How is this accomplished?
I have currently added a ServiceReference to each service from the Manager however it seems that once a Service is "Referenced" it's types becomes specific to the that of the ServiceReference e.g.
ServiceInstance1's type's are all {ServiceInstance1}.
ServiceInstance2's type's are all {ServiceInstance2}.
I need the types to be the same on the web application end, so this obviously seems like the wrong way to do it.
I would also like that when methods are called on the client generated from referencing the "Intermediate Service" or "Service Manager" that the correct Service Instance is invoked, e.g.
IServiceManager.GetProjectById( {GUID} ) ->
Comes Back to ServiceManager ->
Determines which host has the project and returns the ProjectObject from the correct ServiceInstance.
Where ProjectObject is a Type Defined in ServiceInstance1 and ServiceInstance2.
I think the original service needs to have some of the DLL's pulled out so they can be referenced from the web application side and ServiceManager and a GenericWCF Client can be made.
If I am right hooray for me If someone can point me in the right direction I would appreciate it. If I am wrong can someone please scold me and show me how this is properly done!
The way to solve your problem is to create shared assembly with types used by both services. Reference this assembly on the client consuming your services (manager) and when creating proxies by Add service reference mark Reuse types from referenced assemblies.
What you are building is very simple message router. In WCF 4.0 there is additional support for routing services so you should check those features before developing your own. For WCF 3.5 MSDN magazine contains articles about building message router - part 1, part 2.
Just to Answer this and close it I wound up utilizing the Routing Strategy in .Net 4.0 and custom client class which I modeled after the generated classes from the Proxy.
Before I had the custom client ready I used the auto generated client code and I derived a class from it which allow me to change which service it was connecting to. I determined which service via a property which was made available on all service objects which were serialized.
Long story short this is working 100% as expected including the ServiceManager which can even be bypassed on certain calls which we allow.
We even have the ability to move a project from server to server during run time!
Thanks to everyone who helped! (Especially myself for actually doing the work without being spoon fed)
The easiest way to accomplish what you're trying to do is to stop generating your proxies using the server-hosted URL of the service. Instead, generate your proxies from the *.xsd and *.wsdl locally, and merely change the URL of the endpoint. Alternatively, you can use ChannelFactory<T> to generate proxies on-the-fly, and reference your interface .dll on the client side.
Once you've done that, you can use any common webserver load balancing technique to balance the load between the servers.
Not to put too fine a point on it, but Visual Studio's "Service Reference" is not useful, and should not be used, for services you develop. It's useful only for services developed externally, whose URL and contracts are likely to NEVER change. I personally have never had occasion to use it. For your own services, you should probably be using ChannelFactory<T> or a class based on ClientBase<T> to work out the proxies.
I have a web application I'm deploying at multiple clients. Each client will be consuming a web service that was developed by a third party and is hosted at each client location. The soap.location will be different for each deployment.
I am looking to avoid having to do separate compiles foe each client.
This blog post has a potential solution but is missing a crucial element; how to make the client use the derived class for the soap calls.
Any help would be appreciated. Thank you.
Check How can I dynamically switch web service addresses in .NET without a recompile