I have an ASP.NET application that calls other web services through SSL (outside the application). I simply added a web reference (https://url/some.asmx) and used the web services and it works well. However, my questions are, how is the connection (channel) managed? is the connection to web services dropped after each web services call? or do they use the same connection (channel) for the subsequent calls? if they do, how long is the trusted connection kept alive?
Classic ASMX web services maintain the connection for a single request - that's why the methods you call via the web service class must be static. A SOAP call is very similar to a plain vanilla HTTP Request:
Open connection to URL
Pass in request - get/post, etc
Server renders an XML (SOAP) response
Connection is closed
Client processes response.
The web service framework wraps most of this so that you can conveniently access the web service as if it were a local object, but there is no server-side object instance persistence any more than there is for an ASPX page.
WCF services, on the other hand, maintain the connection until the proxy object is closed. This gives you a LOT of power, but, of course, with great power comes great responsibility.
update: link regarding ssl caching:
http://social.msdn.microsoft.com/forums/en-US/asmxandxml/thread/f86066e0-a24b-4d5e-873c-ed427d1faef7/
Related
I have an ASP.NET Owin Web Api which is load balanced, which means there are multiple instances of it which don´t know each other. The web api hosts a SignalR hub with an SQL Server Backplane (for synchronising between instances), so clients can exchange messages regardless of which instance of the web api they are connected to. Everything working so far.
Client session data is stored in the db. The web api needs this info for processing requests for the client. Because it would be too slow to read the session data from the db for every client request, the web api is reading it only once (on first request from the client session) and caching it in-memory. This also works across multiple instances of the web api as every instance is holding it´s own session data cache.
But now the clients should be allowed to change for example the language, which results in an updated language in the session data stored in the db. The web api instance which processes the "change-language"-request of course can react to the changed session data and clear the session from it´s cache, which will lead to a reread of the session data from the db on the next client request. But the other web api instances don´t know about the session data change, their caches now hold outdated session data.
The web api instance which processes the "change-language"-request would somehow need to notify the other instances to drop their cache for session xyz. Unfortunately the instances don´t know each other, but all instances host SignalR hubs which are synchronised through the SingalR SQL server backplane.
Unfortunately a SignalR hub cannot directly send and receive messages. A HubConnection (client) is needed to do that. So the idea is when every web api instance is connecting to it´s own SignalR hub, it would be able to send messages to itself, which are then spread out to the other instances via the SQL server backplane synchronisation. But a HubConnection can only be established with an URL (http://host:port/signalr) but the web api instance doesn´t know it´s own base url.
So finally my question is:
Is there any way to establish a HubConnection to a hub running in the same process without providing an URL (I have access to the hub object)?
If not, is there any way for a SignalR hub to spread out messages and listen to messages through the backplane without a client (hub-2-hub communication)?
If not what else could I do to notify other instances of my load balanced web api and advice them to drop their session data cache?
Solved through distributed caching (IDistributedCache), as mentioned by Panagiotis Kanavos in the comments.
Using SignalR, is it possible to update website clients from my WCF service if the service is not used by these clients directly?
I have a desktop application in .NET which has WCF service used internally using net.TCP protocol. This application changes one of the status fields in database table depending on certain user actions. I want to notify this change to end users who are accessing a different website hosted on the same web server.
I have tried one SignalR sample where notification works fine if it is sent from same website's host to its own client (stock ticker sample). But in my case, the message should go from WCF service to a website client.
IMO you should do an intermediate hop, for example having your website exposing an endpoint (you pick the technology) where you can post whenever you have a change to notify. Your WCF service would post there whenever there's a change, and the web app would process the post by broadcasting info to the target clients (can be all, or can be just some you filter with some logic behind the post). I use this pattern quite frequently, implementing it with HTTP POST. You would have no issues to implement the SignalR infrastructure in the web app, which is where your clients already connect to.
I'm trying to consume a Java Web Service from third party, so i dont have any control over it. I have a pfx file which is password protected, and i installed it in my development box.
This is the code i'm using:
var proxy = new MyServiceReference.WsaaServerBeanService();
var result = proxy.login("test");
I'm getting System.Net.Sockets.SocketError.TimedOut exception when invoking the login web method. The first thing that come to my mind is an authentication issue. Apart from installing the pfx, do i need to send some other info to the web server to authenticate?
System.Net.Sockets.SocketError.TimedOut
Does not indicate an authentication issue, it indicates that you either are not able to contact the remote web service endpoint, or you are and the service is taking too long to respond. Make sure you can actually hit the endpoint from your machine via telnet, a web browser etc...
Authentication failures will usually return immediately.
I have an application which is structured as:
Web Application - WCF Service - Database
All communicate to and from the database goes through the WCF Service, the Web Application is not able to directly talk to the database. I needed to protect the data as it travels across, so i setup SSL on my local machine to test and configured it in IIS, so now the WCF Service has to be hit using HTTPS. However, I did not setup my Web Application to use HTTPS, is that ok? I thought since the WCF Service is doing all the transferring of data, it's the only one that needs HTTPS.
Thanks.
If you're interested in encrypting your data, you need to make sure it's passed encrypted on all tiers of your application. From your description it seems that the data passed from the user to the WebApplication itself is unencrypted and therefor passed in clear text. This means that anyone that "listens" to the traffic between your users and the Web Application can intercept the data.
I recommend adding SSL on the Web Application too, to make sure that your data passes encrypted through all 3 tiers of your application.
I have a WCF service hosted at IIS7 web application. It's created by a WebServiceHostFactory. The client connects to a service calls the Collect method, and data are stored to DB. All working fine.
Now I would like to refresh page every time the new data are "collected" (i.e. the service method Collect is called).
My question is: What is the best approach ?
I was considering the CallbackContract, but this would require a singleton pattern (service is now PerCall), or is it a wrong assumption ? Is this approach possible ?
My logic is:
ASP.NET page subscribes to WCF service
the service singleton is created from now on
when method is called the services calls subscribers (clients)
there should be therefore only one service instance in order to subscription to work (or is it ?)
the client page refreshes itself
regards,
Kate
You can't refresh the page in a user's browser from the sever. Browsers use HTTP, which is a request-response protocol, so if the browser hasn't issued a request, it won't be looking for a response from your server.
If you have a Silverlight application hosted in a browser, that's a different story, but you didn't mention Silverlight anywhere. You would also be able to do what you're asking using WebSockets in HTML5, but that's not fully standardized yet.