I have written a WCF service that uploads a file to the server. It is configured to stream the file, because they may be fairly large. I set transferMode = Streamed in my web.config and set various config size settings to fairly large-ish sizes.
This work fine for my test client. I had to set the client configurations manually to have transferMode= Streamed -- by default when I included the service reference it had set it to Buffered.
But the guy who is consuming my service is complaining about having to do that manual step. He keeps telling me something is wrong with my service and I need to fix it. I don't see anything that I can "do" about the settings not propagating to the client. And it work fine if he uses the config settings I sent him.
Is there something I should be doing? And if not is there some kind of proof I can offer this person to convince him my service is not broken? Anyone have a link to an article explaining this?
If the guy's platform, who is consuming your service, is .Net, then you can create client library with correct configuration, which consumes your service and give him to use it.
There are well known article WCF the Manual Way… the Right Way
Related
I have a windows service which monitors a directory and whenever it detects a new file it will send that file to my web service for processing. I've now noticed that it's become a bit of a bottle neck sending the file using the web service request, so I was trying to work out what the alternatives are?
I've thought of having the Windows Service doing the processing directly (which I'd ideally like), but this isn't an option. Would it be better to be using WCF? In 90% of deployments the Web Service is on the same server as the Windows Service, but there is that 10% where it's on different servers. Just not sure what the best approach would be here...
EDIT: I'm sending the file as a byte[] to the Web Service, this is what I am wanting to somehow speed up. So the question I have is, would using another approach help speed this up, such as using WCF and a different protocol? I understand there is always an overhead, but trying to minimize this.
WCF & Bindings: Changing to WCF offers several bindings you can use that are more efficient to transmit data in a LAN, e.g. NetTcpBinding or Named Pipes (local only). So using WCF is a good step if you don't want to introduce bigger changes into your application.
Hybrid approach:
However, the best way to speed up at least for the 90% of deployments that host both components on the same machine is to remove the process boundary in these cases. As you mention, you've already thought about that. So just in case that the reason for putting the idea aside are the 10% of deployments that would require a distributed installation: By using an interface with an implementation for local procession and one for remote transmission, you could implement a configurable approach that supports both scenarios (90% very efficient, 10% at least not slower as before).
Scaling down data sizes:
Another - obvious - way to speed things up is to filter or compress the file contents before transmitting them to the service.
File path instead of contents:
As I understand your environment, the machines that host the services are at least close to each other (LAN, no firewall issues, ...). So it might also be a viable option not to transmit the file contents to the service, but to notify the service of the file path and have the web service access the file directly. Though not a very beautiful way with certain downsides (e.g. account of web service must be able to access the file, path must also be accessible from the web service) you'd at least get rid of the inefficient transmission of the files and substitute that with a protocol that is built for file access. Also in the 90% of installations where both services run on the same machine, the web service would do a local file access that should be very fast.
I was wondering how you can send data from the client to the host. Currently I have 2 projects and one WCF library. One of the projects is a pump which is the client and I want it to be able to send data to the host? Although I may have a misunderstanding of how WCF works. I was wondering if anyone could point me in the right direction. The problem requires me to use WCF. I want to be able to pass a list of strings to the host.
WCF can send data over many different transport protocols like MSMQ and http. It also enables message security, distributed transactions and other more complex features of a distributed system.
You need to create a WCF service, which is available as a template in Visual Studio. The server should be hosted as a stand alone program os as a web application in IIS.
Afterwards you need to create a client, that can communicate with the server.
WCF is however a large and complicated framework and you should not expect to be able to just scratch the surface and build a system. You need some googling and could possibly start with MS own tutorials.
If you need real useful answers you should be more specific about your program and the client and server operations as well as the deployment scenario.
As faester already said, WCF is a large framework and you can not make a good application by just copy-pasting the code into your project.
You should really read into the matter and then create your programming masterpiece.
faester gave you a link, but it's for basic WCF client-server communication.
Here are some good links on sending and receiving data via WCF:
Data transfer and architectural overwiev
Using the Message class
For a simpler, task-oriented view of how to send and receive data, see:
Specifying Data Transfer in Service Contracts
I hope that this will help you and the people yet to come to this question.
My application is self-hosting several wcf services.
This creates quite a mess in the application configuration file and quite difficult to maintain.
I would like to find a way to separate those configurations, so that each wcf services will have it's own configuration file.
Thank you
Edit:
I've found a way to specify a Client's config file, tried it, it works.
Now I just need to find how to do it for the self-host service, anyone?
I've found the answer.
This post includes the entire solution both on client and host side.
Thanks for those who answered.
From time to time we need to test why a certain request coming from our MQ to a WCF service failed. I need to be able to debug the service and find out where it went wrong and resolve the issue. The only information i have is the XML request that was sent to the service. Before we moved to WCF i used a custom tool to send the request to my ASMX debug instance but since we moved to WCF I dont seem to have that option. All the clients i have tried only allow you to fill in the fields through a UI and this is not an option when dealing with huge requests.
Is there a free or open source client that will allow me to do this? I have searched and tried loads but none seem to do it.
Alternatively is there a tutorial or article on writing a test client of this kind? Again i have searched but there seems to be a lack of information on WCF clients and a huge amount on the services.
tl;dr; Im looking for a WCF test client that will allow me to paste in an XML request and send it to a WCF service or a tutorial that will start me in the right direction.
Of course it is not free, but one of our teams is using Altova XMLSpy for that purpose and it works fine.
You can also check (Not sure they will allow you to edit SOAP, but have a try):
SoapUI
WCF Storm
Also check Web Service Studio 2.0 I have tried it will allow you to edit requests.
Not sure I totally understand what you're looking for:
to see the MSMQ messages, you should open the MMC snapin for MSMQ administration on your server where the MSMQ queues live - is that what you're looking for?
in order to create and send out arbitrary XML messages, have a look at SoapUI which is available in a free (and already very capable) version, or alternatively look at SoapBits
Anyone have a pointer to a C# configuration class that a .NET service can use to do configurations via an admin socket or other control port? I'd rather do this than a filewatcher on the app.config file.
We have some long running C#/.NET services (24h X 6.5 days/week) that may need to be re-configured on the fly. I'm looking for a good way to push out config changes to a .NET service
Any pointers appreciated.
Craig
How about exposing a WCF service for configuration purposes? That way you can get a nicely typed API for configuration of the service.
To expand on Manga's answer;
I'd recommend hosting a WCF endpoint on the same IIS box hosting your long running C#/.NET services. This endpoint run on an arbitrary port.
Its responsiblity would simply be to change the appconfig(s) of your running service(s). You could specify a config type decorated with DataContract to allow for a nice configuration API exposed to the client responsible for pushing the config changes.
I'm not experienced with WCF, but I've typically solved this problem by rolling my own API via RPC. Expose some methods to add/remove/update certain configuration items, throw some sort of UI on top of it, and you can update your service on the fly.