I'm building a chat application that allows people from any website to communicate with my website. Here's the visual breakdown:
Website A Server Website B
Msg1 -------> Msg1 -------> Msg1
|
Msg2 <------- Msg2 <------- Msg2
Right now I'm using a polling solution that works for the time being, but it won't scale.
I'm wondering what solid solutions there are that I could use to facilitate this messaging functionality. I looked at JMS briefly, but it looked like it was only for communication from one Java server to another (not HTML to Java to HTML which is what my setup requires)
I wrote blog about how to implement Java WebSocket on Glassfish 3.1.2.2 but It's is Thai language. .... But I thought you can guess from code.
Anyway If you have any problem. You can ask me.
The most easy way would be to set up a database on the server (SQL/ MySQL) and then let the websites communicate with this server. (so this kind of leaves the Java server out of the question)
This is a nice stack question about that.
How you could build it is for example:
- server passes chat-id to both clients after identification
- clients recognise id and store id
- clients keep calling for the database through AJAX calls
- depending on how the database is designed, it could then update the client's chat
screens whenever a new row has been added to the specified database table.
Be careful for SQL-injection though. You don't want people to be able to read all conversations.
Apart from building your own solution, I can highly recommend going with one of the existing plugins.
For example this list of 10 free Website Chat Widgets is pretty good, but there is most definitely already something (open source) out there that fits your needs.
For example this plugin and this plugin looks nice if you want server side regulation. (Haven't used it myself though)
Or if you just want the 'framework' (as far as I may call it a framework), you can use the very low-end solutions like Blueimp's AJAX Chat.
Good luck!
Related
I want to accomplish this:
https://developers.google.com/games/services/web/serverlogin
with Java instead of javascript. I know the APIs exist for Java, as I already have a desktop application and an Android application that are able to login properly to Google, using Java APIs. Now I just need to figure out how to follow the process described above with regular Java.
This line is particularly annoying:
"If the auth object in my google-signin-callback already has an access token, can I send that to the server instead of performing this additional code-exchange step?
A: No. You should avoid sending access tokens to your server if at all possible. The "exchange a single-use code for an access token" strategy is much more secure and we highly recommend using that approach in your applications."
I have seen things that seem to contradict in several places, including on Google's guides. This seems like it would be the easiest way given what I have working, but I'd do it properly if I could figure out how in Java. I want to be able to access Google Play Games Services on the client side as well as the server side.
1) How do I get a single use token on the client side? (on android and desktop)
2) How do I exchange it on the server side?
Thanks
I've been looking around all morning, and can't seem to figure this one out. I know it's not as complicated as I think it is, and all I need is just some pointers to the right direction.
I have an Android application that takes some user input, sends it to a Java application over the web, and then receives some output based on the input.
My Android and Java applications are ready, but how do I go about sending and receiving the data over the web? I understand that I'll be sending and receiving HTTP requests, but my problem is where I'll be sending them and receiving them from. Do I host my Java application on a Servlet like Tomcat, or do I use something like OpenShift to host my application for me?
I have no trouble with sending some HTTP request from my Android application to the web and receiving some output back, but my problem is that my web service needs to use a Java library to process the input and generate the output. I'm just not sure how I'm supposed to get this data to and from this Java library that needs to be hosted on the web.
I hope my question makes any sense.
EDIT: Perhaps I wasn't clear with what exactly I need help with. I do realize that the architecture I use doesn't really make any difference, but the problem I have is with how I'm supposed to use this architecture.
Let's say I have a registered domain name that I can easily send to and receive data from using my Android application - no trouble with that. But how am I supposed to integrate my Java library with this server? Do I just create an applet and put it on my server? Does my web host even allow Java applets to run?
I guess my question is how I'm supposed to get through the "barrier" between my HTTP request / transport layer protocol and my Java application.
Server architecture usually does not matter. You can use Java, NodeJs, Rails, Python, .NET, etc. You just need an endpoint that accepts a HTTP POST/PUT/GET/DELETE/PATCH verb.
This is more a question of "how do I set up a server to accept input" and its a very large topic in itself. I would advise you look at PAAS solutions like:
Parse.com
Kinvey.com
You can use their tools to build a solution fairly quickly. If you need something custom you'll need to build your backend in the language of choice and host it online via AWS, Google Cloud, Heroku, a VPS or something similar.
I am writing an iOS 5.1.1 app for the iPad2 using Xcode 4.4.1. I want to be able to locate a local http server running on Java.
Once I am able to connect to the http server, all I need to communicate with it is the url including the port.
My questions:
1) Should I use Bonjour or a DNS Server running on the http server to discover the http server itself?
2) I need to authenticate the iPad2 user with name and password to work with the http server once I discover it.
I need some help understanding how I would go about accomplishing these two steps including source code if available for the iOS 5 and Xcode 4.4.1.
1) Bonjour is pretty easy to tie in with Java apps. If you're particularly masochistic you can write your own Java-based mDNS (Bonjour) responders (I've done it, it's not rocket science), but the quickest way to get going is to use jMDNS in your http server to advertise its existence. I won't copy & paste the code samples but they suffice for most applications.
On the iOS side, NSNetService is your friend. Fundamentally it involves starting a responder in the background to look for services (i.e. your Java app), then calling a delegate when something appears/disappears:
id delegateObject; // Assume this exists.
NSNetServiceBrowser *serviceBrowser;
serviceBrowser = [[NSNetServiceBrowser alloc] init];
[serviceBrowser setDelegate:delegateObject];
[serviceBrowser searchForServicesOfType:#"_http._tcp" inDomain:#""];
There's a guide that explains it all. The protocol hasn't changed for 10+ years and you count on all modern iOS/OS X versions supporting it. The jMDNS library is pretty well battle-tested at this stage, too.
You might consider creating your own service type if you don't want it to be visible to other apps that search for _http._tcp., although this is just a cosmetic thing.
2) The simplest thing that'd work would be HTTP basic auth; you didn't say what kind of authentication your app supports or how you make HTTP requests on the client side, but this is pretty well covered already.
I am interested in putting a chatting functionality as part of an application.
What I am interested in:
I would like to keep my application instances acting as peers, i.e.
I would prefer not to write also some server module to handle
message communications
I would like it to be able to use it with exising IM accounts. E.g.
someone can use it using his MSN account or any other client
account he may have, same way he would use MSN Messenger or Tor client etc
I googled and found that there are some Java MSN libraries available and also some other libraries that support IM e.g. SMACK for JABBER etc (not sure what that is) but I am not sure if the latter could be used for option 2 I mention.
My preference on 2 is because I assume that this way a user could do chat no matter where he is while in other solution I assume that some network infrastructure e.g. with routable IPs etc would be required. Am I wrong here?
Does anyone have expererience with Java IM libraries? Are for example any issues e.g. with different MSN versions or something?(Don't know if the protocol has been changing often to matter for me).
What would be the best path/option for my requirements?
I would go with a Jabber based approach. Jabber (also called XMPP) is an open protocol with lots of implementations and supports connecting to other IM services via transports. That way you would not have to deal with changes to the Windows Live protocols. You can rely on the open source community to provide that functionality for you.
Edit: It seems, that Windows Live even allows native XMPP access.
If you like, you can always set up your own Jabber server to provide a tighter integration with existing user accounts. In that case you wouldn't need to write the whole server.
I am currently trying to transfer a file from a Android device to a Java TCP Server, but I am unable to find a good example which explains the structure I would need to implement this. There are many Java Client&Server examples there which explain file transfer but I want to make sure if this will still work once one throws an Android Device in there.
My question is how do I implement this sort of structure? And if it doesn't work, would I be better sending the file over an HTTP connection to a PHP server? I see a lot of examples and documentation online for the later method so I presume it is more reliable. I would however prefer to use a Java server.
The file consists of a large set of coordinates recorded by the Android device which will then be sent to the server. I have not yet established how I will store this data yet but I was originally going to store them in a primitive text file.
Design
The first thing you need is something to allow you to run Java code on your server.
There are a number of options. Two of the most popular technologies are Glassfish and Apache Tomcat.
Crudely speaking Apache Tomcat is sufficient for simple client-server communication and Glassfish is used if you need to do more complex stuff. Both allow Servlets (which are essentially self contained server classes written in Java) to run on the server-side.
They handle communication with the client by launching a JVM (Java Virtual Machine) each time they receive a request. The Java servlet can run inside the JVM and respond do some processing if required before sending a response back to the client.Each new request is run in a new instance of a servlet. This makes dealing with multiple concurrent requests simpler (no need for more complex threading).
Networking (sending data to and from the server)
In networking situations the client can be a PC, an Android phone, or any other device capable of connecting to the internet. As far as the server is concerned, if the client can communicate using HTTP (a standard protocol which it understands) the it doesn't care what sort of device it is. This means that solutions for PC desktop client-server applications are similar to one for a phone.
You can use library such as Apache HTTP Components to make it easier to handle HTTP requests and responses between the device and the server. Of course you could write your own classes to do this using Sockets but this would be very time consuming, particularly if you have never done it before.
Storage of Data
If you have time I would recommend implementing some sort of database to store the information.
They have a number of benefits to such as data recovery mechanisms, indexing for fast searching of data, ensure data integrity, better structuring of data and so on.
If you decide to use a database I recommend MySQL. It is a free and more importantly - well documented.
Aside: JDBC can be used to communicate with the database with Java.
Sorry about the in-line hyperlinks - apparently my repuation isn't high enough to post more than two!
Source: Personal experience from implementing a similar design.