The Old Joel on Software Forum: Part 4 (of 5)

Design Advice

I am beginning to do research for a project that requires a highly available Windows service that can handle many requests, pass out jobs to other threads or processes, and then send the results back to the client when the jobs are finished.

The client in this case is also a server because we need to be able to push data down to the users based on events that happen on the back end (like a job finishing, or a message arriving for them).

Furthermore, the service must act as a proxy to another application server in the back-office which can also trigger events that must be pushed back down to the client.

Jobs are things like a database operation or opening a file and running a script.

So, there are the basic specs. We are using SQL Server for the database and Windows 2000+ is the target platform. If you guys have an opinion on what technologies to consider, some examples to look at, or books to read, that would be great. For instance, should I start brushing up on COM+ and MSMQ? Should I try Winsock for all the connections or use third party party control like Dart or SocketsvrQ?

Coding can/will be done in a mixture of any of the current MS languages.

Wayne
Friday, February 13, 2004

I'd suggest MSMQ style technology, but I've no experience experience with the third party controls you mention.

Writing a server like this using Winsock might be a fun project, but unless you have a lot of resources it adds a lot of overhead. Custom built network stacks are hard to test when you start adding in asynchronous operations, network failures and heavy load.

There is a reason products like MSMQ have hundreds of man years invested in them!

Another option may be ASP.NET web services running inside IIS.

Rob Walker
Friday, February 13, 2004

COM+ is fine. However I have a really bad experience with MSMQ when used for calling COM+ components (queued call). We are using it in our application to start a process from an ASP page. The process is implemented as VB component and can take 10-15 minutes. I chose queued COM+ calls through MSMQ because it seemed that was the right solution. And when it works, it works just fine. However, there wasn’t a single instance when MSMQ would just run the first time. There are always some configuration problems, weird messages in the event log (ranging from more or less descriptive ‘COM+ - Invalid transaction use’ to things like ‘assert failed in some_msmq_suirce_file.c, line 574’). Not pretty.

Alexander Chalucov (http://www.alexlechuck.com)
Friday, February 13, 2004

I am wondering if MSMQ is worth the effort of depending on it...

I also want to do some testing with load simulation. I'd like something that will let me script requests/responses to/from any port.

The closest free thing that I found so far was the java application LoadSim http://www.openware.org/loadsim/loadsim_userguide.html.

Wayne
Friday, February 13, 2004

MSMQ is great (I have seen disasters, but hey there's exceptions to everything), and it's probably the first job distribution system a microsoft platform programmer can get his hands on.

Li-fan Chen
Saturday, February 14, 2004

I have a slightly different take on this. IMO, you're describing a classic "servent" in peer-to-peer parlance: a combination client and server.

So why make the technology so tied in with MSFT? I'm a big Visual C++ fan, but would see no reason to implement a servent using MSFT-only stuff like MSMQ and/or COM+. Especially when all COM-related technologies appear to be getting the 'brush off' from Microsoft in favor of more open approaches to interoperability. Plus - you may want to move this to an HP/UX, Linux, Solaris or some other enterprise server at some point.

Thus, consider using a small-footprint server that not only accept requests in standard forms (e.g., HTTP over TCP) but can issue requests based upon schedule or some other criteria. And it can act as a proxy where needed. Use standards wherever possible... I think your investment in time and code will last longer that way.

dir at badblue dot com
Saturday, February 14, 2004

In case you want to consider .NET remoting, these use cases might be helpful (I have no affiliation with the author):

http://www.ingorammer.com/RemotingFAQ/RemotingUseCases.html

coresi
Saturday, February 14, 2004

I think one of the most important thing is whatever you use do not try to reinvent the wheel, and try to build on mature existing technologies.

other than that I have no advice for you.

Saturday, February 14, 2004