PIAB and WCF Article Published on MSDN Magazine

Posted by Hugh Ang at 1/13/2008 11:27:00 AM

The article that I have coauthored with my Avanade colleague David San Filippo is now published in the February issue of MSDN magazine. If you have subscribed to MSDN, you should have received it in your mail box by now. The online link is here. Basically the article details how to integrate PIAB into WCF via .NET configuration or attribute so developers would not have to write code to apply the goodness of PIAB to WCF.

It's been an absolutely wonderful experience working with MSDN editors, Howard Dierking, Nancy Michell and Debra Kelly so I'd like to extend a big "thank you" to them from here. My colleague David is one of the smartest developers I have worked with; it only took a few weekends for us to come up with a draft of this article after the brainstorming back in last August.

7 comments:

Hugh Ang said...

I have received an email today from David who informed me that Tom Hollander from the Microsoft p&p group had just posted an interesting blog about our article here. Evidently Tom had posted a blog that rather uses IOperationInvoker to integrate PIAB at WCF boundaries. The problem Tom had experienced with both his and our approaches had to do with three different services in the same IIS application pool. David and I are contacting Tom right now to see if we can get the source code Tom was using to hopefully repro the problem by ourselves. But my hunch at this point is that the problem is related to the use of obtaining the .NET remoting transparent proxy as the PIAB proxy, which is the default PIAB implementation. I wonder if CLR has certain optimization by sharing certain data structure across appdomains (different IIS apps) inside the same Win32 process (the same application pool); and the use of remoting proxy has triggered the problem. Good news is that the problem happens only when services are shared in the same process. We will keep you updated. And please share your findings as well.

Anonymous said...

PIAB is a great idea. However, I'm wondering if this is the best approach instead of using Windows Workflow (WF). WF, like the PIAB, allows for technology-related aspects to be separated from the business logic using local services, also known as data exchange services. What do you think?

Hugh Ang said...

To the last comment:

WF is the framework designed to handle business processes. A typical windows workflow contains activities, which are composed of events and code that are closely related to the business domain. So the intention of WF is not the same as PIAB. The data exchange service is for windows workflow to interface/communicate with the hosting application. I don't think it is meant for AOP.

Hope this clears it up for you.

Anonymous said...

This is a great article - thank you!

I was wondering if you figured out the problem that Tom Hollander was describing in his blog. I think we are experiencing a similar thing in production only (?!) and am hoping to get some ideas as to where to look for solutions. Our services are hosted in Windows Services and communicate with the front end via named pipes. I don't want to paste event logs here but if you get curious you can take a look at the samples I put out on codeplex.

Any comments and suggestions will be highly appreciated.

Val

Anonymous said...

Well, it turned out that we'd missed an important point in the PIAB documentation:

"The application block reuses handler instances in different pipelines to minimize the number of objects it must create. Therefore, handlers should not store any per-call state in member variables. In multi-threaded applications, the action of multiple calls passing through the same handler instance is likely to corrupt the internal state."

Making our handlers thread safe solved our problem. Again: thanks for the great solution.

Val

Anonymous said...

What is the status of PIAB these days?

Hugh Ang said...

To the last comment, PIAB is Microsoft p&p's implementation of AOP (Aspect Oriented Programming) and will be relevant and stay. Take a look at the latest Entlib 5.0 Beta 1 change log. Unless you want to build your own interception mechanism, you should still use PIAB.