Reply to: Real-time multi-user Flex/Java app... sockets

[DimPrawn]

Flex makes the socket thing very easy on the client side; how do sockets fit into the WCF framework? And how do you integrate WCF & ASP.net into a single app? I don't plan to go the MS route, but it's always interesting to learn for the future.

I've no idea, but it's .NET, so probably just drag and drop something and you're done.

[Joe Bloque]

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.

Spawning threads from a servlet is not exactly uncommon as in org.apache.axis2.soapmonitor.servlet.SOAPMonitorService.

In the init() method of the servlet, it starts a ServerSocket thread which 'listens' for client connections. When a new client connection arrives it creates another thread to handle this client connection.

You still have flexibility to handle doXXX() methods for normal HttpRequest processing (probably using the ServerSocket object).

When the servlet container is shut down, the destroy() method cleans up the ServerSocket and Client connection threads.

Essentilly non-webserver functionality is handled by init() and normal request procesing by doXXX() all managed by a single servlet.

Whether this idiom can be used for production level applications is a moot point.

[d000hg]

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

Only problem then is don't they have to 'communicate' through a DB which is hardly the best thing performance-wise? Or is there a neat way to let two apps communicate efficiently? I mean if both apps are running on the same JVM instance they can do this, but that seems just as much a hack as spawning threads from a servlet.

[d000hg]

This is a piece of cake in Silverlight and WCF.

Flex makes the socket thing very easy on the client side; how do sockets fit into the WCF framework? And how do you integrate WCF & ASP.net into a single app? I don't plan to go the MS route, but it's always interesting to learn for the future.

[DimPrawn]

Yes, I've heard that networking stuff is really easy with MS technologies

[NickFitz]

This is a piece of cake in Silverlight and WCF.

Yes, I've heard that networking stuff is really easy with MS technologies

[DimPrawn]

This is a piece of cake in Silverlight and WCF.

You Java guys.

[d000hg]

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

[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.

[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.

[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]

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.

[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.

[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.

[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.