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

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

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

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

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

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

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