Scott Stewart

Has .Net Remoting become an exercise in academia?

 Let me start by stating that in general, I’m fan of .Net Remoting. One of the first diversions from the basics of .Net that I started playing with in the early days of .Net was Remoting. In fact, about 2 years ago (man time flies), I wrote an article on DNJ about Working With Events Over Remoting. At the time, I read all I could get my hands on by the ultimate Remoting guru, Ingo. However, I was working on an application that required the ability to callback from a server to a number of clients on the same network, and really couldn’t find exactly what I was looking for; VB code that could RaiseEvents from Server to n-Clients. So I gathered up all the knowledge I could from Ingo, did a little additional research, and then worked out the kinks of my particular solution. Shortly afterwards, I wrote the article on DNJ in case anybody else was looking to do something similar. At the time, Remoting seemed to be all the rage for distributed computing in .Net.

Articles were being written on MSDN like this one: Performance Comparison: .NET Remoting vs. ASP.NET Web Services. Man, I was convinced that .Net Remoting via a Windows Service was the way to go. I mean it was hard to argue with pictures like these from that article:

Basically, the two colors we were looking at back then were the Yellow (Remoting via a Windows Service over TCP with Binary) versus the Pink ASMX. There were more pictures that demonstrated various payloads and the corresponding metrics. The results were similar. There were some cases where the differences were less significant, but Remoting over TCP Binary was the winner when it came to pure performance metric comparisons.

I really don’t remember too much talk at all, at the time about continuing to use ES solely for the purpose of distributed communications. There was still talk about continuing to use ES where necessary for the purpose of DTC, but not a lot of talk about it for the purpose of DCOM or COM+ stuff (partly just because of the desire to move on from some of the COM luggage.) The two players really being talked about and discussed (for distributed computing) were Remoting and Asp.Net Web Services.

The performance statistics were definitely in Remoting’s favor. Full type fidelity for true distributed object architectures was in Remoting’s favor. But what’s happened over the past few years? Most .Net projects today, which involve cross-process communications, are being specifically guided away from Remoting and towards Web Services.

I might be wrong, but I don’t think you would see this comment coming from MSDN today: “Though both the .NET Remoting infrastructure and ASP.NET Web services can implement inter-process communication, each is designed with a particular level of expertise and flexibility in mind to benefit a different target audience. If your application needs interoperability with other platforms or operating systems, you would be better off using ASP.NET Web services, as they are more flexible in that they support SOAP section 5 and Document/Literal. On the other hand, use .NET Remoting when you need the richer object-oriented programming model.” - Performance Comparison: .NET Remoting vs. ASP.NET Web Services It almost seems like we must all be writing for interoperability with other platforms and aren't looking for richer object-oriented programming models today?

Since writing the “Working With Events Over Remoting” article, I’ve gotten a number of emails thanking me for the article, and perhaps looking for some additional Remoting help. I really don’t fancy myself a Remoting expert, but have generally been able to help out with most questions. Oddly enough, I’ve noticed a strange similarity in a majority of the emails that I have gotten over the past few years; most of the email addresses end with .edu? It seems that most people that are searching for help on how to do something in regards to Remoting today (at least ones that happen to email me) come from people involved with academia, and not developers writing code for manufacturing, banking, sales, health care, state work or any of the other millions of professional business segments. Why would Remoting still be popular amongst the academic community, but not so much with the professional development community?

Maybe we got a little too aggressive with our Remoting projects? Maybe we got ourselves in trouble trying to do callbacks over various network hops and NATs that wrecked havoc with our end points? Maybe, we didn’t stick with the suggested HTTP channel over IIS, and had to implement additional custom security over TCP? Just because we could, doesn’t mean that it was the best idea. But hey, it was a shiny new car and we all wanted to take it out for a test drive. And for the most part, it’s technically been an awesome vehicle.

However, it doesn’t seem to be the vehicle of choice anymore, even for inter-process or cross-process communications that require no interoperability with other platforms. Two parts of a single .Net application are now being built with Asp.Net Web Services between them. Did we throw the baby out with the bathwater? Could we have pulled in the reins a little on our new sports car? Maybe we could have given up the super fast TCP Binary Windows Service, wide open with no security? Maybe we could have settled sooner for promoting how easy Remoting over HTTP with Binary from IIS really was to configure and use? Is it too late?

Remoting in .Net 2.0 will receive a few enhancements that should help some of the bleeding; better security, a new IPC channel for same machine communications, and some versioning tolerance (I blogged about this here) But will it ever regain the popularity it deserves? Unfortunately, I don’t think it will under the guise of “Remoting”.Maybe Indigo has something up its sleeve to help? I really don’t know enough about it yet to make any assumptions.

I know what I want; the ability to have full object type fidelity between two ends of a cross process communication with the ability to move user/security context and decent performance, all with the sex appeal of Web Services. Remoting in .Net 2.0 looks like it can bring me the technical part. Maybe Indigo can somehow bring the sex appeal? Maybe somehow we can start convincing (and proving to) the IT managers and developers of manufacturing, banking, sales, health care, state work or any of the other millions of professional business segments of the benefits of Remoting, and not let it become just an exercise in Academia.

Ado.Net and System.Transactions

Rocky at the PhillyDotNet user group

Well, I did in deed make the trek to Philly .Net user group on Wednesday. I thought I gave myself plenty of time, but it’s amazing what a inch or two of snow can do for traffic back ups. The last 30 miles of the trip took me almost 3 hours! I planed on getting down in time to grab a bite to eat and be there for the 5:30 PM start time. I ended up getting there about 15 minutes into Rocky’s scheduled 7:00 PM start! This sucked.

The venue was pretty cool (once I made it inside!) I wasn’t exactly sure where in the building the conference center was going to be located, so I drove past the first entrance to the parking garage in hopes to get a glimpse of a sign or something that specifically said “here it is”, thinking that I could just drive back to the garage entrance I passed if it was the correct one. Well a few hundred feet after going past the entrance to the garage (remember, it was snowing, the wipers where going, etc), I felt a little bump in the road under the snow as I made it up onto a walkway from the garage to the conference center doorway. And low and behold, as I sit on a walkway in my Chevy Suburban (thinking maybe I'm in a place I shouldn't be), I’m looking in through the front doors at Rocky standing there speaking, arms up in the air like a giant (physically and metaphysically) with two huge screens behind him displaying “Data != Objects”. I knew I had arrived ;-)

The session was a lot of fun. I’ve been a Rocky fan for years, so there was really nothing new I heard him say or do here. But, it was cool to see and here him speak it all in person. There was a sense of humor side, that you don’t always realize when your reading things here, or here or here. For example, “…the UI Guy’s job just sucks anyway…”, well I guess you had to understand the context and hear it in person to get the chuckle.

So, the driving sucked, I spent way too much time in my car, but it was real cool to meet Rocky. Don’t know if I’ll try to make the trek down again, unless there is some pretty compelling reason. I guess I’ll stick to more local user group meetings, and lobby that we can get some giants to come by too.

I guess it really isn't quite dead* yet…

I guess it really isn't quite dead* yet…

A real good show on MSDN TV called “What's New in .NET Remoting for .NET Framework 2.0”

A quick summery:

• IPC for same box cross process remoting (bypass the tcp stack by using named pipes for same box communication)

• Secure TCP channel security with SSPI (signed encrypted serialized data, identity and impersonation – real cool)

• Version tolerant serialization

* I know it isn't dead and it isn't going away. Rich told us this almost a year ago. However, it is nice to see actual talk and hype coming from MSDN on remoting.

Learn some swimming basics before jumping in the thread.pool

One of the good things .net has brought to vb programmers is the ability to very easily do some asynchronous work using the ThreadPool. One of the bad thing .net has brought to vb programmers is the ability to very easily do some asynchronous work using the ThreadPool – huh?

I was reviewing some code recently that was written by somebody that must have been doing some of their first multi-threaded work. .Net has made this type of work pretty easy to pull off. Unfortunately, it can be so easy to jump in this pool (pun intended), that it can be tempting to do so before you learn to swim. There are some basics swimming lessons that should be required before entering the water:

• Know what a critical section is, what a mutex is, and why you need to worry about this; in VB you should be familiar with the words Synclock and Monitor.
• Know what a deadlock is and how it can be prevented. Be particularly conscience of the type of work you are doing within an asynchronous thread handler. You should not wait on the results of additional asynchronous work within an asynchronous handler; be sure to know why this.
• Don’t explicitly share a DB connection between threads. Explicitly open and close short-lived db connections, and let ADO.net take care of the connection pooling for you.

The list of basics really goes on further, but these seem to be some common things I’ve seen people miss when first starting to work with the thread pool. In fact, all three of these were missed/abused in the code I mentioned that I was recently reviewing.

A good MSDN article to get you started with some of the basics can be found here.

heading to Philly on Wednesday

more on Database as a service...

Maybe Mr. Lhotka wasn't all that far off the mark when he wrote this over here last month, and perhaps there was less “tongue in cheek” then most assumed.

I came across this article on InfoWorld today titled “Desperately seeking SOA”. The following paragraph from the InfoWorld article seemed to just conjure up spirits of the fallacy article from last month:

 “The database community is also heading toward SOA. Plans are afoot to enable IBM DB2, Microsoft SQL Server 2005, Oracle 10g, Sybase (Profile, Products, Articles) ASE, and other platforms to participate actively in Web services-based SOA activities as first-class citizens -- even without the use of application servers. This will have profound implications for the design and management of widely distributed n-tiered applications because, in effect, hierarchical tiers will become horizontal peers.”