Can someone please explain me the exact difference between an application server and a web server. I've researched a lot but didn't quite get a satisfactory answer. Thanks in advance!
Well, according to the (description of the) tags you had associated to your question;
An application server is a software framework dedicated to the efficient execution of procedures (programs, routines, scripts) for supporting the construction of applications. Normally the term refers to Java application servers. When this is the case, the application server behaves like an extended virtual machine for the running applications, handling transparently connections to the database at one side, and connections to the web client at the other.
A web server is a software application that services requests from clients using the Hypertext Transfer Protocol.
Ive done a lot of researching but I'm a bit overwhelmed by the possibilities i seem to have.
What i want to achieve:
I need to develop a web interface on a linux/windows server, which communicates through tcp via the opc protocol to control some leds.
the plan is that the web interface would open a tcp socket server, where the clients with the leds can connect. when the user gives data to the web interface, it then sends the opc data via the socket to all connected clients (or selected clients). it should also be possible for the web interface to receive answers from the clients.
the problem is, that until now i only had a web interface which i programmed in plain js/php/html, without any help of a framework or something like that.
with that knowledge it is very difficult to imagine how i should realize the communication via tcp. as far as i know plain javascript or php does not support tcp sockets.
1. Websockets
I tried to achieve a similar function with that implementation once, but the problem is that i have to write a separate websocketserver which adds another source for failings. it seemed not to be very stable, which is why i would prefer a "direct" tcp socket connection.
2. Frameworks
Is there a framework which can level me up from plain js/php/html which adds the required functionality? what additional function would a framework give me? I'm not quite understanding the need of a framework.
3. ASP
asp.net seems to be what i want to achieve. a "single-application" web interface which can also target server hardware like tcp or serial. But the problem would be, i think, the enourmous learning curve when developing such an app. i'm also not sure if mono can run the asp.net with full functionality at the moment.
So long story short, what would your approach be?
I think you can do that in Mono and ASP with no problem. But considering that you started your project in php, you can use tcp/ip sockets with it:
PHP TCP/IP example
Best regards
I'm searching a simple implementation to push changes from a free relational database (PostgreSQL, MySQL, SQLite, etc.) to clients' browsers via WebSocket or WebPush.
I want to avoid all the server-side JavaScript ecosystem (Node.js, npm & cie) and the NoSQL databases.
All must be hosted in the servers of my company, I can't use third-party services.
I found these interesting solutions :
http://initd.org/psycopg/articles/2010/12/01/postgresql-notifications-psycopg2-eventlet/ [with Python]
https://gist.github.com/drocco007/6e44ac1a581546c16e67 [the same one slightly improved]
https://coussej.github.io/2015/09/15/Listening-to-generic-JSON-notifications-from-PostgreSQL-in-Go/ [with Go]
Do you know other ways to get this done?
Is PostgreSQL the more suitable free RDBMS to do this?
Can it be accomplished with a SQLite database?
Can Apache or NGinx abilities be used to achieve this?
Update 01/23/17: I wrote an application called postgresql2websocket in order to send PostgreSQL notifications over websockets using Python 3 with asyncio + aiohttp + asyncpg https://github.com/frafra/postgresql2websocket; you could combine it with PostgREST in order to have both standard REST APIs and realtime updates using WebSockets.
As far I know, there is no HTTP server extension for using SQL databases with Websockets without anything in the middle.
You can use Python on the server side, like this: Real Time Web Apps with (just) Python and Postgres. I think it could be improved thanks to aiopg. If you don't need Websockets, you can just use ngx_postgres.
If you like Django, Django Channels will be probably included in Django 1.10 (Redis/in-memory/... layer for channels and SQL backend).
You could use SQLite, but bear in mind that you have to implement a separate server side publish/subscribe mechanism (like Django channel does), because SQLite doesn't have one.
If you're just interested in pub/sub over Websockets, you could use Webdis (Redis-based solution): it would be probably lighter than a full SQL database.
First off, I intend no hostility nor neglegence, just want to know people's thoughts. I am looking into bi-directional communication between client and server; client being a web application. At this point I have a few options: MS-proprietary duplex binding, from what I hear unreliable and unnatural: comet, and web sockets (for supported browsers).
I know this question has been asked in other ways here, but I have a more specific question to the approach. Considering web sockets are client-side, the client code sits in JavaScript. Is it really the intention to build a large chunk of an application directly in JavaScript? Why didn't W3C do this in web services? Wouldn't it be easier if we were to be able to use SOAP to provide a contract and define events along with the existing messaging involved? Just feels like the short end of the stick so far.
Why not make it simple and take advantage of JS dynamic nature and leave the bulk of code where it belongs....on the server?
Instead of
mysocket.send("AFunction|withparameters|segmented");
we could say
myServerObject.AFunction("that", "makessense");
and instead of
...
mysocket.onmessage = function() { alert("yay! an ambiguous message"); }
...
we could say
...
myServerObject.MeaningfulEvent = function(realData) { alert("Since I have realistic data...."); alert("Hello " + realData.FullName); }
...
HTML 5 took forever to take hold....did we waste a large amount of effort in the wrong direction? Thoughts?
Sounds to me like you've not yet fully grasped the concepts around Websockets. For example you say:
Considering web sockets are client-side
This is not the case, sockets have 2 sides, you could think of these as a Server and a Client, however once the connection is established the distinction blurs - you could then also think of the client and the server as "peers" - each can write or read in to the pipe that connects them (the socket connection) at any time. I suspect you'd benefit from learning a little more about HTTP works on top of TCP - WebSockets is similar / analogous to HTTP in this way.
Regarding SOAP / WSDL, from the point of view of a conversation surrounding TCP / WebSocket / HTTP you can think of all SOAP / WSDL conversations as being identical to HTTP (i.e. normal web page traffic).
Finally, remember the stacked nature of network programming, for instance SOAP/WSDL looks like this:
SOAP/WSDL
--------- (sits atop)
HTTP
--------- (sits atop)
TCP
And WebSockets look like this
WebSocket
--------- (sits atop)
TCP
HTH.
JavaScript allows clients to communicate via HTTP with XMLHttpRequest. WebSockets extends this functionality to allow JavaScript to make arbitrary network I/O (not just HTTP), which is a logical extension and allows all sorts of applications that need to use TCP traffic (but might not be using the HTTP protocol) to be ported to JavaScript. I think it is rather logical that, as applications continue to move to the cloud, that HTML and JavaScript support everything that is available on the desktop.
While a server can do non-HTTP network I/O on behalf of a JavaScript client and make that communication available over HTTP, this is not always the most appropriate or efficient thing to do. For example, it would not make sense to add an additional round-trip cost when attempting to make an online SSH terminal. WebSockets makes it possible for JavaScript to talk directly to the SSH server.
As for the syntax, part of it is based on XMLHttpRequest. As has been pointed out in the other posting, WebSockets is a fairly low-level API that can be wrapped in a more understandable one. It is more important that WebSockets support all the necessary applications than that it have the most elegant syntax (sometimes focusing on the syntax can lead to more restrictive functionality). Library authors can always make this very general API more manageable to other application developers.
As you noted WebSockets has low overhead. The overhead is similar to normal TCP sockets: just two bytes more per frame compared to hundreds for AJAX/Comet.
Why low-level instead of some sort of built-in RPC functionality? Some thoughts:
It's not that hard to take an existing RPC protocol and layer it on a low-level socket protocol. You can't go the opposite direction and build a low-level connection if the RPC overhead is assumed.
WebSockets support is fairly trivial to add to multiple languages on the server side. The payload is just a UTF-8 string and pretty much every language has built-in efficient support for that. An RPC mechanism not so much. How do you handle data type conversions between Javascript and the target language? Do you need to add type hinting on the Javascript side? What about variable length arguments and/or argument lists? Do you build these mechanisms if the language doesn't have a good answer? Etc.
Which RPC mechanism would it be modeled after? Would you choose an existing one (SOAP, XML-RPC, JSON-RPC, Java RMI, AMF, RPyC, CORBA) or an entirely new one?
Once client support is fairly universal, then many services that have normal TCP socket will add WebSockets support (because it's fairly trivial to add). The same is not true if WebSockets was RPC based. Some existing services might add an RPC layer, but for the most part WebSockets services would be created from scratch.
For my noVNC project (VNC client using just Javascript, Canvas, WebSockets) the low-overhead nature of WebSockets is critical for achieving reasonable performance. Until VNC servers include WebSockets support, noVNC includes wsproxy which is a generic WebSockets to TCP socket proxy.
If you are thinking about implementing an interactive web application and you haven't decided on server-side language, then I suggest looking at Socket.IO which is a library for node (server-side Javascript using Google's V8 engine).
In addition to all the advantages of node (same language on both sides, very efficient, power libraries, etc), Socket.IO gives you several things:
Provides both client and server framework library for handling connections.
Detects the best transport supported by both client and server. Transports include (from best to worst): native WebSockets, WebSockets using flash emulation, various AJAX models.
Consistent interface no matter what transport is used.
Automatic encode/decode of Javascript datatypes.
It wouldn't be that hard to create a RPC mechanism on top of Socket.IO since both side are the same language with the same native types.
WebSocket makes Comet and all other HTTP push type techniques legible by allowing requests to originate from the server. It is kind of a sandboxed socket and gives us limited functionality.
However, the API is general enough for framework and library authors to improve on the interface in whichever way they desire. For example, you could write some RPC or RMI styled service on top of WebSockets that allows sending objects over the wire. Now internally they are being serialized in some unknown format, but the service user doesn't need to know and doesn't care.
So thinking from a spec authors POV, going from
mysocket.send("AFunction|withparameters|segmented");
to
myServerObject.AFunction("that", "makessense");
is comparatively easy and requires writing a small wrapper around WebSockets so that serialization and deserialization happens opaquely to the application. But going in the reverse direction means the spec authors need to make a much more complex API which makes for a weaker foundation for writing code on top of it.
I ran into the same problem where I needed to do something like call('AFunction', 'foo', 'bar') rather than serialize/de-serialize every interaction. My preference was also to leave the bulk of code on the server and just use the Javascript to handle the view. WebSockets were a better fit because of its natural support for bi-directional communication. To simplify my app development, I build a layer on top of WebSockets to make remote method calls (like RPC).
I have published the RMI/RPC library at http://sourceforge.net/projects/rmiwebsocket/. Once the communication is setup between the web-page and the servlet, you can execute calls in either direction. The server uses reflection to call the appropriate method in the server-side object and client uses Javascript's 'call' method to call the appropriate function in the client-side object. The library uses Jackson to take care of the serialization/deserialization of various Java types to/from JSON.
WebSocket JSR was negotiated by a number of parties (Oracle, Apache, Eclipse, etc) all with very different agendas. It's just as well they stopped at message transport level and left higher level constructs out. If what you need is a Java to JavaScript RMI, check out the FERMI Framework.
I was wondering if it is possible to have a RESTful web service and a bidirectional communication with the clients and server.
In my case the state on the server can change, so the server should send a message to the clients to update themself. Perhaps that's totally against the RESTful idea.
Can I AJAX help me with this issue?
Thanks!
Not really possible under the standard http paradigm, but check out Comet for a possible workaround on that problem and there is alway polling.
The functionality you are after is treated by the concept of web sockets, but they are not mainstream yet.
To keep your solution RESTful you can have the clients poll your service. You can optimize any number of ways, like implementing a special method that lets clients query for changes given a timestamp, then the client just keeps track of when it last checked.
You should take a look at BOSH. BOSH is similar to Comet, but more specific, and I think, there are more reliable implementations.
Though, you will have problems serving multiple users at the same time if you want to use a standard REST service. You should think of some other implementation using nonblocking IO.
There are probably more questions about bosh. Of course, there are websockets now too, but if you need to serve old Browsers, you cannot rely on them.