Before you build a dual Web Services + Remoting interface to your application, I'd suggest you do some profiling. You may find that the speed difference between Remoting and Web Services is relatively minor for your application. They are two completely different stacks, and it's not obvious to me that one would always out perform the other (eg. SOAP/Xml encoding is larger than Binary, but the codegen approach the XmlSerializer takes for Web Services is probably much less CPU work than the reflection-based approach the BinaryFormatter takes for Remoting).
Microsoft keeps saying that using ASMX / WSE web services today is the best way to prepare for Indigo tomorrow, and that that transition path will be the easiest. I'd have to see an extremely compelling argument before I'd consider adding a remoting interface to my web service for performance reasons. Rick ----- Original Message ----- From: "Andy Smith" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, March 23, 2004 8:22 AM Subject: Re: Multiple Ports and Remoting > Yes, I see now. I was getting confused by the Remoting uri, thinking that > Remoting somehow resolved the endpoint within the machine. > > No, not IPC, I'm building a middle tier for a distributed architecture in a > large company. We have many internal apps, internal and external SOAP users. > Migrating from DCOM/VB6. > > But on the subject of IPC: what's the best way to have a service - say, an > order service to accept customer orders and insert into a db - to accept > calls both as a web service OR be called from another service on that box > (such as a fa�ade)? I certainly don't want to incur the overhead of calling > to another Web Service when I'm already on the same server (expensive XML > serialization, SOAP formatting). Should I create a separate assembly that > actually does the work that can be called from a Web Service AND/OR via > Remoting (tcp/binary) from another fa�ade on that same box? That means my > actual Web Service isn't doing anything except accepting the call, turning > around and calling this assembly. This seems to make sense, but I'm new to > Remoting so I'm looking for ideas. One thing that's complicating things for > me is that I'm very interested in Indigo from what I've seen, but it's all > based on web services, and I don't know if using this approach would make it > extremely difficult to migrate to it. > > Thanks. > > Andy Smith > > > -----Original Message----- > From: Moderated discussion of advanced .NET topics. > [mailto:[EMAIL PROTECTED] On Behalf Of Shawn A. Van Ness > Sent: Tuesday, March 23, 2004 12:53 AM > To: [EMAIL PROTECTED] > Subject: Re: [ADVANCED-DOTNET] Multiple Ports and Remoting > > > Is it only for that process? > > Yes, of course. Else, how else would your computer know what to do with an > incoming TCP/IP connection request for port 8080? Query all the processes > running on the machine to see which are interested? Pick one at random to > handle it? No, of course only one process can be allowed to listen on a > port at any one time. > > May we ask what your application is? Sounds like IPC... I strongly advise > against the use of TCP/IP for IPC, for a number of reasons. Foremost (aside > from a host of security issues, which may or may not apply in your case) is > what I suspect you're just running into -- the extremely limited space of > endpoints (port numbers) prevents us from declaring one at design-time -- > forces us to grab one at deployment- or run-time, and then "publish" it to > would-be clients, out of band, somehow. > > Of course, there are about a dozen possible ways to handle that (from > app.config to creative use of registry keys), but they're all about as much > trouble as just p/invoking the classic Win32 IPC mechanisms -- named-pipes, > postmessage, or shared-memory -- which'd give you a totally secure solution > with an ultra-wide space of endpoints, to boot. > > Cheers, > -Shawn > http://www.windojitsu.com/ > > > -----Original Message----- > From: Andy Smith [mailto:[EMAIL PROTECTED] > Sent: Monday, March 22, 2004 13:16 > Subject: Multiple Ports and Remoting > > When I do this: > > TcpServerChannel channel = new TcpServerChannel(8080); > > Is it only for that process? That is, can/should other processes on the same > machine also receive on 8080? Or does each process have to have its own > port? I'm going to have many processes on a single machine (eventually) and > I'm unclear on how this works. I get an error on my 2nd process when I try > to create a channel with the same port number, so I assume that a port is > for one machine/one process only, but I want to make sure I understand. > > Thanks. > > =================================== > This list is hosted by DevelopMentorR http://www.develop.com Some .NET > courses you may be interested in: > > NEW! Guerrilla ASP.NET, 17 May 2004, in Los Angeles > http://www.develop.com/courses/gaspdotnetls > > View archives and manage your subscription(s) at http://discuss.develop.com > > =================================== > This list is hosted by DevelopMentor. http://www.develop.com Some .NET > courses you may be interested in: > > NEW! Guerrilla ASP.NET, 17 May 2004, in Los Angeles > http://www.develop.com/courses/gaspdotnetls > > View archives and manage your subscription(s) at http://discuss.develop.com > > =================================== > This list is hosted by DevelopMentor� http://www.develop.com > Some .NET courses you may be interested in: > > NEW! Guerrilla ASP.NET, 17 May 2004, in Los Angeles > http://www.develop.com/courses/gaspdotnetls > > View archives and manage your subscription(s) at http://discuss.develop.com > =================================== This list is hosted by DevelopMentor� http://www.develop.com Some .NET courses you may be interested in: NEW! Guerrilla ASP.NET, 17 May 2004, in Los Angeles http://www.develop.com/courses/gaspdotnetls View archives and manage your subscription(s) at http://discuss.develop.com
