We need to make client - web server application with minimum code rewriting on server side:
Clients
Web browsers;
Desktop application (win, mac);
Iphone (web and native);
Android (web and native);
(maybe some other mobile platform);
Web server
.Net with IIS 7.x
Application has to run on different devices, and communicate with server over secure connection. We would first develop web application, then desktop, and later mobile version.
We don't want to rewrite server side code. Client side code rewriting is unavoidable anyway...
We were thinking to make following data exchange architecture:
For browsers we would use: HTTPS, HTML, JSON, XML, AJAX...
For desktops and native mobile apps: HTTPS, JSON, XML (no need to for HTML tags)...
Well, you should use something like the Model View Controller architecture, which would allow you to achieve your goal of code reuse. Your rich client application would simply use the JSON/XML based API you create. This is a pretty common method of achieving the goal and I think it is pretty sound.
Related
I am query for a long time now.Where exactly we need to use WEB API and where should we use WCF restful services. What ever we want to achieve in WEB API we are able to achieve in WCF Rest. I tried to dig into answers but i got we need to do extra setting in wcf like URI templates,Contracts,endpoints. But its more on settings , but I wanted to known the real reason behind using WCF Restful Services.
Web Service
It is based on SOAP and returns data in XML format.
It supports only the HTTP protocol.
It is not open source but can be consumed by any client that understands XML.
It can be hosted only on IIS.
WCF
It is also based on SOAP and returns data in XML format.
It is the evolution of web services (ASMX) and support various protocols like TCP, HTTP, HTTPS, Named Pipes, MSMQ.
The main issue with WCF is its tedious and extensive configuration.
It is not open source but can be consumed by any client that understands XML.
It can be hosted with in the application or on IIS or using window service.
WCF REST
To use WCF as a WCF REST service you have to enable webHttpBindings.
It supports HTTP GET and POST verbs by [WebGet] and [WebInvoke] attributes respectively.
To enable other HTTP verbs you have to do some configuration in IIS to accept request of that particular verb on .svc files.
Passing data through parameters using a WebGet needs configuration. The UriTemplate must be specified.
It supports XML, JSON and ATOM data format.
Web API
This is the new framework for building HTTP services the easy and simple way.
Web API is open source an ideal platform for building RESTful services using the .NET Framework.
Unlike a WCF REST service, it use the full features of HTTP (like URIs, request/response headers, caching, versioning, various content formats).
It also supports the MVC features such as routing, controllers, action results, filter, model binders, IOC container or dependency injection, unit testing that makes it more simple and robust.
It can be hosted within the application or on IIS.
It is a light weight architecture and good for devices which have limited bandwidth like smart phones.
Responses are formatted by Web API’s MediaTypeFormatter into JSON, XML or whatever format you want to add as a MediaTypeFormatter.
Choosing between WCF or Web API
Choose WCF when you want to create a service that should support special scenarios such as one way messaging, message queues, duplex communication etc.
Choose WCF when you want to create a service that can use fast transport channels when available, such as TCP, Named Pipes, or maybe even UDP (in WCF 4.5), and you also want to support HTTP when all other transport channels are unavailable.
Choose Web API when you want to create a resource-oriented services over HTTP that can use the full features of HTTP (like URIs, request/response headers, caching, versioning, various content formats).
Choose Web API when you want to expose your service to a broad range of clients including browsers, mobiles, iPhone and tablets.
For more details you can refer to http://www.c-sharpcorner.com/UploadFile/8a67c0/who-is-winner-web-api-or-wcf/.
I want to develop a web application in which client calls a service on server to do some action which involves some processing. Server will do all the necessary processing and when the updated data is ready it will push that data to client. Currently I am considering two approaches: -
1. Using ASP.NET WEB API with SignalR
2. Using WebSockets with WCF in .NET 4.5.
My server will be on Windows Server 2012 but majority of my client will be IE 9 which I think do not support WebSockets.
As written in the SignalR documentation that it automatically falls to Long Polling if WebSockets support is not present without changing the application code. Whether this is also supported by WebSockets in .NET 4.5 or I have to do it manually. Means whether I have to implement both the Pull method and push method on the server.
Please guide me, which approach I will have follow.
In later use case I want to build this web application using PhoneGAP to create mobile app for iOS, Android & Windows Phone.
WebSockets does not fall back to longpolling (that doesn't really make sense). SignalR is a higher level abstraction over http transports and that's why it does the fallback and other things (like provide a nice programming model over a connection).
If you choose to use websockets on ASP.NET (not sure about WCF) you'll be programming against raw sockets (this means reading/writing array segments etc) and doing a good job at that is hard. SignalR does this for you and will fallback to several other transports (forever frame, server sent events, longpolling) if websockets isn't available on client or server.
Regarding clients, if you choose to use SignalR you'll need to use a SignalR client. We only have support for javascript and .NET (silverlight, windows phone 8, winrt, .NET 4 and .NET 4.5). Some people have written clients for other platforms including iOS and Android but we don't maintain them so I can't speak to how up to date they are.
I'd recommend you use SignalR so you can focus on your application logic instead of messing with the low level programming model of websockets.
You could start with the ASP.NET Tutorial http://www.asp.net/signalr/overview/getting-started/tutorial-getting-started-with-signalr
After this tutorials you know all the basic thing you need to know about SignalR
I can confirm that the fallback works automatically. If websockets transport can't be used, ServersentEvents transport would be used.. and so on.. the last transport protocol is longpolling.
Our SignalR server is a .NET 4.5 framework app, hosted in an ASP.NET MVC App using 4.5 dlls on a windows 2012 server. The application pool is ASP.NET 4.0.
A .NET 4.5 client on a Windows 8 or a windows 2012 server seems to use websockets.
The same .NET client on a Windows 7 machine (even with framework 4.5 installed) falls back to serversent events transport automatically.
With Signalr javascript clients on a browser, a similar thing happens:
Chrome/Safari/other browsers that support websockets seem to use websockets.
IE/other browsers that don't support websockets, but are relatively late versions seem to use serversentevents.
From experience, serversentevents is not very bad, therefore don't be put off if websockets isn't being used and certainly don't use that as the sole factor against using signalR as the benefits are many.
Hope this helps.
I'm developing a relatively simple PhoneGap application (iOS) that needs to make cross origin websocket requests to a Go server. I have set $.support.cors = true; $.mobile.allowCrossDomainPages = true; in my application before any network activity. The server serves a simple HTML/JavaScript page for testing / diagnostic purposes and everything works great there - the websocket connections work, the server delivers the correct data, it's all dandy.
This is not the case with the PhoneGapplication running on the iOS Simulator. In the Simulator, Safari can in fact reach my testing/diagnostic page. However, the PhoneGapplication times out.
I'm doing more investigations but my suspicion is that this is a simple server configuration issue and someone with more knowledge of Go and/or the blessed websockets package and I thought I'd ask here concurrent with my investigation.
CORS does not apply to WebSocket. With WebSocket, there is an "origin" header, which browser MUST fill with the origin of the HTML containing the JS that opens the WS connection. Non-browser clients may or may not fill that header (and can fill it with anything they like anyway). The WS server then is able to decide whether to accept the connection or not.
Further: I don't know if the WebView used by PhoneGap sets the origin header when the HTML comes from local filesystem. I would try wiretap the traffic and have a look.
There is no Cross Domain concern in PhoneGAP appliations (remember that this policy is enforced client side and that the server's header only give an indication).
The problem is probably in your handshake as PhoneGAP doesn't support natively the websocket handshake. There are open source projects introducing it in PhoneGAP/iOS as this one (not tested by me as I'm not an iOS developer).
I have been reading articles about asynchronous messaging between clients using MVC3 and the SignalR library (http://sergiotapia.com/2011/09/signalr-with-mvc3-chat-app-build-asynchronous-real-time-persistant-connection-websites/)
We currently use activemq for some of our fat client apps and use topics to broadcast data to everyone. Does anyone know if this sort of thing could be used in MVC3 as well?
I'd like to create an application that doesn't require a user to install anything (and could even be used on a phone), but it would be monitoring continuously-changing data. We're talking refreshing data every 2-3 seconds.
If you want to have asynchronous messaging with client (browser) use SignalR. ActiveMQ and MSMQ are technologies for thick clients and server-to-server communication. They require installation (MSMQ requires windows installation) and they are not accessible from browser (well I can imagine accessing MSMQ through ActiveX or ActiveMQ from Java applet but that is not what you are looking for).
One of the possible ways to go is to build a web service which will implement communication with AMQ/MSMQ via their APIs and do poll this web service from your webpage (via ajax call for example) to refresh the data as it's needed.
I'm trying to port a win32 application to Windows Mobile 6 / 6.1 / 6.5. It uses winhttp which doesn't appear to be available on the mobile platforms.
My initial thought was to replace it with WinInet - but I wondered if anyone had a better idea?
WinInet is actually a more appropriate HTTP client library for client nodes.
Here's some things I like about WinInet voer WinHttp:
If your client app needs to make lots of requests from the same server, WinInet will implicitly queue the requests up so as not to flood the server. (But is transparent to the client app). In other words, it respects RFC 2616 guidelines on simultaneous connections. This is great when your app is pulling down a lot of images (or files) from the same server simultanously.
Will the use the IE cache for fetching content. (Which I assume an equivalent cache exists on Mobile platforms).
Proxy server auto-detected from IE settings. Probably less of an issue with mobile since the IP network is a bit more open. But if you had to support proxy servers with WinHttp, you'd have to use other API calls to specify the server directly.
I've used Wininet and it works. But it's not ideal as its timeouts are broken. And developing a complete asynchronous design with it required a ton of code.
So instead, I'm trying libcurl.
So far though, I still haven't managed to get it compile properly and link. Porting stuff is such a pain sometimes. But I digress. ;)