I'm using a desktop application that writes its data to SQL server. I don't have the source code of this application nor is there an API I could interact with but I do have access to the database.
Besides this desktop application, I'm working with other web based applications that offer a REST API for interaction.
Now, my goal is to act on specific changes I make in the desktop software and push these changes automatically to the web service. For example, if I create a new customer in my application, I want to have the same customer created in the web service.
The easiest way of doing this IMO is to just introduce a trigger in the SQL database and consume the API of the web service directly from T-SQL.
Researching this topic, I came across many comments saying using SQL Server for this is not recommended, too expensive etc. I fully understand where they are coming from, even though in my own case cost or performance really won't matter that much.
Still, I'm wondering, what would be the correct (or at least better) way of doing what I'm trying to do without considerably blowing up complexity?
Related
I am currently studying how to make cross-platform mobile apps (with xamarin forms), and I have heard that the "correct" way to connect to a database in a non-locale server (in my case located in Azure) is by using Rest Services (or rest APIs, or however is called), instead of connecting directly to the database with the server explorer option of VS like you would do in windows forms for example(using the SQL connection, dataset, etc. Which I think they are not necessary in the first case, I am not sure).
The only answer that I have received about this is that in mobile apps "They are not permanent connections. It connects, gives you data and disconnects. They are Asynchronous connections.", and that this is done "For optimization of connection resources. The mobile is suspended or the user passes the App to the background.".
But I still don't know if this is the actual reason, and if it is I don't understand how it optimizes the connection resources. So if someone has time to explain this I would appreciate it.
Thank you for your time, I hope I have explained myself correctly, and that you all have a great day.
As Jason said,the Security issues，with proper authorization having mediator is definitely much more secure than giving a user direct access to the database, because you restrict him to the end points which run only the queries you want to.And from the platform independence and maintenance,if the apps are developed in different languages and on different platforms,it may have benefit to create a common REST interface to allow sharing of data model, caching etc.For performance and scalability，that HTTP layer of your REST API provides another valuable caching mechanism. Your servers for your REST API can put caching headers on their responses, and these responses can be cached at the network layer, which scales exceptionally well.
you could read this link Why do people do REST API's instead of DBAL's?,I think the answers are pretty good
I am using MonoDevelop and MonoTouch to create an application which needs to access SQL Server 2008 tables. I understand that if you use objective-C then the only way to access SQL Server is via web service but what about MonoTouch. Is there anything better than coding a web service when using MonoTouch?
Better? I would say no there isn't. Creating a Web Service is the way to go in this scenario. You keep your data access layer on the server, you keep your security footprint small, and you enforce data validation on the server-side. All of this keeps your MonoTouch application smaller and focused on the Presentation layer and Business Logic Layer.
From your question, I am assuming you would rather stay away from WCF but it really is the way to go. This way you set yourself up to work with MonoDroid, a website, Windows Phone 7, or other platforms without additional Data Access (and possibly Business Logic) layers needing to be written. Even if my research didn't suggest that there isn't a SQL Server connector for MonoTouch, I would still recommend going with WCF. From what I have seen though, it doesn't seem like you have a choice here.
I recently attended the Microsoft Mix event and sat through these OData presentations. It includes code samples for obtaining data via objective C or any other subscriber/device/language from an OData provider (including SQL Server). They are well worth the watch if you're interested in data access technologies.
http://channel9.msdn.com/Events/MIX/MIX11/FRM10
http://channel9.msdn.com/Events/MIX/MIX11/FRM11
http://channel9.msdn.com/Events/MIX/MIX11/FRM16
Please I need help.
I have project in which I need application which communicates with local DB server and simultaneously with central remote DB server to complete some task(read stock quotas from local server create order and then write order to central orders DB,...).
So, I don`t know which architecture and technology do this.
Web application, .NET WinForms client applications on each computer, or web services based central application with client applications?
What are general differences between this approaches?
Thanks
If you don't want to expose your database directly to the clients, I'd recommend having a web service layer in between. Depending on the sensitivity of your data and the security level of your network, I'd recommend either a web service approach (where you can manage the encryption of data yourself, and without need for expensive ssl certificates) or a web interface (which might be easier to construct, but with limitations in security).
I agree with Tomas that a web service layer might be good. However, when it comes to choosing between webforms or winforms I don't think your question includes enough information to make the choice.
I'd say that if you want a powerful and feature rich user interface and want to make development easy, Winforms is probably the way to go. But if you need it to be usuable from a varied array of clients and want easier maintenance and deployment, a web app might be best.
First, focus on the exact relationship between these databases. What does "local" mean. Right there on the user's desktop? Shared between all the users in their office? Presumably the local quotes (you do mean stock quotes and not quotas?) could potentiually be a little out of date relative to the central order server's view of the world. Does that matter? I place an order for 100 X at price 78.34, real price may be different. What is the intended behaviour.
My guess is that there is at least some business logic and so we need to decide where that runs. One (thick client) approach is to put that logic on the desktop, the desktop app then might write directly to the central DB. I don't tend to do this for several reasons:
Every client desktop gets a database connection. Scaling is not good, eventually the database gets unhappy when the number of users gets very large.
If we need a slightly different app, perhaps exposed to a different set of users via the Web or whatever, we end up reproducing that business logic.
An alternative approach (thin or browser based) keeps the UI on the desktop, but puts the logic on the server. The client can then invoke some kind of service. Now there's lots of possible ways of doing that, a simple Web Service or Rest Service will do the job. I hope it's clear that this service-based appraoch addressed my two points above.
By symmetry I would treat the local databases in the same way, wrap them in services. However it's possible that some more complex relationship between the databases exists and in which case you might need the local service layer to interact with the central service layer.
I'm touting the general pronciple of Do Not Repeat Yourself, implement each piece of business logic once.
Currently we got a web service up and running that handles all our C.R.U.D calls to our database, and pretty much every interaction between user and the database.
(starting with checking the database to see if there's an update for the particular version of the end users application, checking credentials, checking/reading various other application settings, etc, etc)
Pretty much everything our desktop application does (written in c# with WPF .net framework 3.5) it makes a call to the web service. Problem is that on slower machines this takes way too long. Some of users have to wait up to 3 minutes for the app to cold start (this is probably partly because of .net frameworks slow load time...but the web service calls don't help anything).
I guess since our applications are more or less a fancy front end to a database (SQL SERVER 2005), should we be using something else to communicate with it besides a web service? What else is there? I choose the web service because it's the only thing I knew how to do. (besides connecting directly to the database) What do other similar apps use?
Thank You
As mentioned by #Chris Marisic, first profile to ensure that the problem is in the web called. Assuming that it is, there are a few things you can try (I don't know WPF so you will have to see how they work with the framework).
Batch similar items.
For example instead of loading 1 row at a time from table (or equivalent), load several.
May web calls asynchronous.
If you have to send out a bunch of independent calls to the web service, send them asynchronously so that multiple requests are going across the network at once.
Cache values. This can add a lot of complexity if you are not careful (depending on how much you care if the cache is up to date). The ability to listen to the server for changes (or the ability to have the server push changes) makes this one easier to handle.
I had a similar problem on a different framework and I got quite a bit of speedup just with #1.
Profile Profile Profile. Don't make assumptions.
By "web service" do you mean "SOAP service"? Profiling will tell you whether or not SOAP is buying you something.
It's likely that latency and (n+1) query is killing you. It should be easy to measure.
There are some rumors floating around that the team at my company will soon be using web services for all future application development. The architecture is supposed to be something like this:
Application --> Web Service --> Database
The stated reasoning behind it is security. This sounds like a huge waste of time for little if any benefit. My question is, in what ways does a web service make your data more secure than a database? I would think that if an attacker wanted to get all your data and had already gotten onto the app server, it would be fairly trivial to figure out how the application is getting it's data.
Please keep in mind that these web services would be purely for data, and would have little if any business/validation logic, and would also be outside the application developers control (at least that's the way it's worked with all previous applications that have used web services).
If it's true that there will be no business logic or validation on the web services, then there is only a limited security benefit to adding the additional layer of abstraction. I say limited because the interface between your application and the database is still more limited than if they were directly talking to each other.
If you add validation and business logic to the equation, there is a significant security benefit, as anyone who has access to the application account can only do the database what the application is able to do. Additionally, this is a better design because it reduces coupling between your application and implementation details of how the data is stored in the database. If you wanted to change the database schema, you only need to update the web services, and not entire applications.
One important thing about Web Services is interoperability so that different applications from different platforms later can utilize the services and data. Your company will benefit a lot by doing so. And you are right about the security, it is definitely one of the good reasons to use web service rather than expose a public endpoint of the database, it is dangerous!
Web Services enable the accessibility of your data, For example, your data can be accessed within browser by javascript. There is no way to access the database on the server directly within Javascript.
All in all, go for it, that is the right approach.
the security argument is questionable; authenticating to a web service is no different than authenticating to the database
there are legitimate reasons for moving db operations to web services and SOA in general, but security isn't one of them
If you use a webservice hopefully you will also be using some kind of queue when sending the data to the database. If you are using a webservice and queue combo then the security come into place with less chance of lost data. If you do not have a webservice and queue combo if you send data to the database and it never gets there you have no were for it to go it just disappears.
You are correct though if someone wants to break into your system a webservice isnt going to help if anything it might make it worse if you make the webservice public and they find the name of your webservice because then they can just query your DB using the webservice and any security features on your servers will just think it is you applications getting the information.