which technologies to use for middleware server in .net?

I don't know whether this is a silly question! I searched the web with no useful hits. I am a dot net user (C#).I want to develop a Server, it may be called a middleware server (actually I am not sure), which does the following tasks, I have a server which cannot b开发者_JAVA技巧e modified and many clients that request the server and receive the results. I can modify the clients.Now I want to develop software that receives client requests,check if the server is busy or how many tasks are queued at the server, store the client requests to temporary database if server is busy,fetch requests queued in the temporary database and forward to the server and then receive the results and forward to to clients and the like.The questions are

1. which technologies are best to use while remaining in dotnet, WCF, Webservives, remoting, or other?

2. how complex is this task assuming that there are tasks like transaction handling, load balancing, logging, security checking mechanisms and the like?

3. what things should i read to do these task?

4. while searching I find such things as middleware in java but not in dotnet. what is the reason?

Short Answer: From the sounds if it, if you just want to buffer your server from overload, you can get away with handling the request asynchronously. WCF supports MSMQ natively. MSMQ supports DTC so messages can be placed and removed transactionally.

The larger topic of Middleware is quite a 'fuzzy' term (as are terms such as Transactions, ESB, etc). MS do have products in this space. This includes:

• Queing technologies (Message Oriented Middleware) MSMQ (Alternatives include IBM Websphere MQ, Rabbit MQ etc)
• XA / ACID / TP Monitors - Microsoft DTC
• EAI - Microsoft has BizTalk for integration (There are many other vendors here)
• ESB - Microsoft has BizTalk. You can also look at the MS Managed Service Engine (MSE) for service virtualization. This is defunct
• For RESTful integration, WebAPI
• BPM / BPEL - Again, MS have BizTalk. Can also include business level monitoring and reporting
• Operational aspects - as you've described - management, monitoring, load balancing, throttling, SLA agreements on services etc
• For Web Services (and WS Extensions), WCF. There are a large number of configuration options here which mostly abstract away the need to change code when between switching protocols.

And this is just scratching the surface :)

Middleware is a very broad term, you're specifically talking about a proxy:

http://en.wikipedia.org/wiki/Proxy_server

http://en.wikipedia.org/wiki/Proxy_pattern

Which is also a middleware, of course.

The other answers depend on what technologies you are using for client-server communication (Web services, REST, json, ...?), how complex is your server logic, and how many requests you have to handle, ...

The simplest thing that could possibly work in your scenario is a load balancer ( http://en.wikipedia.org/wiki/Load_balancing_(computing) ) that forwards requests to two or more servers, depending on the server load. Obviously that works only if you can replicate your server instances.

Putting a middleware that stores a queue if the server is busy could work, but nothing assures about the possibility to exceed the queue capacity of that proxy too, and there you go again...

For #1:

Please provide additional info about your task: 1. Rough estimate for amount of clients 5, 100, 10000, 1000000 2. Estimated size of the data which will go force and back between client and server 3. Where clients will work in Internet or Intranet? Any restrictions by security? 4. Client will be standalone application or web-application (like page or widget on the page)?

For #3:

If all what you mentioned in #2 must be implemented as part of the task, then I don't believe that you can just read some books and implement it. Or the result of implementation will be far from production requirements. I recommend to hire architect or outsource it to experienced team. Just for general information I can recommend to read - "Patterns of enterprise application architecture" By Martin Fowler. But just reading can't replace experience.

For #4: I believe there are middleware systems for .Net too. There are commercial middleware systems which work with Java, .Net & C++.

IMO Microsoft selected other approach then Java community. They provided frameworks which allow you to build what you call "middleware". First look into WCF & REST. The queue can be easy implement in the DB. If it's not enough look into WCF & MS MQ. If you do not like MS MQ look at Amazon SQS. If it's not enough look into BizTalk.

P.S. Java and .NET platforms are so huge that you can build what ever you want on both. It doesn't make sense to jump from .NET to Java or from Java to .Net just because you think that something is missed in the platform.

In .NET the recommended approach for a middleware server is to use Enterprise services which provides an .NET API over COM+.

COM+ provides all of the features you mention (in point 2) to .NET applications.

WCF supersedes Remoting but is all about interoperability. While it does provide security and transactional features, these are geared towards the communication between 2 endpoints, not your application objects.