I was looking into the new WCF 4.5 Websocket services.
Ran into trouble while making calls to the service via browser.
As it turns out (after alot of googling stuff), when you're dealing with web browser as a client for your web-sockets, the only way WCF 4.5 will work is, if you define your OperationContract with 'Action="*"' tag [as there is no explicit way to call a 'specific' function from the browser, you can just call 'ws.send("asd")' to send messages to the server, hence you need to define a single handler for all the incomming calls to the service, similarly there can only be one callback function]
Now, if you use 'Action="*"' you can only use the datatype 'Message' while defining your contracts.
This is well and good, if you want to create an echo server, but lets say, you want to upload/download data, in the default (buffered) mode, the data transfer speeds are not what they are supposed to be (20mb file takes 40-50 secs). The only way to improve the speeds is by setting the mode as 'Streamed' (i tried using 'StreamResponse').
But now the trouble is, since we can only use 'Message' as the datatype while defining the Contracts, and Message uses SOAP type def., it uses the 'Buffered' mode, even if its explicitly defined otherwise. [please correct me if i am wrong here]
So, my question is, is there any way to achieve, 'streamed data transfer' in WCF 4.5 Websockets.
And, yes i am using byteStreamMessageEncoding (latest one provided in 4.5).
And i am using 'custom binding' in the web.config as 'netHttpBinding' doesnt work with browsers.
Ohk....
Since WCF didnt work..found out it can be done using ASP.Net 4.5 handlers.
Related
I'm using Portable Class Libraries to build service classes that all our UI technology with use to communicate with our services.
These libraries will support Silverlight, Asp.Net and any other .Net UI technology.
Since Silverlight is supported, all calls must be asynchronous.
With Silverlight, I can call CloseAsync() immediately after client.Method() call to the service.
However, I'm finding that doesn't work with Asp.Net clients.
I don't want to use CloseAync() in the completed code because if multiple async calls are being made you could run into a timing issue.
I'd rather not have to come up with a lot of logic something like putting a while loop in every async method to make sure CloseAsync() hasn't been called and completed.
Right now I'm testing just using Abort in the completed sections and everything appears to be working fine.
Just curious if anybody else out there knows of any problems we may run into Using Abort?
Thanks.
We're using .Net 4.5.
It depends on which binding you're using. If you're using a binding which uses sessions, then calling Close[Async] will attempt to first close that session (e.g., WSHttpBinding with reliable messaging), then close the connection, otherwise it will remain alive in the server side until it times out. If you're using a binding which does not use sessions (i.e., BasicHttpBinding), then they're pretty much equivalent.
Ok, let me first state some facts:
This is a web service that has been working. There are several .svc endpoints all of which worked. Right now though there's one that is not, meaning I can make method calls to it when I consume the service through another project but I keep getting null back as a result.
The code for the methods in this service that continually sends back null HAS NOT CHANGED
I did mess around with the endpoint configuration pointing it to a couple different servers. I tried the original server it was pointed to also. No matter what I can update the service fine but even if I set it back to the old endpoint path, I still get null back from my unit tests when testing calls to this service. The unit tests are running in the project that's consuming the service of course
I've checked the app.config and web.config for the service itself. As far as I can see everything looks fine...but again I'm new to WCF
I know this is pretty general but I'm looking for some guidance on where to start looking to see why I'm getting null back all of a sudden. The stored proc behind these methods have not changed. Again these method calls were working at some point in time in the past week but now it isn't.
This is very general, but a few things to try...
Try updating your service reference to ensure you have the most recent version of your proxy objects
Have you tried debugging inside your service and seeing if the expected return value is being returned from the service prior to the client getting it?
Do you catch all exceptions in the service and then return a result object or do you let exceptions fall through? If you let them fall through, the WCF channel might be getting faulted.
Try using Fiddler and seeing if the endpoints you think should be getting called are and if the response object is indeed null.
Use an old-school trick and write the result to a file on the server just before you return to the client. This will help you know whether or not it is a server-to-client serialization issue. You may even need to write to file right as the service gets the call to make sure your client is connecting.
What you really need to do is start by debugging inside your service and stepping through the code there. Make absolutely certain the SPROC is returning what you expect and then there isn't an environmental bug introduced.
When you have weird problems with WCF, the fist thing to do it configure WCF tracing. It's a very powerful tool. You can even see the content of messages.
Here is the official doc on this: Configuring WCF Tracing
We are migrating set of WSE services to WCF platform.
The new WCF services are called over secured HTTP. (https)
I want to invoke an operation contract of one WCF service from another. Both the services are mostly hosted in the same IIS, but they can be on separate IIS server.
Do I need to take care of some things (which i obviously do not know at present) in this scenario?
Is there any special calling mechanism in this case?
Does calling mechanism change when call is synchronous and when it is asynchronous?
Can you suggest some type of binding which is readily available in this case?
1.) If the services are on the same box, use named pipes, unless you have any compelling reason not to, to communicate with each other. While WCF proper doesn't care about what you're doing as long as the address, binding and contract all match up (see what I did there?), .NET will when it comes to making network connections. The fewer you use, the better. (see http://msdn.microsoft.com/en-us/library/fb6y0fyc.aspx for more details)
2.) As stated in #1, if they're talking on the same box, use named pipes unless there's a good reason not to.
3.) Can you provide a little more detail on what you mean by this or what you're planning on doing? A lot of this is built out for you, so assuming you're familiar with implementing async methods and using async callbacks, the short answer is yes, it's different than calling an operation synchronously, but that's to be expected. Or do you mean IsOneWay = true? If that's the case, the calling mechanism is the same but there can be a number of other gotchas (e.g. faults)
4.) Named Pipes on the same box, BasicHttp otherwise (unless you need any of the additional features from WS).
but they can be on separate IIS server
In this case, you either can't use Windows authentication (if you were using it) or you have to set up some special delegates stuff on the domain to make it work. Windows Authentication won't "hop" between different servers. Here's some info on that, there's a lot of reading out there on the subject.
If they stay on the same server or you're not using Windows authentication, then it shouldn't be a problem.
Does calling mechanism change when call is synchronous and when it is
asynchronous?
Shouldn't matter, it's all the same on the service end. I will say that if the client calls X and X calls Y, X might as well call Y synchronously because it can't return to the client until Y is done anyway. (If X calls Y and Z, then X making async calls may make more sense.)
Can you suggest some type of binding which is readily available in
this case?
If you were using WSE before, then BasicHttpBinding is going to be the one closest to what you were doing and will look pretty familiar in what it outputs. It's also the simplest one to work with.
There shouldn't be anything special needed just because a WCF service method calls another WCF service. A WCF service doesn't "care" what other application types are calling its methods so long as they use the correct service contract, data contract, endpoint, and binding settings.
Just make sure that both service methods return promptly, and don't cause execution to block for long periods of time.
Just wondering under what circumstances would you prefer to generate a proxy from a WCF service when you can just invoke calls using the ChannelFactory?
This way you won't have to generate a proxy and worry about regenerating a proxy when the server is updated?
Thanks
There are 3 basic ways to create a WCF client:
Let Visual Studio generate your proxy. This auto generates code that connects to the service by reading the WSDL. If the service changes for any reason you have to regenerate it. The big advantage of this is that it is easy to set up - VS has a wizard and it's all automatic. The disadvantage is that you're relying on VS to do all the hard work for you, and so you lose control.
Use ChannelFactory with a known interface. This relies on you having local interfaces that describe the service (the service contract). The big advantage is that can manage change much more easily - you still have to recompile and fix changes, but now you're not regenerating code, you're referencing the new interfaces. Commonly this is used when you control both server and client as both can be much more easily mocked for unit testing. However the interfaces can be written for any service, even REST ones - take a look at this Twitter API.
Write your own proxy - this is fairly easy to do, especially for REST services, using the HttpClient or WebClient. This gives you the most fine grain control, but at the cost of lots of service API being in strings. For instance: var content = new HttpClient().Get("http://yoursite.com/resource/id").Content; - if the details of the API change you won't encounter an error until runtime.
Personally I've never liked option 1 - relying on the auto generated code is messy and loses too much control. Plus it often creates serialisation issues - I end up with two identical classes (one in the server code, one auto generated) which can be tided up but is a pain.
Option 2 should be perfect, but Channels are a little too limiting - for instance they completely lose the content of HTTP errors. That said having interfaces that describe the service is much easier to code with and maintain.
I use ChannelFactory along with MetadataResolver.Resolve method. Client configuration is a bother, so I get my ServiceEndpoint from the server.
When you use ChannelFactory(Of T), T is either the original contract that you can get from a reference in you project or a generated contract instance. In some projects, I generated the code from a Service Reference because I could not add a reference to the contract dll. You can even generate an asynch contract with the service reference and use that contract interface with ChannelFactory.
The main point of using ChannelFactory for me was to get rid of the WCF client config information. In the sample code below, you can see how to achieve a WCF client without config.
Dim fixedAddress = "net.tcp://server/service.svc/mex"
Dim availableBindings = MetadataResolver.Resolve(GetType(ContractAssembly.IContractName), New EndpointAddress(fixedAddress))
factoryService = New ChannelFactory(Of ContractAssembly.IContractName)(availableBindings(0))
accesService = factoryService.CreateChannel()
In my final project, the availableBindings are checked to use net.tcp or net.pipe if available. That way, I can use the best available binding for my needs. I only rely on the fact that a metadata endpoint exist on the server.
I hope this helps
BTW, this is done using .NET 3.5. However it does work also with 4.0.
Well in order to use ChannelFactory<T> you must be willing to share contract assemblies between the service and the client. If this is okay with you then ChannelFactory<T> can save you some time.
The proxy will build async functions for which is kind of nice.
My answer is a kind of summary of Keith's and Andrew Hare's answers.
If you do not control server, but have only WSDL/URL- generate proxy using Visual Studio or svcutil. (Note that Visual Studio sometimes failed, when svcutil works better).
When you control both server and client, share interfaces/contracts and call ChannelFactory
.
It's not just a matter of time saved. Using the WSDL generated proxy is dangerous because if you forget to update the service reference you can leave the solution in an inconsistent state. Everything compiles but the service contract is broken. I definetly suggest to use a ChannelFactory whenever possible, you make your life much easier.
A possible alternative could be to write a prebuild script that calls the SVCUtil utility to create the proxy everytime you build your project, but anyway ChannelFactory is much more neat and elegant.
I have a VB.NET web service that calls a third party web service. How can I view the SOAP message generated by .NET before it is sent to the third party web service and how can I see the SOAP response before it is serialized by .NET.
When creating a standalone EXE, I see the Reference.vb file that is automatically generated, but don't see a similar file when my project is a web service. I have found lots of C# code to do this, but none in VB.NET.
Edit - Fiddler and TCP loggers are great, but will not work for my purposes. I need to be able to access the raw SOAP messages from within the application so I can log them or modify them. I need to do more than just see the messages going back and forth.
You can use fiddler or a tcp sniffer to filter and identify all outgoing and incoming traffic on your host.
This is if you want to see the xml request and response.
How about using an extension to allow you to examine the SOAP message?
Accessing Raw SOAP Messages in ASP.NET Web Services
http://msdn.microsoft.com/en-us/magazine/cc188761.aspx
I was trying to do the same thing and this seems to work for me:
Dim message As String = OperationContext.Current.RequestContext.RequestMessage.ToString()
I didn't think it would be that easy since most of the time ToString() returns the name of the class, but I tried it out and low and behold.
I know you asked this back in January so if since then you've figured out a better way let me know.
Please note that if you're catching the exception in a class that implements IErrorHandler then you have to perform this operation from within the ProvideFault() method instead of the HandleError() method because the context is closed before it gets to call the HandleError() method.
Hope this helps.