Real-time multi-user Flex/Java app... sockets

[d000hg]

Thinking of building a little tool for multi-user real-time interaction. Partly as something to show as a product on my website, partly to expand skills for the CV if I go back to contracting, partly to actually help my team communicate remotely.

Anyway, it's essentially a tool where users can work on a shared space and see what each other are doing. Server side will be Java, client-side probably Flex rather than try and do real-time prettiness in HTML.

It could be done purely through HTTP requests, but that's clunky for responsiveness and means the client has to keep polling the server. So I am thinking for the real-time parts, I should use sockets as provided in Flash 9.

My current confusion is over how I make a Java-server app which can both maintain socket connections, and provide more standard ways to communicate e.g login, some HTML pages to see status, etc.

[OrangeHopper]

Threads.

Accept connection and handle individual client sessions with a thread per connection.

You then have a management thread accepting your management requests from your browser on a different port. This can produce your management pages and handle your management commands.

Doesn't matter what language you implement this in. Same architecture applies to all. There is probably a "pattern" to describe this but I'm old school and don't deal in patterns.

[TroubleAtMill]

Both Java and Flex can talk to each at the low socket level. Linky Slinky

My current confusion is over how I make a Java-server app which can both maintain socket connections, and provide more standard ways to communicate e.g login, some HTML pages to see status, etc.

There's nothing to stop you from writing a servlet that spawns a thread to handle the socket connection. (IIRC, only EJB containers prevent you from doing this.) If the app server is able to, you may want to use it's ability to create network 'listeners'. For example, Tomcat has its 'Connector' architecture. One of which is its AJP13 connector to handle requests from an Apache webserver.

So, a simple architecture is to have a DB that is visible to both an admin web app (for login and status) and the socket-handling application.

HTH.

[VectraMan]

If you're using a different port (i.e. not http) that might cause you some firewall issues.

I forget what it was called but somebody here was talking about a technology that was half way between a polling all the time Ajax connection, and a permanent socket like connection, i.e. something that would cause the web server to keep the HTTP connection open for a certain time, but not indefinitely.

Flash has an XMLSocket class that could probably talk to that.

Nick Fitz will appear any minute and tell us the right way.

[minestrone]

Both Java and Flex can talk to each at the low socket level. Linky Slinky

There's nothing to stop you from writing a servlet that spawns a thread to handle the socket connection. (IIRC, only EJB containers prevent you from doing this.) If the app server is able to, you may want to use it's ability to create network 'listeners'. For example, Tomcat has its 'Connector' architecture. One of which is its AJP13 connector to handle requests from an Apache webserver.

So, a simple architecture is to have a DB that is visible to both an admin web app (for login and status) and the socket-handling application.

HTH.

Banned in the spec but every fecker does it, including me.

[d000hg]

Hmm, let me simplify a little. I'm aware that Flash can use sockets directly but let's forget the client part totally.

Now the question is simply, how do you have a Java web-server (probably Spring) which can maintain open socket connections to multiple clients as well as doing more traditional HTTPRequest/response handling through servlet/JSP type architecture?

I guess my confusion is partly over the fact a servlet-based app, especially using SpringMVC, has no entry-point in the traditional sense... no main() in which you can set up non-webserver functionality.

I could have two distinct apps, a webserver and a socket app... but that's not ideal. When sockets are not available, it's likely a web-service or AJAX might be used as a fall-back so conceptually the same app should provide servlet, web-service and socket based communications for different clients.

[minestrone]

At various places in the JEE spec it states that creating threads/controlling sockets in a J2EE container is not allowed.

As TroubleAtMill says you can spawn threads in servlets but as the container controls the servlet life cycle it may choose to destroy it and initialise it again which would very likely create another thread.

I would be very hesitant to create a thread that controls sockets in that way, you should really create 2 applications.

Flex has Blaze DS which pushes real time stuff back to multiple clients, I would be thinking about using that rather than mucking about with sockets.

[TroubleAtMill]

Live on the edge!

No, ministrone is right. Spawning new threads from a servlet app is a Bad Idea (TM).

Like I said, a better approach is to take advantage of any feature of the app engine that allows 'services' to be run. The entry-point (i.e. where you start a Thread to listen for network connections) would be defined by the app engine's API.

But I agree it's also worth learning BlazeDS. I've found build apps quite easy in Flex and integrating with a Java back-end with BlazeDS relatively straightforward - especially as there's now a dedicated Spring project.

[d000hg]

Blaze is an implementation allowing Flex RemoteObject interaction with Java, correct?

[DimPrawn]

This is a piece of cake in Silverlight and WCF.

You Java guys.