What are cons and pros of web service vs direct client-sql server communication?
From my understanding:
Pros:
If web service is installed on same computer as remote db then there is no need to open sql server port so that client can access to remote db. If web service is on another computer then port needs to be open for web service to access remote db.
If someone manages to get a hold of user:pass he only can do operations on db that web service exposes, not all operations on entire db.
Cons:
More work for programmer
Slower
The main difference is that if you go with a Web Service/Rest Api you are centralizing the Business Layer where if there is a bug or a change you can control it very easily with no need of client upgrades.
I will only recommend you to go with direct db access only if you have a small number of clients, over a local network with too few updates to the business logic (aka simple app).
Related
I'm trying to create a WCF service for our existing product.
The service should provide normal "webservice" features (one-way), but also act independently.
Sample scenario:
The client connects to the server
The server saves the client in a collection
Now I use an admin client / database entry to tell the client to do sth. (For example change config for log4net/NHibernate)
I've read some things about callbacks (mostly a chat system), but I'm still not sure if this will work.
Now my question is, will WCF be suitable for such a scenario or should I use TCPClient/TCPListener?
Currently I'm working on a design for a Windows Service application to fetch reports from an Oracle database, aggregate them to a message and send it to an external WCF SOAP service.
I would be grateful for some design suggestions concerning Windows services.
Should Windows Services use e.g. dedicated WAS/self-hosted WCF service (net.pipe/net.tcp) that provides data to achieve better separation / reusability?
So I would add a WCF service (net.pipe) that provides data (e.g. a GetReport method).
The Windows Service application would call GetReport and call the remote SOAP service to forward the aggregated message. The remote service and its client code are likely to change. It might be adapted for different customer projects.
If I understand correctly, your windows service will periodically fetch some data from the database and upload that data to a remote web service.
This means that your windows service is a client in terms of WCF communication and you won't need to implement any WCF server code inside it.
All you'll have to do is to connect to the remove web service and upload the data, e.g. using a client proxy generated for this remove service.
I don't think that it is required to add another WCF service that provides the data instead of querying the database directly as long as you don't have the requirement that another application will use the same WCF service. Until then I wouldn't add the service for the following reasons:
Another WCF service increases the complexity of the deployment and makes it harder to install and configure.
The connection to the new WCF service is another point that can break.
If you handle lots of data, getting them from the database directly is much more efficient instead of transferring them over a service protocol. As I understand your question, you aggregate the data in the windows service not in the database. Therefore you'd have to move the aggregation code to the new service also.
As said before, this recommendation will change once you have another potential client to the new service. In order to prepare for that, you should of course choose a design in your windows service that separates concerns well and is a good starting point to move some components later.
I'm trying to make a login app.
I would like to know how the connectionString on app.config is made for an online connection and if I would need anything else to reach the database, being as I'm trying to go directly to the user table on that database and perform a check for the login (as I already made it happen with a local database)
Best Regards
Your online database, does that mean a database at a remote location?
I would advise against going directly to a remote database unless that database server is protected in a LAN environment with no outside public access. Public access would also be considered if users inside the LAN also have unregulated access to the remote server. In any thick click based application the typical architecture would be to go through a proxy source or set of WebServices to authorize and authenticate users. Direct access opens your SQL server up to remote attacks.
That being said the connection string to an SQL server (remotely) could be:
Standard User\Pass
Server=myRemoteServer;Database=myDataBase;User Id=myUsername;
Password=myPassword;
Now chances are there are firewalls between the remote database and your client APP protecting remote logins (as there should) and it is a good possiblity that SQL server has disabled remote logins. Read here for more http://blogs.msdn.com/b/walzenbach/archive/2010/04/14/how-to-enable-remote-connections-in-sql-server-2008.aspx
I must point out again that this is a very bad idea and I would personally create a set of WCF WebServices to run on the server with the database. The WCF services would be responsible for connecting to the database to verify the credentials and return a structured datamodel.
WPF Applications are designed to work really well with the Async methods of WCF services and are very simple to setup. Using this model you can also setup more advanced layers of authentication using hashed token sets, implement SSL to block sniffing out the plain text, and keep your database protected from external access.
There are alot of examples on the web to connect to WCF services from a WPF application.
Please actually read my post before placing it on hold!!
Let me start by saying I've been searching for a solution all afternoon and so far I have seen plenty of examples for WCF but none that would do what I need.
I have developed an application in c# that will be installed on customer servers and accesses a sql server on the customer's local network. The application also has the ability to control network relays on the customer's local network and records the status of these in sql. I am trying to figure out a way to have the customer's server establish a connection to our datacenter and be able to issue commands back to the customer's server (retrieve datasets from sql, control the network relays, etc). I have found plenty of ways to have a client call classes on a server but have so far been unsuccessful in finding the reverse. One consideration was writing a web service as part of the application on the customer's server but need a way to establish this connection for customers with dynamic IP addresses and without having to publish through firewalls, etc.
Have you considered using
VPN - Virtual private network
or
Configuring a Port Forwarding redirect on the ADSL modem, and using a solution like www.noip.com ?
If I understand correctly you want to get information from the customer's database, which is behind a firewall and has no known static ip, in addition there might be several hundred customers so a dedicated VPN to the customer is not viable.
First of all: you should not contact the customer database directly. Databases are not designed for this scenario and would probably be left open to attack if exposed directly to the internet.
So you need a service on top of the database. There are two main options you can use for this service:
Polling service
The service is actually a client calling some web service on your network and asking for instructions.
Benefits: easy to implement and deploy.
Downsides: With polling there is always the cost-benefit of scalability/bandwidth use vs. speed of service. There are also some considerations in selecting the time to poll to prevent all the client polling at the same time.
The service is a tcp-server
This can be a usual web service (or RESTfull service) or some other service. The only difference is that it needs to advertise itself. For that you need to have a known directory server. When the service starts it then connects to the directory service and tells it the port it can be contacted on (the directory knows the ip from the connection). It will then need to periodically contact the directory to let it know it is still alive and so any change in IP is detected.
A client on your network would now query the directory to find the address of the client and connect directly to it to issue commands.
Benefit: Scalable and bandwidth efficient.
Downside: More difficult to implement. Requires firewall traversal solutions (UPNP or firewall exceptions).
I am creating a client application that downloads and displays market data from Yahoo! for a university project, but that also sends out notifications to mobiles (so far using Google cloud messaging). So far it's a WPF client and the "server" is a class library - so far working. What I was wondering, is can you mix this server with a WCF service - the WCF service I was planning on using for registering devices, as well as accepting and parsing commands.
So I would call .Start() on my server object, and it will be constantly running in the background, while a WCF REST service runs alongside it - or would I be better simply having a thread running on the server that can accept input... sorry if this is confusing, but just wondering if it can, or has been done before or any advice. :)
Just to explain a bit better
The client front end and the "server" are running on the same machine - I was calling it a server because it is not only updating the front end, but sending out GCM notifications at the same time. I was wondering if maybe a WCF service could be added to make it simpler to handle adding devices to a database ("server" reads a list of device reg ids from a database, sends notifications to these) by allowing an android app to details via REST or something similiar
I would explore wrapping the class library in a Windows Service (which is essentially a process that runs continuously, and can be stopped/started/paused) and keep your WCF service as a web service for client communication.
How the WCF client service communicates with the Windows service is up to you - whether you store the data in a shared database, keep it in memory and have another WCF layer communicating between the two, etc. A shared database would be the most straightforward, especially if you want to persist the data for use by other apps/services as well.
WCF Service would be useful if you had one notification service on your server with multiple WPF client application connecting to it. If you have just one application running on the same server then not sure if it will be worth the overhead.
The usual pattern is to host WCF service in IIS, that way it always starts whenever first request is received. WCF is very flexible though, therefore you can host in in Windows Service, Console Application, etc.