Architecture question
-
I'm about to write a C# application to, er, do stuff (not important). I'm going to provide request handlers that can take input from database tables, MSMQ and JMS queues (thank god for J#), Web service requests, HTTP requests, and maybe socket connections using a simple proprietary protocol or even a drop directory. Its admin interface will be ASP.NET pages. I know pretty well how to write the logic in a nice way to satisfy all the requests from different input. My main question right now is how to arrange the components. I think I'm going to write the main body of the application as a Windows service, which'll give the benefits of startup, shutdown and even power-management hooks, as well as easy administration. I obviously need IIS for the Web services and HTTP support, which is great because it allows me to delegate security responsibilities for that stuff to IIS and the Web applications, as well as the opportunity to spread the load. I figure the best thing to do is use a TCP/IP remoting channel with a binary formatter between the IIS applications and the Windows service, yes? (I've done some reading and practicing with remoting, but never used it in the real world.) Once I've done this, should I think about just making remoting another method of direct input into the Windows service? I mean, how valuable is it in general to provide access to something via remoting? I mostly see mention of it as a way to provide internal communication between components. -Jeff here, bloggy bloggy
-
I'm about to write a C# application to, er, do stuff (not important). I'm going to provide request handlers that can take input from database tables, MSMQ and JMS queues (thank god for J#), Web service requests, HTTP requests, and maybe socket connections using a simple proprietary protocol or even a drop directory. Its admin interface will be ASP.NET pages. I know pretty well how to write the logic in a nice way to satisfy all the requests from different input. My main question right now is how to arrange the components. I think I'm going to write the main body of the application as a Windows service, which'll give the benefits of startup, shutdown and even power-management hooks, as well as easy administration. I obviously need IIS for the Web services and HTTP support, which is great because it allows me to delegate security responsibilities for that stuff to IIS and the Web applications, as well as the opportunity to spread the load. I figure the best thing to do is use a TCP/IP remoting channel with a binary formatter between the IIS applications and the Windows service, yes? (I've done some reading and practicing with remoting, but never used it in the real world.) Once I've done this, should I think about just making remoting another method of direct input into the Windows service? I mean, how valuable is it in general to provide access to something via remoting? I mostly see mention of it as a way to provide internal communication between components. -Jeff here, bloggy bloggy
Using .NET Remoting to talk to a Windows Service is very common, and the whole concept of communication between some server object (in this case, an ASP.NET Web Service) is not uncommon at all. Before (and still) server objects talk to COM+ services, which provide a lot of nice features for (almost) free. As far as how ASP.NET talks to the back end, if you're not sure about Remoting perhaps consider using a provider pattern to make abstract calls to implementations: one could talk to .NET Remoting while another talks to another Web Service or directly to a database...whatever. Every since .NET 1.0 beta days when I realized how great the CTS was, I've been using a provider pattern for most of my bigger apps (including the solution I've architected here - though in a rush-to-market start-up I didn't have as much time as I needed, but will someday get around to revamping). Much of the .NET Framework already uses a provider pattern (.NET Remoting channels and sinks, System.Net authentication modules, etc., and ASP.NET stuff), and 2.0 will use it even more heavily (with great improvements).
Microsoft MVP, Visual C# My Articles
-
Using .NET Remoting to talk to a Windows Service is very common, and the whole concept of communication between some server object (in this case, an ASP.NET Web Service) is not uncommon at all. Before (and still) server objects talk to COM+ services, which provide a lot of nice features for (almost) free. As far as how ASP.NET talks to the back end, if you're not sure about Remoting perhaps consider using a provider pattern to make abstract calls to implementations: one could talk to .NET Remoting while another talks to another Web Service or directly to a database...whatever. Every since .NET 1.0 beta days when I realized how great the CTS was, I've been using a provider pattern for most of my bigger apps (including the solution I've architected here - though in a rush-to-market start-up I didn't have as much time as I needed, but will someday get around to revamping). Much of the .NET Framework already uses a provider pattern (.NET Remoting channels and sinks, System.Net authentication modules, etc., and ASP.NET stuff), and 2.0 will use it even more heavily (with great improvements).
Microsoft MVP, Visual C# My Articles
provider pattern That's a good name for it. That's what I'm used to doing, now. I create an interface for something that takes input, then make one implementation for every type. I do the same for the methods of output. Then, for things that need a synchronous response that depends on processing, I give the ability to associate a particular input method to a particular output method ("sink"). Each request carries context information, etc. Next I write the threading code, so that one thread is attached to each method of input. These threads read in requests (sometimes assigning them priorities; sometimes that's down the processing chain). Each request is dropped into an in-memory queue at this point, and winds up getting processed eventually. Any sensed admin requests are sent to the front of the queue. Sometimes I make the same thread that processes the request write the output, but when performance is important I usually dedicate a separate thread to each sink too, especially if the same response or result has to be written to more than one output. Since you bring it up, I have to say that the word "sink" to refer to output is awesome. I formed most of my personal naming preferences doing Java work, where everything in the API is "reader" and "writer" organized, with an occasional "sink" in there usually as the contribution of an old C coder! The word "sink" is now one of my favorite things about .NET. I really am a naming freak. So you're saying that I could make the ASP app front end another method of input besides remoting, an interesting suggestion. Whatever I do with this thing, though, I'm going to have to provide synchronous responses for both the ASP and Web service requests, so I'm concerned about performance; like, I wouldn't want to funnel HTTP requests through the Web service. I'll just have to try wading into the remoting stuff, I guess. I have zippo experience with COM+, although I've done some reading on it. I'm sure I'll have plenty of annoying questions in a week or so. :) -Jeff here, bloggy bloggy
-
provider pattern That's a good name for it. That's what I'm used to doing, now. I create an interface for something that takes input, then make one implementation for every type. I do the same for the methods of output. Then, for things that need a synchronous response that depends on processing, I give the ability to associate a particular input method to a particular output method ("sink"). Each request carries context information, etc. Next I write the threading code, so that one thread is attached to each method of input. These threads read in requests (sometimes assigning them priorities; sometimes that's down the processing chain). Each request is dropped into an in-memory queue at this point, and winds up getting processed eventually. Any sensed admin requests are sent to the front of the queue. Sometimes I make the same thread that processes the request write the output, but when performance is important I usually dedicate a separate thread to each sink too, especially if the same response or result has to be written to more than one output. Since you bring it up, I have to say that the word "sink" to refer to output is awesome. I formed most of my personal naming preferences doing Java work, where everything in the API is "reader" and "writer" organized, with an occasional "sink" in there usually as the contribution of an old C coder! The word "sink" is now one of my favorite things about .NET. I really am a naming freak. So you're saying that I could make the ASP app front end another method of input besides remoting, an interesting suggestion. Whatever I do with this thing, though, I'm going to have to provide synchronous responses for both the ASP and Web service requests, so I'm concerned about performance; like, I wouldn't want to funnel HTTP requests through the Web service. I'll just have to try wading into the remoting stuff, I guess. I have zippo experience with COM+, although I've done some reading on it. I'm sure I'll have plenty of annoying questions in a week or so. :) -Jeff here, bloggy bloggy
Each request to the Web Service (and .NET Remoting objects when hosted in IIS) get their own
HttpContext, which runs in a separate thread of execution. While you may call a method synchronously in your client application, the web application uses a free-threaded model to execute it.Microsoft MVP, Visual C# My Articles
-
Each request to the Web Service (and .NET Remoting objects when hosted in IIS) get their own
HttpContext, which runs in a separate thread of execution. While you may call a method synchronously in your client application, the web application uses a free-threaded model to execute it.Microsoft MVP, Visual C# My Articles
Mmhmm, that's good to know from a performance standpoint. So what you're saying, I think, is that Web services aren't plain awful on performance from a threading perspective, which I'm prepared to believe. I'm mostly worried about making the application consume too much of the available network resources, and I also figure that the encoding/decoding overhead of a binary formatter is going to be less than that of XML serialization and deserialization. I was thinking a while back about writing a lightweight Web services provider that could be used outside of IIS, just to provide an easy point of entry into things like Windows services. I wouldn't be able to easily (read as ever) provide all of the built-in security functionality of Microsoft's Web services implementation, but I could make it easy to cobble together communication between your components in a snap. I don't know, maybe I'm overafraid of this remoting stuff. It seems pretty similar to Java RMI, which wasn't all that complicated. -Jeff here, bloggy bloggy
-
Mmhmm, that's good to know from a performance standpoint. So what you're saying, I think, is that Web services aren't plain awful on performance from a threading perspective, which I'm prepared to believe. I'm mostly worried about making the application consume too much of the available network resources, and I also figure that the encoding/decoding overhead of a binary formatter is going to be less than that of XML serialization and deserialization. I was thinking a while back about writing a lightweight Web services provider that could be used outside of IIS, just to provide an easy point of entry into things like Windows services. I wouldn't be able to easily (read as ever) provide all of the built-in security functionality of Microsoft's Web services implementation, but I could make it easy to cobble together communication between your components in a snap. I don't know, maybe I'm overafraid of this remoting stuff. It seems pretty similar to Java RMI, which wasn't all that complicated. -Jeff here, bloggy bloggy
It's okay to be afraid of Remoting at first, but once you get the hang of it it's great! There you can use a
BinaryFormatterwhich does improve performance (even just serializing/deserializing, not to mention the bandwidth required).Microsoft MVP, Visual C# My Articles