We are starting to develop a new application and I'm searching for information/tips/guides on application architecture.
Application should:
read the data from an external (USB) device
send the data to the remote server (through internet)
receive the data from the remote server
perform a video call with to the calling (support) center
receive a video call call from the calling (support) center
support touch screens
In addition: some of the data should also be visible through the web page.
So I was thinking about:
On the server side:
use the database (probably MS SQL)
use ORM (nHibernate) to map the data from the DB to the domain objects
create a layer with business logic in C#
create a web (WCF) services (for client application)
create an asp.net mvc application (for item 7.) to enable data view through the browser
On the client side I would use WPF 4 application which will communicate with external device and the wcf services on the server.
So far so good. Now the problem begins. I have no idea how to create a video call (outgoing or incoming) part of the application.
I believe that there is no problem to communicate with microphone, speaker, camera with WPF/C#. But how to communicate with the call center? What protocol and encoding should be used?
I think that I will need to create some kind of server which will:
have a list of operators in the calling center and track which operator is occupied and which operator is free
have a list of connected end users
receive incoming calls from end users and delegate call to free operator
delegate calls from calling center to the end user
Any info, link, anything on where to start would be much appreciated.
Many thanks!
It sounds like you are in the support business, not in the making of video conferencing software business. Maybe look at licensing 3rd party SDK's to fill in the video conferencing component of the application. It should end up being a lot faster to get your application live than reinventing the wheel. I googled quickly for "Video conferencing SDK". Several popped up immediately. I haven't ever used any so I am not about to start recommending any but I would think that is a good place to start.
I suggest using an existing service (Skype, Google Chat, ...) and control if from your WPF application(s) for the operator and client.
Use a SIP solution with a video codec. Open standard one there are many SIP SDK's out there.
Related
I want to create an Instant Messaging app for Windows Phone.
I have found some information about Live SDK, but it looks like the messenger api is outdated?
Can anyone help me start? All I want to do at first is embed the IM.
A simple IM app where the user logs in with their Live ID, sees who already has the app (Live Contacts) and an IM-service with a UI like the SMS-service in windows phone.
Can anyone help me get started?
Firstly i hope i got your question right.
I have multiple lookouts for you:
XMPP (Jabber): start from there. It is fairly simple, and there are opensource clients out there where you can dismantle code and learn by understanding what others have done.
Check out the SignalR
ASP.NET SignalR is a new library for ASP.NET developers that makes it incredibly simple to add real-time web functionality to your applications. It's the ability to have your server-side code push content to the connected clients as it happens, in real-time.
You may have heard of WebSockets, a new HTML5 API that enables bi-directional communication between the browser and server. SignalR will use WebSockets under the covers when it's available, and gracefully fallback to other techniques and technologies when it isn't, while your application code stays the same.
SignalR also provides a very simple, high-level API for doing server to client RPC (call JavaScript functions in your clients' browsers from server-side .NET code) in your ASP.NET application, as well as adding useful hooks for connection management, e.g. connect/disconnect events, grouping connections, authorization.
Ok so i have a C# server and a windows phone app that acts as a client. The client will have to modify settings on the server, receive images from the server (possibly a video stream) and receive notifications from the server (the best way would be instantaneous, like when someone sends you a message on facebook and you get the notification right away).
I have the server and client set up so they are communicating, they are sending each other an object that is serialized with XmlSerializer (it currently only contains a public String field with public get/set methods). They connect over a socket. This works well if i want to send just simple messages between them, but i assume i'll run into problems when i want to have instant notifications and transfer of images / video streams. How would i go about continuing my work in a proper way?
Consider designing an API solution via web services using RESTful or SOAP services. Personally I suggest using RESTful web services. Here are some kick start links about REST:
http://www.codeproject.com/Articles/255684/Create-and-Consume-RESTFul-Service-in-NET-Framewor
http://www.codeproject.com/Articles/148762/NET-4-0-RESTful-Web-Service-Introduction
http://www.codeproject.com/Articles/21174/Everything-About-REST-Web-Services-What-and-How-Pa
http://msdn.microsoft.com/en-us/library/dd203052.aspx
This is another useful article in MSDN which compares WCF REST and WCF SOAP: http://msdn.microsoft.com/en-us/library/vstudio/hh273094(v=vs.100).aspx
I think if you are looking for two way communication between the client and server then using sockets is the way to go.
As for images you don't need to send the actual image. You can just pass a URL to it and then download it with one of the classes specialized for that.
For near instant notifications you could also take a look at push notifications.
Of course if you don't really need the server to push data to the client then it would be much simpler if you used a REST API as someone else suggested.
I know I can use Remote Desktop ActiveX control, but I am trying to implement solution browser based solution just like browserstack.com etc, they have implemented same by using Flash which connects to their server which in turn might be rdp gateway.
I have looked at library Cassia, https://code.google.com/p/cassia/source/browse/trunk/Samples/SessionInfo/Source/SessionInfo/Program.cs, but I am not able to understand how to actually grab the screen and send input after we call WTSStartRemoteControlSession method.
I want to call these methods from an ASP.NET MVC Web Application, which basically stores scripts for automated UI testing. Most of the time, no body will be keeping any UI open, our test server will automatically create RDP session, run everything and then email results.
Only for recording tests, programmers will use Web UI which will communicate with server purely through web sockets and download images of screen. Using ActiveX control is not possible as we use UI Automation to capture text/UI element information etc.
Yeah, Cassia and the WTS API won't help you much here, since they're more for administering servers than interacting with individual sessions.
You could try an HTML5 RDP client like Guacamole. It has a JavaScript client API that allows you to send key and mouse events.
As an alternative, very comparable to Guacamole, you can try Myrtille, also open source and using FreeRDP as rdp client through an HTTP gateway. The main difference is it's done in .NET (C#) and thus is more intended for Windows Servers.
I am creating a "tracking system" for my android phone. Basically, the phone would transmit it latitude/longitude to a C# program that will receive the coordinates and display it on a map. I managed to get the phone's latitude/longitude coordinates but I need a way to transmit that data to my C# application running in my PC. I know my way around C# and Java but never really got into network programming. Is there a way to do this ?
I'd look into C# Webservices, very powerful. The communication protocol is SOAP (Simple Object Access Protocol) which is a popular and well supported standard.
Good starting reference: Your first C# Web Service
I can't speak to the C# side of it, but if you write a C# server to receive post requests, the Apache HttpClient makes it relatively simple to send requests. There are a bunch of other questions on SO that will help with setting up the client side on your phone if you poke around a bit.
You have different way to do it.
The first is to send data over the cloud to interact through distant server. So the both devices have to be connected to Internet
The second id to send the data over a local network so the data have to be on the same network and have to share their IPs
The third is to use adb forward which allows to build a socket connection between the 2 devices over a USB cable. The requirements are that the phone have to be on debug mode I think and that the driver are installed on the PC so the phone is recognized by ADB.
I can add one more by using a Bluetooth connection. Find information here
The correct way to do it would be to build WCF service which allows many different protocols to receive data. This would could be a very powerful solution that can be extended in future.
The fastest and easiest IMO would be to create ASP.NET MVC application, define a POCO Model for your longitude/latitude and create an action that would take your Model as parameter. Then use HttpClient and HttpPost on android to send the data. The trick here is to name the variables in your post request same as ones you define in your C# Model.
I'm working with an n-Tier application using WinForm and WCF
Engine Service (Windows Service) => WCF Service => Windows Form Client Application
The problem is that the WinForm Client Application need to be 100% available for work even if Engine Service is down.
So how can I make a disconnected architecture in order to make my winform application always available ?
Thanks.
Typically you implement a queue that's internal to your application.
The queue will forward the requests to the web service. In the event the web service is down, it stays queued. The queue mechanism should check every so often to see if the web service is alive, and when it is then forward everything it has stored up.
Alternatively, you can go direct to the web service, then simply post it to the queue in the event of initial failure. However, the queue will still need to check on the web service every so often.
EDIT:
Just to clarify, yes all of the business logic would need to be available client side. Otherwise you would need to provide a "verify" mechanism when the client connects back up.
However, this isn't a bad thing. As you should be placing the business logic in it's own assembly(ies) anyway.
Have a look at Smart Client Factory: http://msdn.microsoft.com/en-us/library/aa480482.aspx
Just to highlight the goals (this is sniped from the above link):
They have a rich user interface that
takes advantage of the power of the
Microsoft Windows desktop.
They connect to multiple back-end
systems to exchange data with them.
They present information coming from
multiple and diverse sources through
an integrated user interface, so the
data looks like it came from one
back-end system.
They take advantage of local storage
and processing resources to enable
operation during periods of no
network connectivity or intermittent
network connectivity.
They are easily deployed and
configured.
Edit
I'm going ansewr this with the usual CYA statement of it really depends. Let me give you some examples. Take an application which will watch the filesystem for files to be generated in any number of different formats (DB2, Flatfile, xml). The application will then import the files, displaying to the user a unified view of the document. And allow him to place e-commerce orders.
In this app, you could choose to detect the files zip them up and upload to the server do the transforms (applying business logic like normalization of data etc). But then what happens if the internet connection is down. Now the user has to wait for his connection before he can place his e-Commerce order.
A better solution would be to run the business rules in the client transforming the files. Now let's say, you had some business logic which would based on the order determine additional rules such as a salesman to route it to or pricing discounts...These might make sense to sit on the server.
The question you will need to ask is what functionality do I need to make my application function when the server is not there. Anything thing which falls within this category will need to be client side.
I've also never used Click Once deployment we had to roll our own updater which is a tale for another thread, but you should be able to send down updates preety easily. You could also code your business logic in an assembly, that you load from a URL, so while it runs client side it can be updated easily.
You can do all your processing off line, and use some thing like Microsoft Sync Framework to sync the data between the client and the server.
Assuming both server and client are .net, you can use same code base to do the data validation both on the server and the client. This way you will have a single code base that will serve both server and client.
You can use frameworks like CSLA.NET to simplify this validation process.