Interview with Ingo Rammer

Interview with Ingo Rammer

ngo is an independent consultant, developer, author, and trainer based in Vienna, Austria. His books “Advanced .NET Remoting” and “Advanced .NET Remoting in VB.NET” were published by Apress in 2002. In his day-to-day work, he focuses mainly on the architecture of .NET applications, and works with several companies in the telecommunication and software industry. You can reach him at

Q: Ingo, today you are one of the most regarded international gurus on .NET Remoting. When did you hear about .NET for the first time? Did you focus on Remoting immediately? How quickly did you understand Remoting’s potential features?

I started out with .NET when it was still dubbed NGWS (Next Generation Windows Services) – I guess this was some time before beta 1. I however didn’t realize its massive Remoting capabilities until I listened to a talk at a German developer conference. This talk mentioned the extensibility model and I decided right away that I just had to write a book about Remoting, because this technology was absolutely everything I ever wanted from DCOM or Java RMI. So one could say that I grasped the important features and the potential in about 5 minutes at a conference talk 😉

Q: Let’s talk about your book. It is the first one ever written about Remoting. Despite this, it’s probably the best one. Can you tell us how the book was born?

That’s a funny story. Right after the talk mentioned above, Dan Appleman did another talk on Remoting at the same conference. He concluded his talk with “well, as said before, there is no documentation on Remoting, and as you probably know, I’m co-founder of a publishing house. So if anybody wants to write a book about it …” at which point I stood up – right in his talk –, raised my hand, and promised him publicly that I’ll do it. We signed the contract seven days later.

Q: How did you life change after publishing the book?

Turned around 180 degrees. Actually, if one likes to get around and speak at conferences and events in a number of cities in various countries, I can only recommend writing a book.

Q: Your site has a place among the favourite links of every Remoting programmer (and not only). Did you decide to open the site while you were writing the book or after? Are you satisfied with it?

Thanks for your kind words! I opened this page to channel my thoughts while still working (in secrecy) on the book. I really wanted to get some samples and snippets out to the developer community. At the same time I also took part in Microsoft’s newsgroups to listen in on the other developer’s issues with Remoting so that I can cover them in detail in the book. I guess both, the newsgroup participation and took a large part in helping me to raise the quality of my books.

Q: What do you like most about Remoting?

The architecture with its layers of extensibility. It allows the creation of some great re-usable components when combined with the .NET framework’s custom attributes and reflection.

Q: What do you think could be improved or is missing in Remoting?

I think that some sort of support provided by Visual Studio is absolutely missing. Without it, everybody has to write the configuration files on his own, etc.

Q: Are there relevant changes in Remoting with the .NET Framework 1.1?

The most obvious one is the change in security during serialization. That is, if you want to pass objects by reference or pass private members of objects, you have to specify a flag in a configuration file – else you’ll get a security exception. That’s a very good thing, but unfortunately, it will appear to break a lot of apps which has been written for the 1.0 framework – just don’t forget to add this configuration setting!

Q: Speaking about security, .NET remoting doesn’t currently support any built-in security feature. The only “workaround” is to host remoting components in IIS. Do you know if and when the situation is going to change about this? How can this fact influence the adoption of Remoting?

Actually, that’s not really a workaround – Remoting simply uses the transport level protocol’s means of security. That’s actually a very sane design decision – and the very same which is true for ASP.NET web services as well. However, there is also already a security implementation for arbitrary remoting channels (i.e. the TcpChannel) available at MSDN.

Q: Java programmers are encouraged to put their large scale applications’ business logic in Session EJBs, which are a kind of remote objects: this is meant to achieve strong separation, even physical, from the presentation layer, which is often the web tier (Servlets & JSPs) but could be also (at the same time) a desktop fat client. Could it be a good practice for ASP.NET programmers to move business logic from their pages to Remote servers, using code behind only as a glue, when scalability is an issue?

Actually, a number of people in the Java space discourage the use of EJB session beans because of their massive performance effects. I personally know about a number of high-load Java sites which explicitly removed EJBs after performance tests.

I also truly believe that it’s easier and better to scale as soon as possible – in .NET terms this means to scale the ASP.NET layer together with the in-proc business logic. Hey, ASP.NET session state rocks when compared to classic ASP.

Q: In you opinion, how does the experience on technologies such as DCOM or CORBA, RMI or EJB help a programmer to understand and use Remoting?

Knowledge of DCOM, CORBA or RMI can definitely help – it’s distributed applications after all. EJB knowledge won’t be of too much help because EJB is basically only a service layer, whereas Remoting is a communication layer (like RMI or IIOP which is used for EJBs). Apart from this, it’s always easier to learn a new technology when you can compare it with an older one. This way, you can ask questions like “How does Remoting solve this-or-that problem I had with DCOM?”.

Q: Before Remoting, which languages/technologies did you use?

I started my commercial career with – don’t laugh – Perl on Linux in 1995.
About a year or two later, I switched to VB 5 and 6 which I used extensively for about 5 years. I also spent some time with The Dark Side, working with Java for about one or two years before the first pre-beta versions of .NET came along. Along the way, I used the respective distributed application protocols (DCOM and RMI) and also worked with a number of Microsoft back-end server technology (SQL Server, MSMQ, Exchange, …).

Q: Many people tried to use remoting to develop peer-to-peer communication infrastructures. Do you think remoting can play a role in this field or Winsock programming is still a better option?

As always: it depends. I however somehow think that using sockets is better for this kind of application, because – at least with the built in TcpChannel and HttpChannel – there’s no support for bidirectional communication over a single connection. Remoting would always require a different “reverse path” connection between server and client which is simply not possible with firewalls, proxies and NATs in between.

Q: .NET Remoting is probably one of the easiest technologies that enable distributed computing, making it approachable also to not-so-experienced programmers. Do you think that widespread adoption of Remoting in everyday programming will raise new network security troubles?

Hopefully not. It is however in the responsibility of every programmer to host the objects in IIS together with HTTP security. Remoting just gives you the possibilities – but power also brings the need for responsibility. Every developer has to work responsible and take care of these issues.

Q: Describe an Ingo Rammer’s typical day.

As I spend roughly 50% of my time on the road, there are actually two different kinds of “Ingo Rammer”-days: abroad and at home. Abroad basically means that I provide on-location services to a client, or that I speak at a conference or event. This also means living in a hotel – with all the associated benefits and disadvantages. These days are usually pretty dense: getting up early, working at the customer’s, back to hotel, working on some articles or samples until late at night, etc.

The days at home however are pretty relaxed on the other hand. I usually get up at around eight, read email, weblogs and articles until around nine or ten at which time I’ll have breakfast with Katja. After eating, it’s back to work, which usually means digging around in some new technology, writing articles, producing conference sessions or doing some real development work. I try to reduce my work to a maximum of working until 8:00 pm. I however only succeed about three or four days a week – the rest of the time it’s basically midnight 😉

Q: How many email messages do you receive every day?

Discounting spam (~30 a day) and mailing list messages (~ 400 to 500 a day) I receive about 20 to 30 emails a day. Most of the time, it’s still manageable but unfortunately, I’m not always able to respond to questions in a timely manner. Especially after conferences, when I’ve been disconnected for seven days and several hundred of emails sitting in my inbox.

Q: Have you ever been in Italy?

Absolutely, yes. I’ve been there a number of times on vacation and even did a talk about .NET Remoting at the University of Milan in June 2002. I’m really looking forward to returning there in the future. Let me tell you a secret: I drank coffee in roughly 20 states, but nobody makes espresso as good as the Italians do.

Q: In conclusion, what can you suggest to our readers about building effective Remoting applications?

Don’t use SoapSuds. Define interface and access your remote components based on these interfaces. If you need 100% scalability, use SingleCall SAOs, and avoid CAOs and events. Host in IIS with the binary formatter to provide for the best match in security, scalability and performance.


About Our Editorial Process

At DevX, we’re dedicated to tech entrepreneurship. Our team closely follows industry shifts, new products, AI breakthroughs, technology trends, and funding announcements. Articles undergo thorough editing to ensure accuracy and clarity, reflecting DevX’s style and supporting entrepreneurs in the tech sphere.

See our full editorial policy.

About Our Journalist