I'm creating an application that consists of a web-based front-end and a c++ back-end and has the following requirements:
1) There should not be any installation of web server like Apache or similar software
2) The front-end UI should be able to trigger the back-end to perform specific measurements
3) The back-end after the computation of the measurements should return the value to the front-end in order to be depicted on the WEB UI.
I'm quite new in network programming so I made a research and I found that the absence of an installed web server can be replaced by an http server implemented in c++ with a relevant library like boost or poco.
However what confused me a lot is the way/ways that the front-end and the back-end can communicate with each other. I'm aware that C++ is able to create not only a simple but also a web socket.
What I'd like to ask is whether for the aforementioned functionality a simple socket will do the job or do I need to use web socket? If a simple socket is enough to transfer the data from the back to front-end in what way the html front-end can communicate with the c++ back-end? In your opinion which is the most stable and efficient way?
Communication with the web browser requires the use of whatever features the web browser happens to support. A "simple socket" is not something that exists in browsers.
The majority of all web applications use simple HTTP requests (so-called "AJAX") to a "REST" interface for most interactions, and WebSockets for those that require the ability to "subscribe" to live changes or where bandwidth-efficiency is more important than resilience against disconnections.
Remember that the browser only (generally) supports JavaScript, and that your communication between front-end and back-end is transactional by default (that is, request-response as opposed to message handling.)
Related
I am building a trading back-end that provides live streaming prices (over Websockets) and trading functionality (REST endpoints) to the web client. The back-end was planned to be build with Django. However, the back-end also needs to receive live prices over TCP/IP connection from the 3rd party server and further distribute prices over Websockets to end-users.
Django is powerful and has lots of built-in features out-of-the-box including REST framework, admin panel, ORM, etc.
However, how I start a TCP connection and distribute price feed over Websockets? Can I use a management command to start a new thread?
Should I rather look into a different frameworks like Tornado? Tornado is apparently good for non-blocking network I/O and Websockets. However, it's a complex thing with a lot of state.
If I could, I'd rather stick with Django. What would you suggest?
I am developing an Emergency Response System. I have developed my server using the Django Framework in Python. I have an Android Client which needs to communicate with the Server. My question is :
1) Should I use REST API for communicating between the Android App and the Django Server?
2) Or is there any other RPC methods (like RMI in Java) which should be used for communication?
3) The Client developed as an Android App needs to send requests/messages to the server based on the user interaction. Would a REST API be a good option?
Thanks.
Use HTTP. This is the easiest protocol available to you.
REST is an architecture pattern (it describes how you would design your API service and client). It is designed to use HTTP (a protocol).
In order to implement RMI you would have to find an implementation for JRMP on Android and then make sure that all your users have access to this over the network; you would also have to use TCP/IP which would be near impossible to implement separately on your remote clients (unless you have deep level control over them) and even then, the network should allow such access which most mobile providers will not.
It is not practical, and it will not work reliably.
Does web api have more advantage than socket communication when I am writing a software need calling server to function?
If we write a web api,do we can take advantage of http, http server, web app framework to do more thing with less work than doing the same function by socket ?
If my client call my server through internet, Do we have not any reason to not implement it as web api ?
I'd say that 'web API' is-kind-of a 'socket API'. While socket API may be basically anything running over sockets, web API is done using the HTTP protocol. That has a bit of limitation but usually the advantages are more important:
You reuse existing protocols and methods instead of re-inventing your own ones. That makes the work easier for you, and much easier for your users who do not have to implement everything from scratch;
You can use existing tools (and even a regular web browser) to debug your API. Well, with socket API you usually can use telnet but with more complex cases, a web browser or any HTTP querying tool is simpler to use;
You reuse HTTP ports 80 (and/or 443). That usually means it's less likely that any firewall will forbid your users to access the ports used by your service;
And after all, if you choose the right technologies, you can reuse them 'in' or even 'as' web pages. For example, you can use AJAX or similar technologies to catch data from your API in scripts on your web page.
Even better, if you just use XML for the API output, you can basically make it an API and a web page at the same time. You simply add a reference to an XSLT stylesheet to it, and whenever a web browser uses that API, it will use it to transform the raw XML into HTML.
Web services only output XML instead of HTML. The reasons why you should create a web service does not differs from the ones for creating a web site.
A web API can be called remotely.
A web API can be called in an independant manner. That means that you can allow you user (and you) to use an other interface that the one you build for the final customer.
You can program the API the way you want. The only requirment is to produce valid XML. So, yes you can use some framework, you are supposed to use a web server as the ones that output webpages.
If the client call your service throught Internet (SAAS), creating a web service allow you to give a new interface. Web services are required in order to use SOAP and to allow refreshing of webpages and also to give the datas to a heavy client.
Assume there are 2 web services A and B setup in SOA infrastructure.
Web services A depends on information that is available from the locally installed Desktop application (its a legacy application based on C++ programming and provides C++ API to give the information needed by web service A).
The scenario is this: Human actor (which can be considered as Consumer of web service B)logs into a website and clicks a button which requests the service provided by web service B. As part of this request, his ID is sent. Web service B sends request to web service A with this ID. Web service A uses this ID to somehow determine a way to talk to locally installed desktop application of the human actor who originated the request.
The main problem how can web service A connect to desktop application and get the information in a reliable way using SOA infrastructure.
Assume that everything in this SOA is Java based except the desktop application.
The desktop application is basically like a CRM application with its own internal database and not traditional database like MySQL. It provides just basic textual information about the human actor and about the customer(s) of that human actor in his installed CRM desktop application.
I do want to use SOA related technologies even though it may be more complicated.
Given above details:
How can I use JMS to solve this problem?
If JMS is not the right solution, what about ESB and how can I use ESB to solve this problem?
The communication with the desktop application will greatly be determined by what different methods the application is capable of performing. If the application has a database backend, an ESB can facilitate communication with predefined adapters for the specific database being used. If the application has an api that can be tapped programmatically, that is a method as well. I am not sure JMS would be the appropriate solution since given your use case you would want a synchronous reply. Putting JMS in the middle (somehow) will break that reply and rather return an asynchronous response.
I would recommend looking more into the functionality available in the desktop application and with your findings start with evaluating ESB functionality. An ESB may be overkill for this use case but if you plan to do more operations like this it may become valuable.
I think the problem boils down to a Java Web Service A, having a requirement to talk to a C++ desktop application to get user details.
If the Desktop application is able to use JMS using Stomp etc, ActiveMQ or HornetQ maybe used. This also allows you to scale A into multiple instances across many machines, and use JMS to request user information from the Desktop application.
Another option is to expose a simple API (REST, TCP etc) on the Desktop application and make the Web Service A talk to the Desktop application using that. Again, you could distribute the A into multiple instances for scalability.
You can use an ESB to convert a REST call to TCP, or a SOAP to JMS etc. Basically any-to-any conversion. The Free and Open Source ESB UltraESB [http://adroitlogic.org] contains many examples, and is lightweight (~35MB) so the 'overkill' will be minimal compared to > 300MB+ resource hungry ESBs
I have a C++ web service that needs to send/receive data from a Silverlight client.
Can I still use the WCF RIA client or do I need to use the sockets library directly?
Note that I'm pretty flexible on using HTTP or not, and I even prefer not to use the HTTP protocol.
Now this is just me thinking outloud here. But I'd assume that since you're using a C++ web service you're too low level to be doing anything WCF based (as WCF is usually a C# thing).
As far as using a sockets library directly, I think that a silverlight app can't do that for security reasons. Sockets are mainly for a client app that you have built yourself. But silverlight is a web client, So I would think that you'd only be left to use http requests.