I've an enterprise database store used by some rich applications and a website with it own database store.
Enterprise application work with local data and some of these data (like orders,prices ...) have to be "synchronized" to the web site datastore.
On the other side, internet customers are able to edit their profile which have to be "synchronized" to the enterprise datastore too.
Basically i need this architecture :
WebSite => WebSite Database <=> || Internet || <=> Enterprise Database <= Rich Applications
Merge Replication
Service Broker
Synch Framework
Pick your poisson. Merge replication is probably the easiest to deploy. Service Broker is the most performant, but requires a steep learning curve. Synch Framework is not really appropiate, unless you plan to deploy datasets on the client too (mobile devices).
You can do a pull or push from the WebSite Database (WSDB) to the Enterprise Database (EDB) and vice-versa. It depends on what type of latency you are comfortable with. If you want near real-time syncing, go with a push. Otherwise the EBD can pull from the WSDB every hour or so through web service methods or REST calls (and vice-versa).
Push Example:
Customer updates profile and pushes "Submit" button.
WebSite calls web service method PushCustomerInfo(params) on EDB.
Pull Exmaple:
Every hour EBD calls web service method GetCustomerInfo that returns a Customer object on WSDB.
Related
We have an online food ordering management system with 1000 registered restaurants in this application. Every restaurant has its own product, category.
I want to create another desktop WPF application named Epos (Electronic point of sale). This application has both an online and offline mode. I am concerned about the data sync between 1000 the customer epos and the central, online food ordering system. If an order is placed from a desktop PC it should sync to website. If any customer order is placed using the website it should sync to their desktop app.
Website: Asp.net mvc and SQL Server database
Desktop Epos: WPF app plus SQL Server Express
We saw some solutions on the internet :
Microsoft Sync Framework
What is the best approach to solve this problem?
Sorry for my bad English
Too broad but most likely you don't even need db on client
I would just load the objects in a List and use LINQ
Unless you have some really massive List
I would just synch down by demand on the client
And have it synch everytime it uploads an order
You can also have a watch on the db to get notified but not sure how that would work with a service
If the Internet went down you would still have what is in memory so you cannot shut the app down. But I am amazed you have restaurants with unreliable Internet. Do they have reliable power?
There are too many options to chose from in Microsoft Azure when planning application design. Azure itself not stands still, looks like many options added recently. I'm a pretty nooby solo developer so I need some entry points to choose architecture.
The application consists of next parts:
1. Database
Classic SQL database is already implemented with Azure SQL database.
2. Server-side application. (architecture refactor needed)
For now application is a .NET C#/WPF desktop application hosted on classic Azure Virtual Machine with Windows Server onboard.
This is an always-running scheduler that performs kind of tasks one by one.
Tasks are mainly long-running works getting some data from Web, CPU-bound proccessing with recieved data, working with the DB.
It feels like its kind of ancient and wrong design (having in mind amount of azure features):
a) The application really don't need a GUI, just ability to control scheduler's status required.
b) Logically some kind of tasks can be performed simultaneously, and some of them must wait others to finish before start. Now all of tasks performed one by one, that caused by virtual machine performance limit. I think there must be a way to achieve parallel working and control results on higher level of abstaction than inside desktop app. I wanna somehow move scheduling logic to level up. (Maybe IaaS->Paas goes here?)
3. Client applications.
Client applications. Registered users work with the DB.
Here questions:
Which server-side application design should be chosen in this case, what Azure features required?
Is there an Azure built-it abilities to manage registered users accounts, or only way is to implement it as a part of application?
Did you explore other storage options or SQL database is what you need?
lets start from scratch:
STORAGE:you can choose from
1. Storage - Blob, Table, Queue, and File storage and disks for VM
2. SQL database - relational database service in the cloud based on the market leading Microsoft SQL Server engine, with mission-critical capabilities
3. Document DB - schema-free NoSQL document database service designed for modern mobile and web applications
4. StorSimple- integrated storage solution that manages storage tasks between on-premises devices and Microsoft Azure cloud storage
5. SQL data Warehouse- enterprise-class distributed database capable of processing petabyte volumes of relational and non-relational data
6. Redis Cache- High throughput, consistent low-latency data access to build fast, scalable applications
7. Azure Search- Search-as-a-service for web and mobile app development
SCHEDULAR: You can pick from
1. Virtual Machine
2. Cloud Service (worker role): you have more control over the VMs. You can install your own software on Cloud Service VMs and you can remote into them.
3. Batch: Cloud-scale job scheduling and compute management
4. Service Fabric: distributed systems platform used to build scalable, reliable, and easily-managed applications for the cloud
5. App Service: Scalable Web Apps, Mobile Apps, API Apps, and Logic Apps for any device
CLIENT: you can try out
1. Web Apps
2. Cloud Service (web role)
Use this link as one stop shop for all Azure services beautifully categorized based on functionality. From here you can pick and choose various services and amp it to your app's requirement.
MASTER LIST: http://azure.microsoft.com/en-in/documentation/
Existing Application:
I have an existing distributed Windows Forms application which is developed using VS 2013 & SQL Server 2008. Application is communicating through web api's from various remote locations to the central database.
Requirement/Feature:
1. I have to add new feature that application may be run in offline mode if there is no internet connectivity. When application is connected to the internet it should SYNCH all the data automatically to the server. Also if there are any changes to the database server in central database it should be SYNCH to remote locations as well.
The synch mechanism must use the webapis to synch the data and database structure.
My Proposal:
I'm planning to use Microsoft SYNCH framework to add SYNCH feature but it can not be done through webapi's (It has to be done through API's as per client requirement).
Also we need complete audit/reporting of the SYNCH process and hence this can not be done without customizing the program for adding SYNCH feature and we can not use Micorsoft SYNCH framework.
My Question/Queries
Can anyone suggest the best approach to do this so that both data and architecture can be SYNCH?
Would be great if anyone has used the generic approach which may be used for all database tables?
Thank you very much in advance!!
I'd like to know my options for the following scenario:
I have a C# winforms application (developed in VS 2010) distributed to a number of offices within the country. The application communicates with a C# web service which lies on a main server at a separate location and there is one database (SQL Server 2012) at a further location. (All servers run Windows Server 2008)
Head Office (where we are) utilize the same front-end to manage certain information on the database which needs to be readily available to all offices - real-time. At the same time, any data they change needs to be readily available to us at Head Office as we have a real-time dashboard web application that monitors site-wide statistics.
Currently, the users are complaining about the speed at which the application operates. They say it is really slow. We work in a business-critical environment where every minute waiting may mean losing a client.
I have researched the following options, but do not come from a DB background, so not too sure what the best route for my scenario is.
Terminal Services/Sessions (which I've just implemented at Head Office and they say it's a great improvement, although there's a terrible lag - like remoting onto someones desktop, which is not nice to work on.)
Transactional Replication (Sounds like something quite plausible for my scenario, but would require all offices to have their own SQL server database on their individual servers and they have a tendency to "fiddle" and break everything they're left in charge of!) Wish we could take over all their servers, but they are franchises so have their own IT people on site.)
I've currently got a whole lot of the look-up data being cached on start-up of the application but this too takes 2-3 minutes to complete which is just not acceptable!
Does anyone have any ideas?
With everything running through the web service, there is no need for additional SQL Servers to be deployed local to the client. The WS wouldn't be able to communicate with these databases, unless the WS was also deployed locally as well.
Before suggesting any specific improvements, you need to benchmark where your bottlenecks are occurring. What is the latency between the various clients and the web service, and then from the web service and the database? Does the database show any waiting? Once you know the worst case scenario, improve that, and then work your way down.
Some general thoughts, though:
Move the WS closer to the database
Cache the data at the web service level to save on DB calls
Find the expense WS calls, and try to optimize the throughput
If the lookup data doesn't change all that often, use a local copy of SQL CE to cache that data, and use the MS Sync Framework to keep the data synchronized to the SQL Server
Use SQL CE for everything on the client computer, and use a background process to sync between the client and WS
UPDATE
After your comment, two additional thoughts. If your web service payload(s) is/are large, you can try adding compression on the web service (if it hasn't already been implemented).
You can also update your client to do the WS calls asynchronously, either in a thread or if you are using .NET 4.5 using async/await. This would at least allow the client to use the UI, but wouldn't necessary fix any issues with data load times.
I am writing a plugin for an application in C#. The plugin allows me full access to the internal information model for the application.
I would like to create a mechanism to allow external applications to be able to connect to the information so they can report on it etc.
In days of old this used to be achieved via ODBC links - is that still the way to go.
I assume it's a significant task to create an ODBC driver for this, are there any easier recommendations or example C# code for cresting a driver.
Looking back I was not very clear in the original question. The requirement is to allow two applications on the same PC to share data. The "host" application use a proprietary storage format and as such access to the data cannot be achieved without using the "Host" application. The "host" applications allows the development of plugins (using C#) and the plugins have access to all of the data within the application. On that basis I was exploring whether a plugin could therefore expose an interface to an other external application and as such could act as a "Data Access Layer"
My reference to ODBC is probably a "red herring" - just shows how out of touch I am in this area.
Probably you are looking for something like Remoting and\or Web Services and\or the more modern WCF (windows communication foundation).
You can write your own services and access to that services from every language you want.
C# support for WCF and Remoting and WebServices is very good and allow you to write your server-client infrastructure in a very clean, object oriented and easy way.
Use HTTP: each services is handled in a serialized object sent in XML through an HTTP server, for example, IIS.
Clients can be written in every kind of language you want, from PHP to C# to C++ to JAVA to wathever, they need only to connect through HTTP and parse\deserialize\serialize XML.
You can choose your architecture. If both clients and servers are written in C# all is transparent to you, serialization and deserialization of XML, remote procedure call and IIS integration are all ready for you to use. You need only to write your applications.
You can export services instead of tables like a relational DBMS does, in this way you can divide the logic of your system from the data layer and the presentation layer.
In this way you can obtain scalability, multiplatform and multisystem support.
Some links to read:
http://en.wikipedia.org/wiki/Windows_Communication_Foundation
http://www.codeproject.com/KB/webservices/myservice.aspx
http://msdn.microsoft.com/en-us/library/aa730857(v=vs.80).aspx
http://msdn.microsoft.com/en-us/library/kwdt6w2k(v=vs.71).aspx
http://blogs.microsoft.co.il/blogs/bursteg/archive/2008/02/10/how-to-build-an-n-tier-application-with-wcf-and-datasets-in-visual-studio-2008.aspx
http://msmvps.com/blogs/williamryan/archive/2008/05/16/doing-tiers-with-wcf.aspx
Instead, if you are in an intranet, for example, or a single computer and you want just to share a DB service, you can just use SQLServer or MySql or PostgreSql and connect to it via TCP/IP.
Is not safe\secure however to expose a DB service on internet or in an intranet where security can be a problem.
Note also that SQLServer Express is free and may be suitable for you if you don't have much users\connections or a DB not greater than 4gb.
MySql and PostgreSql are free and open source.