Most of the demos of Websockets I see are of a chatroom application. I was wondering if it was possible to create more of an Instant Message implementation. The difference being that, in a chatroom application, numerous users connect and share messages with everyone, where, in an instant message application, users can connect to other users they choose.
I would like it to work without any plug-ins. I'm using JavaScript for the client side and Java EE for the server side. I looked into being able to change the endpoint URL but it seems that it has to be known at compile time. I also looked into using the Session object in the onMessage method but how would I know the session object of the user I need to send the message to? And I feel that would be a slow method to cycle through all session objects looking for the correct one. So, how could I create an Instant Message like application using WebSockets?
Websockets are for communication between server and client using the HTTP protocol.
They are a particularly fit solution for any cross-language/cross-platform real time streaming/message passing related tasks, because the client(s)/consumers get notified instantly when any new data arrives, without the need of polling**.
The browser implements the client part of the specification.
Most server-side languages have libraries implementing the server part.
If you want basic instant messaging it's as easy as regular chat: you just have to change the list of recipients from everybody in the chat room to the particular client(s) on that conversation.
If you want to build a production grade instant messenger app, you should be aware you don't have to reinvent the wheel: You can built your messenger app on top of any XMPP library or code your own implementation of the protocol. Either way it takes away a good part of the design burden, letting you focus on the GUI or whatever extensions you consider appropriate.
If you are interested on the latter. check out atmosphere (specially, their plugins and extensions) and this article (it's a little bit old, but it's good introductory stuff):
http://jfarcand.wordpress.com/2010/11/08/using-jquery-xmpp-and-atmosphere-to-cluster-your-websocketcomet-application/
(** If you wanted to use RMI instead, for example, you'd need a JVM on both server and client sides or the RMI-IIOP implementation for CORBA support, which is quite cumbersome for simple tasks. There are also some popular alternatives based on Comet, which is more of a set of techniques than a W3C standard: It's a little more difficult to use than websockets and has a few limitations, but has the benefit of working with legacy technology and implementing real time communication without the need of polling, by using HTTP 1.1 persistent connections)
Related
sorry if my english isn't perfect.
I'm trying to make an app and I need to exchange information between more devices.
I thought that could be a solution connect the devices on a server but I really don't have the idea where start.
What language I need to study to make this? There is a better solution?
This highly depends on what you are trying to achieve in the first place. It would be helpful if you could tell what you are trying to do, but I will still outline some general aspects:
You need to decide, what information is going to be exchanged and how this should happen
What information: Figure out, what exactly needs to be sent and received. Generic text messages? Images? Byte Streams?
How should this be done: Generally spoken, there are two approaches of getting information as a client: Polling and subscribing.
Polling: This approach means to periodically check an endpoint for new data. For example, HTTP uses this way: A web browser or any other client (REST-Client for example) periodically requests information from a HTTP-Server, using a connection just for this single request.
Subscribing / Sync / Notification: In some way or another, the client tells the server that it is interested in the information and wants to get notified when there is something new. The connection is initiated at the beginning and held open for further usage. The benefit of this approach is that changes are received immediately, but on the other hand a permanent connection needs to be maintained.
Things to study
At the beginning, get a good understanding of the TCP/IP Protocol, how Sockets work, how common Protocols do their job (e.g. HTTP, WebSockets)
Take a look at specific Protocols working on top of the basic ones
Tip: REST: Most common WebServices Protocol, providing a common way to exchange stateless data. Uses Polling.
WebSockets: Socket connection using Web Browsers. Commonly used to update information without needing to poll.
There is no specific language to learn for connections. It's more about understanding what the difficulties are and what ways have been invented to address this. Once you get to this point and know what you want to do, it's possible in every language.
Recommendation: As you seem to use Java/Android, I would try to use REST. A really great client-side library for REST on Android is Retrofit. For the server side use what fits for you .. common Java way would be to use Jersey, but you are free to choose from a lot of choices. If using Jersey is too hard for the beginning, maybe take a look at the JS/NodeJS world, those guys invented Express, which allows you to create a REST service out of just a database, wihtout having to code a lot.
First you need to decide if you want to go for an Android or an iOS application. There are other various mobile operating systems as well, but these are widely used . If you want to go for android which is most widely used in my opinion, then you need to learn Java. If you want to go for iOS application, then you need to learn swift or objectiveC. These languages provide the API to connect with various types of services such as Facebook, Firebase and Amazon etc. If you want to connect to some other local server who’s IP is known to you, then you can use socket programming to send messages.
There could be many ways you can implement this. One way will be using Web services. Of course REST might be a better option, if you follow this approach. You can implement Your service(server side code) with any language. I will recommend you use java since you are already using android.
Aside from this You might need to go through the basics of REST, its specifications and
some reference implementations for language of your preference.
We've got a server app and two stand alone client apps (both with different functionality - one for front office and the other for back office). Everything is written in Java.
What we need right now:
If both apps are running - click on a button in one app -> checks to see if the other app is open and triggers some functionality (display a message, open a frame) on that app
if the other app isn't open -> it should display a message saying so.
Can anyone point me in the right direction to achieve this. The best real life example I can give is: how clicking on the an itunes link in the web browser opens the iTunes application if installed and to the relevant appstore page.
EDIT: Our applications don't deal with websites at all. Everything uses Swing.
There is no "best" way to achieve inter-app communications but there are many ways; the best one will be the one that fits best your environment: network conditions, firewalls, number of calls, synchronous vs asynchronous, etc...
Usually communication is achieved using either:
Remote Procedure Calls: an app basically calls a function/method on the other app and passes arguments. RPC are usually synchronous: the response is sent within the same communication/transaction
Messaging: an app sends messages to the other app which, maybe, replies with other messages. Messaging is usually asynchronous.
The frontier between the two can be pretty blur with some protocols like REST.
In the Java world,
RPC is usually achieved using either
RMI: Java only solution; easy to implement; does not like firwalls much.
SOAP Web services: not Java centric; hard to implement; full of traps; network friendly.
Messaging can be achieved using
JMS: Java only; rather easy to implement but asynchronous; extremely powerful on high loads
JSON/XML HTTP/s Messaging: there are many protocols here from the most secure like AS2 to RNIF, plain XML/Json POST etc... These are network and language agnostic but always require some work to implement.
An hybrid approach is REST which has become very popular due to the benefits of an easy implementation and network friendliness but has the drawbacks of not being very formalized. it is a technology rather than a specification. I would look at documentation around JAX-RS and frameworks like Restlet and Jersey to get you started.
(Edit)
I purposely did not mention developing your own with Java sockets. IO is by definition impure and often multithreaded: IO is very hard to get right. If you really insist going down that route, at least, use the help of a proper framework like Apache Mina or Netty.
I want to create a Java server in the client's browser to collect and manage communication
and update the displayed material in the client browser and receive the Get Push Post statements and then communicate through a long life persistent link for security reasons.
I know some universities have started working on this type of service
But i would prefer to do this from another approach.
What services/plugins are there that can help me in this field.
Its taken me a long time just to get to this point to even know what I'm asking for
But now I'm hearing I just need the tools and implementation of them.
What you're looking for is probably known as COMET, and can be done purely in JavaScript, without requiring a Java applet: http://en.wikipedia.org/wiki/Comet_(programming)) The advantage being that it could be implemented on a mobile device/tablet as well.
There are a number of libraries that will help you accomplish this depending on your programming environment. I tend to work in JSF, and so I favor tools for that environment, (IceFaces, RichFaces, PrimeFaces) but your choice of tools will depend on your specific application environment, which you haven't provided much detail about.
I'm building a multiplayer card game using Flex on the client side and Java on the server side and I wanted to know if I must sockets and the accept method in order to connect users to the server for in order for them to join a game room or create one or to chat.
In the past I've learned how to build a game server which both sides are JAVA and connection was in sockets but now days the client side will be in FLEX which has few ways to connect to a Java server (XML,SOAP,BLAZEDS(AMF)) and I find it hard to understand how to write the Java server in order to do all the features of a game server , especially managing the rooms and sending data back to the users.
In the sockets way, when a user was connecting to the server and he had opened a room, this room was opened on a thread and who ever was joined that room then he was connected to the same thread and sending the messages to the right place was easy, so the problem is understanding how to do the same using SOAP or BLAZEDS.
Any help would be appreciated.
Thanks.
Please make your questions concise, it is difficult to know what is being asked for.
If you ask the difference between socket and webservice, sockets are used to manage the basic networking communications. Over them, you can receive/send bytes in whatever format / protocol you chose to.
SOAP / Webservices is just one of such formats, its advantage is that it is a standard way of encoding messages so you can easily write code that connects to your service in most platforms, and those messages are human-readable. The main disavantage is performance, both in bandwith and processing power (specially to parse it at the receiving end).
If you are starting, I would advise designing a format related to the application you are using to simplify things.
Take a look at RED5 and remoteSharedObjects. Using this tech, you can essentially put you "game" object in a remote shared object, and all the clients will have the same object with real time updates. Then on top of that you can use AMF (the protocol behind BlazeDS) for your less dynamic data.
Using raw sockets gives you the benefit of control. Control of your protocol format ( how your message data is structured). And because of this you can tweak your messaging to be more secure, or faster, or more robust, depending on your application requirements. All that control comes at the cost of complexity and maintenance. Because you get to say exactly what you want to send and how you want to send it you need to write and debug alot more code. Another issue with raw socket communication is that it has a significantly greater chance of being blocked by firewalls.
Using web services removes some of the complexity of deciding on a message format (with that being it's main benefit). You don't have to worry about things like byte endian-ness, string encodings, or data conversions (as much). As such web services really excel at data communications amongst heterogeneous clients and servers where inter-operability is key. The cost being that it's relatively complicated to serialize/deseserialize, and as such, slower than binary messaging formats. Web services are good to use when you have to communicate with client applications that you have little control of (not really your case). Web services are traditionally tunneled through HTTP, so there is an additional advantage in being able to worry less about a firewall blocking access to your game.
BlazeDS attempts to bridge both worlds - it gives you some of the robust features of web services (fallback communication options, firewall interoperability etc), but uses it's own binary format for serialization/ deserialization. This gives it some of the speed of using raw sockets without a lot of the downsides. I think it's a great candidate to explore, but if you find yourself needing more speed then raw sockets would be worth messing around with.
Good luck.
Sockets are the programmatic interface to OSI Level 4 Transport Layer. Everybody uses them, ie Webservices is a Level 7 Application Layer interface that hides the lower levels.
If you need real-time bidirectional data exchange between your client and server you're better off managing your own TCP sockets. Flex still supports sockets.
In order to satisfy customer requirements, we will need to let users exchange information among each other. The 'messaging system' does not have sophisticated back-end requirements and could be easily implemented with a few tables to store messages and message types.
The problem is that I believe that the requirements on the front-end are very high and usability is very important. In addition I expect this communication's part to become an important part of the system in the long run.
Is there anything that can be directly integrated into a Java web application and adapted to the application's design? What we need is the following interface
From service layer:
send message to user (header, subject)
reply to a message
notification on new message in user inbox (if possible: on current page)
interface to existing user management
Preferably, the component should already have a front-end with the following functionality:
message management (select, remove, reply, delete/restore, ...)
folders: inbox, sent, trash
tagging: message categories
show last x messages in a panel/div
styling to look like the application
If there is something reasonably stable, I would prefer using a component before implementing something like this into the application. The application runs on Wicket, but we are not tied to this framework for the messaging component.
Thank you,
Kariem
In portal servers, you have the flexibility to add portlets that could do something similar to the component I am looking for; e.g. Liferay provides mail and message boards portlets.
As akf points out in a comment Jabber provides a solid basis for messaging. We are looking for something that can be integrated into a web application. If we have to build a lot of UI around Jabber, we cannot really consider it a good fit for our requirements.
Ok, it may be a bit surprising but what about giving the Google Wave a try ?
If I review your criteria :
Is there anything that can be directly
integrated into a Java web application
and adapted to the application's
design [...]
It can be as you will discover on this mini-tutorial : http://blog.zenika.com/index.php?post/2010/01/27/Google-Wave-Embedded-API-the-missing-tutorial (how interesting isn't it ?)
From service layer:
send message to user (header, subject)
reply to a message
notification on new message in user inbox (if possible: on current page)
interface to existing user management
Everything but the last point is offered by the Google Wave instance. The last point may be a bit harder to solve as you will require that all of your user have a googlewave account. Managing those accounts may become available through Google Apps, but atm it's not feasible. If it's absolutely mandatory you could plan to have your own instance since it is an open protocol but your goal was to have something already done for you, right ?
Preferably, the component should
already have a front-end with the
following functionality:
message management (select, remove, reply, delete/restore, ...)
folders: inbox, sent, trash
tagging: message categories
show last x messages in a panel/div
styling to look like the application
Great, all of this is ok with the Wave.
If there is something reasonably
stable, I would prefer using a
component before implementing
something like this into the
application. The application runs on
Wicket, but we are not tied to this
framework for the messaging component.
Ok Wicket is so trendy, you should love this solution :-)
I acknowledge that is a bit 'avant-gardiste', I have never done such a thing myself but thought it could have broaden your vision as regard to your problem...
If you are looking for opensource java email clients:
http://java-source.net/open-source/mail-clients
You may also want to have a look at Google Wave . With this you will have next generation communication and collboration tool. Please see some awesome videos about google wave on www.youtube.com
http://code.google.com/apis/wave/
http://code.google.com/p/wave-protocol/wiki/Installation
.
Updated solution... Web based email clients
http://java-source.net/open-source/web-mail
http://code.google.com/p/cubusmail/
http://www.zimbra.com/downloads/os-downloads.html
I think a web-based IM client like SparkWeb can be useful in your scenario.
Using XMPP protocol for messaging is recommended because you can easily federate your server with other chat servers, such as GTalk and Jabber.
If you intend to embed the messaging server into your application, Tigase is a fast and reliable Java XMPP server which can be easily integrated because of being lightweight and having no third-party dependencies. It also scales to hundreds of thousands of users almost seamlessly.
For the client, you can use many available web-based XMPP clients such as emite which is a GWT-based web client that is both beautiful and AJAX.