Good afternoon,
I'm trying to find a way to synchronize an ObservableCollection between applications. Basically, one would be the server that has a collection of strings, and the other would be the client which would have that same list and display it in a GUI. When a string is modified on the server, I want the modification to be reflected on the client.
I'm not very familiar with server-client architectures or frameworks and would like to know where to start. So far I have looked at the WCF architecture and it looks like it might be a bit overkill for what I'm trying to accomplish, but I could be wrong.
Any guidance will be greatly appreciated.
WCF is the standard way of performing inter-process and inter-machine communications for .NET applications and it works very well. You need your client application to connect to the server and get the current state of the collection. Then each time the collection changes the client needs to be notified so it can apply the same change locally. There are many resource on the Web and at MSDN describing how to create a WCF connection.
Related
Please forgive the newbie question. I've spent the last three hours researching this, and I can't quite find the right answer, or perhaps I just don't believe it's as simple as it looks.
I need to deploy an application such that an application on the server-side does the heavy lifting, database wise, and the client-side version is fairly lightweight.
I have built a Data Access Layer class library (or at least a dll) that does all the heavy lifting. I have built a Windows Forms application that could serve as the lightweight client. They see each other. They talk to each other. They work happily together.
I'm kind of hoping all I need to do is put the dll on the server, point the reference to it in the client, and all will be well. The dll will run its code on the server, using server resources, and the client will run on the client. It's what the various websites seem to suggest, but it looks too simple.
Do I need to configure something like remoting on the server? Do I need to use System.Runtime.Remoting for something? Or is it really as simple as it looks?
Again, please forgive so basic a question.
what you are trying to do is build Client/Server application,
where you have
Client
client domainDomain
server Domain
Dal
Data
you will need to enstablish http conntection between client domain and server domain .
the common way to do this is using WCF
Explain the different tiers of 2 tier & 3 tier architecture?
http://www.codeproject.com/Tips/642296/Hello-World-Basic-Server-Client-Example-of-WCF
http://www.codeproject.com/Articles/14493/WCF-Basic-Client-Server
oh and welcome to stack overflow!
Well, you could use System.Runtime.Remoting, but that is a deprecated technology, i suggest using WCF for communicating between the client and the server.
Good afternoon,
I am looking to have a web service that deals other web services (and databases) to collect data that is then stored within its own database. This is all quite straight-forward as I can regularly poll these to gather changes.
now communicating with the clients is the problem here. The web service can be created in any language (although C# or Java are the main candidates). But they will need to push data to clients written in Silverlight and Android (and others to be decided).
Polling is of course possible but on mobile devices we don't want constant polling, and besides in as real time as possible comms is important here
If this was totally in C# then I would imagine I could use duplex channels but I need something that is more general in order to push. So the question is what is available to do this? Also it needs to be free in an ideal world.
Seems a simple thing, a way to push from a web service toa client but I suspect it is far from simple (but maybe I can be proved wrong, I hope!)
It seems that there is no platform independent way to do what I want and so the way forward has been decided as the following for now:
Silverlight clients will use a polling mechanism to get the data and Android clients will use XMPP to get the messages.
This does have disadvantages in the polling aspect however there are no readily available free libraries to do it that work with Silverlight but in the future we will move to using XMPP throughout when we have the cash
Say two clients machines recall a ticket. If one client makes a change, what is the best way to keep the second client in sync? Obviously I don't want the second client to overwrite the first one's changes, but additionally I want the second client to be updated because it may do an operation based on that ticket that needs to include the update the other machine made.
Some approaches I've considered:
MSMQ - our application actually used to use this but by the time I was hired it was just dead code that was no longer being used. I've thought about reinstating it but I don't feel that MSMQ quite offers the functionality I want in regard to not just notifying other clients of a change, but also distributing that change.
SQL Service Broker - it's been a while since I looked at this but I definitely remember it was not the route I wanted to go.
Web Service - Instead of having applications each access the database themselves, I think having a webservice to be in the middle to be responsible for forming the business objects and handing them out would be a partial fix, except for the fact that our application is purely windows forms. But surely there is another way to implement this without the need for an actual web server?
Sockets - I've thought about just creating a windows service that integrates with our business object and uses windows sockets to either a) Just tell other clients they need to call the database for updates or b) Actually give the clients the updates so they don't need to call the database.
This is new territory for me and I'm not aware of any good books or articles that address design patterns that deal with this issue so please direct me to any if you know of them.
With regards to your web-service option, be aware that WCF does not require a web-server. All it needs is a Host, and you can implement one yourself trivially. That host would probably be a Windows Service for your needs.
I m not sure but you can make use of
Observer
- Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.
and implement it
I've been asked to research approaches to deal with an app we're supposed to be building. This app, hypothetically a Windows form written in C#, will issue commands directly to the server if it's connected, but if the app is offline, the state must be maintained as if it was connected and then sync up and issue data changes/commands to the server once it is connected.
I'm not sure where to start looking. This is something akin to Google Gears, but I don't think I have that option if we go a Winform route (which looks likely, given that there are other functions the application needs that a web app couldn't perform). Is the Microsoft Sync framework a viable option? Does Silverlight do anything like this? Any other options? I've Googled around a bit but would like the community input on what's best given the scenario.
The Microsoft Sync Framework definitely supports the scenario you describe, although I would say that it's fairly complicated to get it working.
One thing to understand about the Sync Framework is that it's really two quite distinct frameworks shipping in the same package:
Sync Framework
ADO.NET Sync services v. 2
The ADO.NET Sync services are by far the easiest to set up, but they are constrained to synchronizing two relational data stores (although you can set up a web service as a remote facade between the two).
The core Sync Framework has no such limitations, but is far more complex to implement. When I used it about six months ago, I found that the best source to learn from was the SDK, and particularly the File/Folder sync sample code.
As far as I could tell, there was little to no sharing of code and types between the two 'frameworks', so you will have to pick one or the other.
In either case, there are no constraints on how you host the sync code, so Windows Forms is just one option among many.
If I understand correctly, this doesn't sound like an actual data synchronization issue to me where you want to keep two databases in sync. it sounds more like you want a reliable mechanism for a client to call functions on a server in an environment where the connection is unstable, and if the connection is not present at the time, you want the function called as soon as the connection is back up.
If my understanding is right, this is one option. if not, this will probably not be helpful.
This is a very short answer to an in-depth problem, but we had a similar situation and this is how we handled it.
We have a client application that needs to monitor some data on a PC in a store. When certain events happen, this client application needs to update our server in the corporate offices, preferably Real-Time. However, the connection is not 100% reliable, so we needed a similar mechanism.
We solved this by trying to write to the server via a web service. If there is an error calling the web service, the command is serialized as an XML file in a folder named "waiting to upload".
We have a routine running in our client app on a timer set for every n minutes. When the timer elapses, it checks for XML files in this folder. If found, it attempts to call the web service using the information saved in the file, and so on until it is successful. Upon a successful call, the XML file is deleted.
It sounds hack-ish, but it was simple to code and has worked flawlessly for five years now. It's actually been our most trouble-free application all-around and we've implemented the pattern elsewhere successfully
So my company stores alot of data in a foxpro database and trying to get around the performance hit of touching it directly I was thinking of messaging anything that can be done asynchronously for a snappier user experience. I started looking at ActiveMQ but don't know how well C# will hook with it. Wanting to hear what all of you guys think.
edit : It is going to be a web application. Anything touching this foxpro is kinda slow (probably because the person who set it up 10 years ago messed it all to hell, some of the table files are incredibly large). We replicate the foxpro to sql nightly and most of our data reads are ok being a day old so we are focusing on the writes. plus the write affects a critical part of the user experience (purchasing), we store it in sql and then just message to have it put into foxpro when it can. I wish we could just get rid of the foxpro, unfortunately the company doesn't want to get rid of a very old piece of software they bought that depends on it.
ActiveMQ works well with C# using the Spring.NET integrations and NMS. A post with some links to get you started in that direction is here. Also consider using MSMQ (The System.Messaging namespace) or a .NET based asynchronous messaging solution, with some options here.
MSMQ (Microsoft Message Queueing) may be a great choice. It is part of the OS and present as an optional component (can be installed via Add/Remove Programs / Windows Components), meaning it's free (as long you already paid for Windows, of course). MSMQ provides Win32/COM and System.Messaging APIs. More modern Windows Communication Foundation (aka Indigo) queued channels also use MSMQ.
Note that MSMQ is not supported on Home SKUs of Windows (XP Home and Vista Home)
Its worth mentioning that the ActiveMQ open source project defines a C# API for messaging called NMS which allows you to develop against a single C# / .Net API that can then use various messaging back ends such as
ActiveMQ
MSMQ
TibCo's EMS
any STOMP provider
any JMS provider via StompConnect
You may want to look at MSMQ. It can be used by .NET and VFP, but you'll need to rewrite to use them. Here's an article that tells you how to use MSMQ from VFP. https://learn.microsoft.com/en-us/previous-versions/visualstudio/foxpro/ms917361(v=msdn.10)
Sorry if this isn't what you are asking for...
Have you considered some sort of cache behind the scenes that acts a bit like the "bucket system" when using asynchronous sockets in c/c++ using winsock? Basicly, it works by accepting requests, and sends an immediate response back to the web app, and when it finally gets around to finding your record, it updates it on the app via AJAX or any other technology of your choice. Since I'm not a C# programmer I can't provide any specific example. Hope this helps!
Does the Fox app use .CDX indexes? If so, you might be able to improve performance by adding indexes without needing to change any program code. If it uses .IDX indexes, though, the change would have to be done in the actual app.
As the problem is with writes, I would look more towards >removing< any unneeded indexes on the tables. As is common in RDBMS, every index on a FoxPro table slows down a write operation as the indexes need to be updated, and as you aren't reading directly from (or presumably directly querying) the table you shouldn't need very many indexes. You might also want to look at any triggers or field rules on the tables as they may be slowing down the write operation. Be sure your referential integrity is still preserved, though..