I have Java and Flash client applications. What is the best way for the two to communicate without special Flash-specific servers such as BlazeDS or Red5? I am looking for a light client-only solution.
Well, you can make http requests from flash to any url... so if your java server has a point where it can listen to incoming requests and process XML or JSON, your flash client can just make the request to that url. BlazeDS and Red5 just aim to make it simpler by handling the translation for you making it possible to call the server-side functions transparently.
Are they running in a browser (applet and SWF), or are they standalone apps?
If they're running in a browser then you can use javascript. Both Flash and Java are can access javascript. It's fragile, but it works.
If they're running as actual applications then you can have Java open a socket connection on some port. Then Flash can connect to that and they can send XML data back and forth.
I've done both of these, so I know they both work. The javascript thing is fragile, but the socket stuff has worked great.
WebORB for Java may be of some help to you. It integrates with your J2EE code.
For more info:
http://www.themidnightcoders.com/weborb/java/
I'm sorry, I reread your question that you are only looking for a client side solution. In this case, WebORB will not help you. Sorry for the misunderstanding.
There's a Flash implementation of Caucho's Hessian web service protocol. This approach would be similar to using JSon or XML, but is more performant, since Hessian is a binary protocol. If you happen to be using Spring on your server, you can use the Spring/Hessian binding to call you Spring services directly from your Flash application with minimal work.
Merapi Bridge API
Merapi allows developers to connect Adobe AIR applications, written in Adobe Flex to Java applications running on the user's local computer.
Related
I want to develop a Java server that is able to send messages asynchronously to a client in form of a website with JavaScript. I know that one possibility is using WebSockets, but these are not supported in IE 9.
For transmitting messages from client to server I can use AJAX calls with maybe a RESTful Interface on the server side.
Does anyone have a solution for this?
This is not how webservers work, most of the time. HTTP Webservers are inherently a request-response architecture:
HTTP functions as a request-response protocol in the client-server computing model. A web browser, for example, may be the client and an application running on a computer hosting a web site may be the server. The client submits an HTTP request message to the server. The server, which provides resources such as HTML files and other content, or performs other functions on behalf of the client, returns a response message to the client.
That said, there are technologies that you can use to do this. Read here about Comet and Reverse AJAX:
Is there some way to PUSH data from web server to browser?
You better implement your Java server to act as a Websocket server when it's supported by the end user. For the users who does not support Websocket it should fall back to long-polling.
This behaviour will avoid unnecessary overheads due to long-polling communications whenever possible.
The good thing is you don't have to implement all these behavious from the scratch. You can readily embed and use a reliable implementation available open source.
One such implementation is CometD project. The CometD project was available for more than a decade and it has evolved to solve most of the issues.
If you are looking for commercial products, there are many available. One such would be lightstreamer (http://www.lightstreamer.com).
You need to use a design pattern like long polling since WebSockets is not available. Rather than build it yourself you could use a library like SignalR. SignalR is an ASP.NET library but there is a client for Java (https://github.com/SignalR/java-client)
For anyone who comes across this question more recently, the modern answer (as of early 2021) supported across all browsers (except IE, which even Microsoft has given up on in favour of Chromium-powered Edge) are server-sent events. A most elegant and standardised solution to providing a pub/sub model to web clients.
I am new at using Codename One. I am trying to deploy a server that will interact with my app on Amazon Web Services using OpsWorks. The server is going to run on Apache Tomcat and be a dynamic web project written in Java, and I am wondering the best way to communicate with the Codename One client. I am planning to use the Socket classes provided by Codename One, but and not sure what to use for the server-side code. Will it work to use WebSockets from Apache? I am having difficulty debugging the server code and have hit a wall here. Thanks in advance!
WebSockets aren't compatible with sockets so you will need to code a websocket implementation which is a bit of work. I suggest you use HTTP communication which is more portable and very performant on the devices.
You can also use solutions such as PubNub which allow for fast message based communications.
Anyone has expirience on having Jruby project running on Jboss (using torquebox or whatever) with an ability to communicate with another "japps" not on the same jboss where jruby app is, i.e. some java project on another jboss?
I know there is an torque-messanging but dunno if it's possible to communicate with external(out of jruby-app's jboss) app?
Best practices are welcomed.
Thanks in advance.
P.S. placing that other app on the jboss where jruby app is not acceptible solution.
I can recommend you to use Thrift and build communication via them.
Thrift have generator for both your needed languages (Java and JRuby) and provide good and fast communication.
UPDATED:
Thrift is RPC (remote procedure call) framework developed at Facebook. In detail you can read about it in Wiki.
In few word to save you time, what it is and how to use it:
You describe you data structures and service interface in .thrift file(files). And generate from this file all needed source files(with all need serialization) for one or few languages(what you need). Than you can simple create server and client in few lines
Using it inside client will be looks like you just use simple class.
With Thrift you can use what protocol and transport used.
In most cases uses Binary or Compact protocol via Blocked or Not-blocked transport. So network communication will be light and fast + with fast serialization.
SOAP(based on XML on HTTP) packages, its in few times bigger, and inappropriate for sending binary data, but not only this. Also XML-serialization is very slow. So with SOAP you receive big overhead. Also with soap you need to write (or use third-party) lib for calling server(tiny network layer), thrift already made it for you.
SMTP and basically JMS is inappropriate for realtime and question-answer communication.
I mean if you need just to put some message in queue and someone sometime give this message and process it — you can (and should) use JMS or any other MQ services(Thrift can do this to, but MQ architecture is better for this issue).
But if you need realtime query-answer calls, you should use RPC, as protocol it can be HTTP(REST, SOAP), binary(Thrift, ProtoBuf, JDBC, etc) or any other.
Thrift (and ProtoBuf) provide framework for generate client and server, so it incapsulate you from low level issues.
P.S:
I made some example in past https://github.com/imysak/using-thrift (communication via Thrift Java server + Java Client or node.js client), maybe it will be useful for someone . But you can found more simple and better examples.
Torquebox supports JMS. The gem you specified torquebox-messaging allows for publishing and processing of HornetQ messages on the local JBoss AS server/cluster that the JRuby app is running in. I don't think it currently supports connecting to remote servers.
Using this functionality in your JRuby app you could then configure your Java app on another server to communicate with HornetQ running in the JBoss AS that the JRuby app is running on.
Alternatively you could always implement your own communication protocol or use another Java library - you have access to anything Java you want to run from JRuby.
You can use Web Services or JMS for that
Intro: I want to develop simple multiplayer Five in row (Gomoku). Front-end should be done using JavaScript, and back-end in Java.
Basically client and server should exchange pairs of integer numbers and game id. It's easy to do on client side with WebSockets, but...
Question: Is there simple way to process communication on server side, using Sockets and ServerSocket, without embedding Jetty or any other server?
Since Front-end is javascript it might run in a web browser. To communicate with the server most likely using http, then embedding Jetty and using dwr is the simplest way IMO.
If you intend to do such thing on a web project, have a look at the DWR project.
WebSockets browser support is poor at the moment.
If you're creating a Web application the mainstream solution for JS-Java communication is Ajax with some JS framework like jQuery or Dojo. It will not require any libs on the server side (unlike DWR) and also you don't need to put any JS stuff on your server if you use CDN.
I need to push events to web clients in a cross-browser manner (iPhone, iPad, Android, IE/FF/Chrome/etc.) from a Spring based Java server. I am using backbone.js on the client side.
To my best knowledge, I can either go with a Web socket only approach, or I can use something like socket.io.
What is the best practice for this issue, and which platform/frameworks should I use?
Thanks
Looks like you're interested in an AJAX Push engine. ICEPush (same group that makes ICEFaces) provides these capabilities, and works with a variety of server- and client-side frameworks. There is also APE.
You can have a look at Lightstreamer.
My company is currently using it to push real time financial data from a web server.
I suppose Grizzly or Netty may fit your needs. Don't have a real experience in that scope, unfortunately.
I'd recommend socket.io as you mentioned in your question, if you're doing browser based eventing from a remote host. Socket.io handles all the connection keep-alives and reconnections directly from javascript and has facilities for channeling messages to specific sessions (users). The real advantage comes from the two-way communication of WebSockets without all the boilerplate code of maintaining the connection.
You will need to do some digging for a java implementation thoughConsider running the server directly from V8.