I am encharged to build a web/desktop/mobile app for reservations, so obviously everything should be synchronized whenever a reservation is made either by the desktop, the mobile or the web app, I am thinking on using WPF and SILVERLIGHT for the dev, my question is I'm just seeking for advices before I start this up, are there protocols or ways to do the synchronization in WPF? Or would it be better using another language?
Excuse me if my question sounds dumb, the thing is I have never done something with synchronization and I'm seeking for guidenss.
Thanks in advance.
are there protocols or ways to do the synchronization in WPF?
You can use a Client-Server architecture to handle syncronization between all your clients.
The way this can work is you'll have a central server that handles the back-end logic of your buisness (Manages reservations in your example) and the clients act as the front-end applications that show the user data received from the server, let's him manipluate it through a UI, and send it back to the server for further proccessing such as saving the data in the database.
If you choose DotNet platforms as your development enviornment, You can use Windows Communication Foundation as your communication framework between your clients and your server.
would it be better using another language?
Your syncronization shouldn't rely on the UI framework you choose to develop your apps on, wether it's WPF, Silverlight or any other framework. It should be a seperate layer (like WCF) that keeps the coupling between your UI and DAL loose.
Hope this helps
Consider Sync Framework. Its like... in the name.
Okay, just got home, so can expand this answer.
Microsoft has an example where by it uses Sync Framework, SQL Server and SQL Server Express on the client, syncing using WCF to transfer ADO.Net DataTables and DataSets.
The important thing to realise about why you WANT to use Sync Framework is that it will handle all of the delta/diff/federation stuff for you. It is possible to have Sync Framework to two way sync your data, whilst only sending the delta across the wire.
Remember, don't reinvent the wheel.
Related
I'm not sure if the title I used is good, but hopefully my question will be better.
I have an java application that tracks data on PennyAuction sites(such as beezid.com), and will eventually upload all of the data to a database. Clients will download a java application and run it on their local machine, but this local machine application will have to be able to access the database and obtain all of the data.
All I have ever done is java applications programming, so this is all very new to me. Can anybody help me with a solution that will be able to accomplish this?
This is all I can think of:
Server that will run Backend application 24/7, and use JDBC to upload data to database.
Separate server for database alone.
I have no idea how the client application should connect to the database though.
Any help/links to tutorials on stuff like this would be appreciated.
You could actually let your clients connect to the database directly if the database is on a public IP.
An architecurally much better way of doing this is with webservices. This would make your system much more safe, robust and scalable.
Web services are client and server applications that communicate over the World Wide Web’s (WWW) HyperText Transfer Protocol (HTTP). As described by the World Wide Web Consortium (W3C), web services provide a standard means of interoperating between software applications running on a variety of platforms and frameworks. Web services are characterized by their great interoperability and extensibility, as well as their machine-processable descriptions, thanks to the use of XML. Web services can be combined in a loosely coupled way to achieve complex operations. Programs providing simple services can interact with each other to deliver sophisticated added-value services.
Im looking into developing a new version of a client/server application for a client. The current solution is a website in asp.net mvc.
The purpose of the application is to build a digital signage solution, this means that on the client the user will be creating playlists, from viedos and images and scheduling them to be shown on a screen. The items to be displayed are WPF user controls, one with logic for image and one for logic about video.
The current application is web based and accesses the central database directly. When all the clients (the ones that present the information) request data it is done through a webservice. The customer is very happy to use the web based client, although they request more "rich" behavior. This includes a principal requirement og having a preview of both a single "slide" and of a collection of slides.
I started developing this as a WPF application (discarding silverlight because of the preview of a wpf user control). Now im faced with the problem/challenge of defining how to access the database. The customers probably want the same usage pattern as they have now, where they move around with their labtops and thus not being on the same network as the database all the time.
My question is this: How do I design the database connectivity layer, should i go for pure web service based so everybody always use this, or should i make some kind of disconnected mode, where they can work at home, then connect and synchronize their data? Should i require them to be on the same network as the databse, so i can connect directly using a database layer and a connectionstring?
Will a webservice based approach be fast enough for working with images, videos (thinking about only loading thumbnails of these, else data would kill the performance ~several Gb og data). Im planning on using thumbnails on the clients and when on the home network they connect and get all the big videos and images...
When designing your app it's worthwhile to remember the KISS and YAGNI principles, and to be wary of overkill solutions and premature optimizations.
If I understand correctly, you have a working web-app, in which the only further feature which is required is a slideshow of sorts.
you can find lots of jQuery (or any other web-client framework) solutions for that.
If, nevertheless, you decide to develop a new client- you already have a webservice which is working well! I would suggest using it.
About the idea of storing the data on the client side- that's a classic candidate for YAGNI; Test your application's performance, and then see if you need anything more sophisticated like caching on the client side etc.
A side note- having the client application access the DB directly is not a recommended approach; it effectively cancels the 'server' part of 'client-server', and causes a high coupling between your presentation and business logic / data access.
It would be better to have a WCF application on the server which is responsible for fetching the requested files.
Starting from scratch in terms of knowledge I have written a desktop application using WPF and NHibernate. This has helped me get up to speed with both NHibernate and WPF.
However, there is a requirement to make the application so that it can be accessed from mutliple places - these include handheld devices which have very simple web browser (no javascript capability), web services, Internet, the desktop application and potentially other user interfaces.
I believe this requires moving the application from its current NHibernate.dll deployed on the client to a web based application. The sheer choice of technology stacks is overwhelming and I am hoping I can get pointed in the right direction.
In essence, I want to be able to access the data from the server side in the desktop client, from the web service, from the handheld devices.
On the server side I guess I would have a web server(IIS?), NHibernate and a database and some way of communicating between the clients and the server.
What would be the best choice in this circumstance? Is it REST? SOAP? WCF? Something I don't know about / haven't mentioned?
Any assistance and advice from people who have implemented similar things would be very much appreciated.
Well since you have already made most of the work on the desktop, moving the actual data access part on a webservice is not going to be hard.
If i were you i would make that transition and make a SOAP/WCF service have the same signatures (or at least as close as possible) as the data layer. This will make the transition for your already written desktop application easier. You will have to add code for synchronizing or just safety code for when the service is inaccesible.
For mobile access via a thin web client as the browser is, you are looking at a web site/application that touches the DB (possibly via the same data-access webservice) and generates html...
I can't advise between rest/soap/wcf as i have minor prior experience with all, but i can tell you that i have created a similar setup with a SOAP WebService feeding a Web Application and .NET Compact Framework Application for WM6+ and it works well.
VS2010: What is the best way to access a remote database over the internet from a WinForms application? By that I don't mean talking to the database (SQL Server) directly, but rather through a service. Best if I could use http as a protocol to avoid firewall issues.
Would recommend that you look at WCF
If you have control over both ends of the connection, you then can change protocol etc through configuration, but yes, http:80 is usually the easiest way to adhere to firewall policies.
If you wish to keep this simple and your needs are limited you could always use a typed dataset that you pass over WCF (or .Net Remoting). However you will quickly hit problems if your app gets more complex or you have lots of data.
SqlServer will exposed stored procs over soap, this may work well if your applications uses a few stored procs that are not too chatty.
Exposing your data with WCF Data Services is an option if you want simple CRAD operations.
Otherwise you will have to define all the methods you need on WCF interfaces.
If you are not tied to WinForm, look at WCF RIA Services with Silverlight as this will do a lot of the hard work for you with most CRAD type applications. But you will need to learn Silverlight.
The problem is there is no simple and
easy solution to “presenting the
internet is not in the way” and moving
to a 3 tier application will always
make your code more complex. A 3 tier
architecture can be great for more
complex and demanding applications,
but is often over kill.
Also consider writing a 2 tier WinForms application and using Terminal Services to expose it to your clients over the internet. This is often the cheapest solution and tends to give the least pain with system admin. However a lot of programmers think it is “cheating” for some reason.
We have a relatively large application that is strongly tied into Firebird (stored procedures, views etc). We are now getting a lot of requests to support additional databases and we would also like to move a lot of the functionality from the client to the server.
Now seems like a good time to move to a 3(4) tier architecture. We have already looked at DataSnap 2009 and RemObjects SDK/DataAbstract. Both seem like they would do the job, but are there any advantages/disadvantages we should look out for? Are there any other frameworks that you could recommend?
Cheers,
Paul
I can recommend using the KBM Middleware components from Components4Developers. There is a bit of a learning curve but they are very flexible and hold up well under use in real world conditions.
Comment from a user (http://www.components4programmers.com/usercomments/commentfromapowerusertoaquestion.htm)
Changing your application to Multi-Tiers with new framework (RM,DS,kbmMW, or what ever), will make a lot of changes in our application architecture, I recommended to go with this in future, but you can achieve the support for multi database, with other products like
UniDac from DevArt( Best components for database with direct connection).
AnyDac(from same Company who offer RemObjects.
SqlDirect(Has support for 9 MajorDB and also ODBC).
ZeosDB(Open source).
using one of the components above, will give you support for most major databases, beside it will not make you doig a lot of changes, and in some cases you just replace old database components with the new ones, and maybe change some of properties.
However, changing to Multi-tiers will not only make you only support more databases, but it will separate your business logic from presentation layer, therefore you can have more presentation layers for your application like web interface, or smart devices.
But the most important in the Multi-Tiers architecture, you will have a scalable system the grow more than what the database you are using can handle of connection, beside other benefits, like using other languages to write client applications.
In the process of moving to a multitier application you could consider using a transport protocol between the layers, which is language/technology independent (like webservices, (i think tha remobjects supports that)).
This could make a reimplementation of a layer simpler later (like if you later have to make a another version of the client-application in a browser/java/silverlight).
You can also investigate Midware http://www.overbyte.be/frame_index.html
For multi-tier architecture I also recommend to check out message-oriented middleware.
With message-oriented middleware, cross-language and cross-platform application integration can be implemented using the peer-to-peer or the publish/subscribe communication model. Messaging systems are loosely coupled, asynchronous and reliable. For example, they are core components in Java(tm) application servers such as JBoss.
For Firebird, I recently wrote a blog article on replacing Firebird database events, their limitations and ways to replace them with message-broker based solutions (which are available as open source):
Firebird Database Events and Message-oriented Middleware (part 1)
Firebird Database Events and Message-oriented Middleware
(part 2)
(disclaimer: I am a developer of Delphi and Free Pascal client libraries for open source message brokers).