My existing scenario is below:
I have an SQL server which resides in a main company office. The company has another branch which is 60 miles apart.
I have a WPF application installed in computers in the main office and the branch which connects to the SQL server in the main office for printing records etc.
I am specifying the connection parameters in the app.config file as below:
<add name="CompanyEntities" connectionString="metadata=res://*/LabModel.csdl|res://*/LabModel.ssdl|res://*/LabModel.msl;provider=System.Data.SqlClient;provider connection string="Data Source=publicIPaddress of remote SQL here;Initial Catalog=databasename;Persist Security Info=True;User ID=sa;Password=password;MultipleActiveResultSets=True"" providerName="System.Data.EntityClient" />
My problem is that the application in the branch hangs for ever at certain times. So my question is whether its the best practice to use WCF for connecting to the remote SQL server?
Which is the best way to go about it? Is there any links which best discribes this?
In your current scenario, WCF is useless to you. If you write a server side application, that manages the database connection, you can use WCF to send the data to your clients. However that requires your client side software adapted to the use of WCF also, but in that case your clients wouldn't access the database (you would change from a two-layer architecture to a three-layer architecture). It might solve your problems, and it might introduce some other problems.
The hanging problem you describe could be caused by many things. For example you can run out of database connections, get into a deadlock (altough that transaction would be terminated by the server normally), or just simply have a lock on data being edited, and the employee using it going for a break.
It is also possible, that the problem is not with the database connection, but something in the client side code. Since I have no details, I can not tell you anything more specific.
Picking on the wording you chose, I don't think you'll be "connecting to the remote SQL server" using WCF. However, you can certainly use WCF to host a service that provides your client (WPF app) with secure access to your data, though it will do so indirectly. This approach will be quite different from the approach you currently have: accessing the server directly from the WPF app.
Although I haven't used it myself, I believe one approach may be WCF Data Services. If you only need a few operations in your service (e.g. GetRecord) for printing you may also be able to just roll your own WCF service that just provides "Records" to your client app. Any introductory book or tutorial on WCF will probably get you on your way.
The above answers the questions you seemed to be asking. However, WCF doesn't solve connection issues for you: if you say "the application [...] hangs forever at certain times" you should investigate that no matter what. But that's a different question.
Related
I have been doing much research into this and was wondering what the best approach is, imagine the scenario where you have a WPF application that is being distributed to many users, this application has to connect to a database server. Connecting to a database is not a problem its how secure the connection is as external users will have access to the application.
within the app.config file connection strings can be pointed to the server, however releasing the password and server IP address is not a good idea. from research, other people recommended encrypting the data, but sure this is still got a degree of vulnerability.
the next approach is to use WCF, this i have limited knowledge on and not sure if this approach is correct.
Am I safe in encrypting the connection strings or is there more to it than that, I just want to be extra careful when dealing with sensitive data.
A common way is to add a server layer between your wpf app and the database. It can be a REST api or other web services as you like. In terms of technologies you can choose, wcf is one. But wcf is not easy to get started with if you do not have experience of dealing with services. I suggest to try Asp.Net's Web Api project to quickly establish a Rest Service (http://www.asp.net/web-api/overview/data/using-web-api-with-entity-framework/part-1 ).
This server layer will protect your database information (connection string etc). Also, allowing your application directly querying the database will potentially prevent the database from evolving -- for example, the insert query may break on the client side when you add a constraint on a table. Having a server in between can solve this future headache as you can update the server side implementation and database simultaneously.
In case of data sensitive, I would like to prefer SOA architecture will most suitable to you. WCF will be good option but think about RestFulWCF or WebApi2.0 (popular for multi platform support).
Hope this will help :)
Say I have an application that wants to return information from an online database, it's a public application which anyone has free access to. What is a safe approach for these clients to communicate with the database?
I am interested in how this is done in professional environments. When I tried to do research all I could find were examples of clients connecting directly to the database themselves, leaving their connection strings in the code, these examples I'm sure were for server sided/private applications. But in my scenario I assume there has to be a proxy in between.
Do I set up a web server with PHP scripts that returns results or do I program a server that listens for TCP/IP connections? I feel there is a better way but can't lay my finger on it.
What my question boils down to is essentially..
What technique is used for this 'proxy' and client to communicate? What does the setup look like? Even a diagram would be great. Assume I am working in C#.
we are evaluating a new project which will have a .NET Server which is available in the internet. We have access to the server but the hosting is done by a 3rd party company.
We are evaluating using WCF on the .NET Server. (I have no professional experience with WCF and just reading into the topic). The WCF service will talk to a SQL Server to perform its duties.
Here is the scenario:
Multiple client machines running our own ActionScript software will connect to that .NET Server.
Clients might be online 24/7 and should periodically poll our server to tell the server that they are there.
A client needs to be able to login, and only if the login has worked the other calls will be allowed and at some point it logs out. So we need to "remember" the state with a particual client...
Highest expected load is around 1000 Clients, of which 500 will only do polling while the other 500 will be "active". "Active" means a maximum of 1 call each minute, no heavy payload in each call, neither in the request nor in the response, just 1-3 database accesses per call.
We already tested some "HelloWorld" with ActionScript and WCF using BasicHttp(s)Binding.
But because we need session handling we were thinking about taking using the wsHttpBinding binding because it can provide us WCF Sessions.
So far so good, but then I stumbled upon the fact that it should
However:
I find that in my Oreilly WCF Services 3rd edition book (Page 177) it is written
and even Microsoft is writing to be careful using that:
http://msdn.microsoft.com/en-us/magazine/cc163590.aspx
"A service configured for private sessions cannot typically support more than a few dozen (or perhaps up to a few hundred) outstanding clients due to the cost associated with each such dedicated service instance."
So because we need to identify the state with each client, we could of course implement our own "Session Handling" on top of stateless HttpBindingBinding, and make a call to that SessionHandling class each time when my WCF methods get called, but I am reluctant to do anything like that, it looks to me like thousands of people should already have faced the same problem.
So, my question now is:
Do you think wsHttpBinding on my server could handle the payload?
How "bad" is it really to go with wsHttpBinding on WCF? Does anybody already have experience with this? Can I use it? What would you use?
Final Remarks:
I am not limited to WCF if we dont like it, we just shall do an evaluation.
From the companies point of view it would also be fine to go for a protobuf-RPC or XML-RPC solution over TCP and the ActionScript clients implementing that. (just examples!) So no need for hosting WCF in IIS on the server as long as the coding part is comfortable (enough) for the programmers on both sides and the ADMINISTRATION on the deployed server is not too much either. With just making some TCP-ports based communication I am a bit afraid what it would mean for the administration in regards to firewall and stuff. Payload is not an issue, client processing power is also not an issue. The only thing I am concerned about is scalability of the server and security.
Thanks in advance for any suggestions!
I would not be concerned with scalability. You can always add a server or two to your farm in case of issues.
I would rather be concerned with your architecture and the need to store anything in session - are you sure about that?
Note that you don't need ws binding to support sessions, basic binding supports sessions as well.
Hosting services commonly provide support for webapps (say ASP.net, Rails or Django) and a few databases (e.g. SQLServer, MySQL).
I prefer C# WinForms for most of my own apps (speed of graphics updates eg.), but I'd like to have a webbased DB behind it so I can access it from multiple locations.
Is there a reason that I couldn't use such a web-provider just for my databases, i.e. not serve a dynamic webpage but just answer my sql queries?
Existing posts that appear to answer similar questions exist, but I would like to obtain more clarity.
E.g. does the webserver provide additional security that is otherwise hard to obtain?
Does the 'correct' answer include the keyword WCF? Do I need the hosting service to support WCF explicitly?
There is no technical limitation in accomplishing what you are asking, but most of the hosting providers (shared hosting mainly) restrict access to their database to be within their internal network. If you can find a hosting provider who provides you the option to connect from external network you are good to go.
One thing you want to keep in mind when you are distributing your winforms client is that the connection string can be extracted by the end user if he is a smart enough person. It would be prudent to encrypt the connection string in the configuration file and also use encryption for the connection it is making to the database (SslMode=Required in the connection string).
When you are using WCF, it helps you to implement an additional layer of abstraction and protection. You can use your own membership to authenticate the user who can have access to the WCF services and not worry about connecting from the client to the database directly.
All being considered, going with a WCF or any other web service layer instead of directly connecting to the database from the client would be better approach.
We are departing from our typical native application development and are developing some new web-based application services. We are using .Net and WCF and most likely hosting on IIS.
Our services will need to use a database to persist data. In all cases we intend to make the database server a different box than our host. Most of the resources we find seem to indicate storing the database connection string in the web.config (or app.config file for self-hosting). Our concern is that since the service is web-facing the box it is running on is a more likely to be hacked/compromised. If that happens, the attacker now had the DB connection string and will have full access to all of the data.
An initial thought was to make the WCF service simply proxy to a server application that lives on another machine that holds the connection information and does all the processing logic. That way, if the the web-host is compromised they would have to figure out how to communicate with our server application, or compromise that machine as well, to gain database access. Though we do have concerns of the performance costs of proxying and possibly having a bottle-neck at the server application.
The concern with that approach is that we are not finding much in the way of WCF/IIS literature that recommending on such an approach, but we might just not know what it is called in order to find such information. The question: is proxying like that a good practice and why/(why not) (or where might I find more information on this topic), or is there a better practice?
As with these things, it all depends on how secure you need things. You can encrypt your web.config:
http://msdn.microsoft.com/en-us/library/dtkwfdky.aspx
But you have to ask that if your attacker has the ability to compromise your web host machine, they will be able to find your other server, and may also then have the ability to compromise that - not 100% sure what the net gain here is (apart from making your life more difficult).