Enterprise Library 5.0 Released

Erwyn van der Meer — Wed, 21 Apr 2010 09:22:00 GMT

The Microsoft Enterprise Library has always been one of the most popular things to come out of the patterns & practices team. Yesterday p&p reached a major milestone by releasing version 5.0 of EntLib.

The improvements are too numerous to sum up here, but let me mention one: this release has full .NET 3.5 SP1 and .NET 4 compatibility and works great from both Visual Studio 2008 SP1 and Visual Studio 2010 RTM.

Full details can be found in Grigori Melnik’s blog post on this release. Or you can go straight to the download page or the documentation.

Similarity between EntLib 3.0 Policy Injection Application Block and EDRA

Erwyn van der Meer — Sun, 04 Mar 2007 06:03:00 GMT

As announced on Tom Hollander's blog, the Microsoft Enterprise Library 3.0 will include a new application block: the Policy Injection Application Block.

Enterprise Development Reference Architecture (EDRA)

Edward and me noticed a striking similarity with an earlier effort by Microsoft Patterns and Practices. For some other people who have been following the P&P guidance for some years now, this similarity didn't go unnoticed as well. For example in the post: Can anyone say Shadowfax?

"Shadowfax" was the codename for the Enterprise Development Reference Architecture (EDRA) released by Microsoft in 2004.

One of the important goals for EDRA was the separation of business logic from cross cutting concerns in enterprise applications. This was implemented by providing a pipeline of pre- and posthandlers that could be inserted declaratively using configuration in XML format. Messages would pass through this pipeline before reaching the business logic. The response would go back through the pipeline as well. EDRA handlers could inspect and even alter the messages flowing through the pipeline.

One of the other important goals for EDRA was the ability to physically separate the service interface from the service implementation. As in distributing these layers across different tiers and across security boundaries.

Our business unit at LogicaCMG followed and evaluated this effort in 2004 and even used it in some projects. We especially liked the fact that this was a ready-made framework for "policy injection". We made some extensions for cross cutting concerns not originally included in EDRA. Previously, we worked on a home-made framework that was based on .NET remoting extensibility to configure cross-cutting concerns. Although architecturally sound, it was far from complete because it still had a long way to go to fulfill our vision.

EDRA also included an early prototype of the Guidance Automation Toolkit to help framework users with building an EDRA based service. This was known as the "Microsoft IPE Wizard Framework". Check out this blog post from Daniel Cazzulino to see the EDRA wizard framework in action.

Eventually we reluctantly decided to drop EDRA. Some of the reasons for this were:

The EDRA wizards were hard to extend.
You had to mess with a big XML file to configure handlers.
No proper .NET 2.0 support.
No WS-* support.
No support for calling out into other services from the service implementation.
No big adoption in the worldwide .NET community. Not a lot of publicly available handlers.
No clear path towards Windows Communication Foundation. The internal messaging structure was not based on SOAP.

Especially the last reason was probably the biggest reason why Microsoft decided to stop the P&P effort on EDRA. The 1.1 release was announced to be the final release.

The Microsoft Enterprise Library has become far more successful with respect to adoption world-wide than EDRA. There are several EntLib extensions freely available. I've contributed my RollingFileTraceListener to the greater EntLib community. According to the feedback I got, this extension has been really useful for several people and companies. Microsoft has realized the lack of this functionality in the Enterprise Library and EntLib 3.0 will include a similar rolling file trace listener out-of-the-box.

EDRA is still being used by some companies. One of the largest implementations is the Commonwealth Bank of Australia CommSee Solution that is based on EDRA. Microsoft is still using this as a reference case. For instance, there was a presentation on CommSee at LEAP2007 in Redmond.

I disliked the idea that EDRA pushed you into the direction of distributing the service interface and service implementation across different tiers. Both layers had to be realized in managed code using EDRA, so the service interface could also just call the service implementation in process. Remember the first law of distributed computing: "Don't distribute!" (unless you have to).

Of course, it was great that you could distribute service interface and service implementation. But not all applications need this.

So in my opinion it is better to have different frameworks that cleanly support these orthogonal concepts:

Separating business logic from cross cutting concerns.
Separating service interface from service implementation across physical tiers.

Proseware

By the way, a sample application that was commissioned by Microsoft to provide guidance on how to build distributed systems never saw the public light of day. It was the Proseware application designed and build by newtelligence's Clemens Vasters. I never got a clear answer from Richard Turner, the responsible program manager at Microsoft, for why it would not be released. But I think it was because of internal Microsoft politics: Proseware was too close to the release of WCF and might be perceived as conflicting guidance (too close turned out to be two years!).

Proseware included a great idea to improve the reliability and scalability of web services. By using one-way messaging for both requests and response. That way you can use queuing inside your service to handle heavy loads and to automatically retry failed attempts at processing messages (for example when a database is temporarily unavailable) without bothering the service clients with having to retry. To achieve this, a web service interface would be a very thin facade around an MSMQ transactional message queue. The web service would only return a fault when the message could not be placed onto the queue (highly unlikely). The message would re-enter the queue if the service implementation failed at processing it so it could be processed again. A response from the service implementation would be send using a one-way message to the recipient specified in the WS-Addressing ReplyTo header in the original request. Note that this recipient does not have to be the original caller! It could well be a different service and the response message is really a new request. Check out this blog entry for more details on Proseware.

Eventually, we will all leave the world of developing and calling synchronous services in distributed systems, but that may take a while ;) Anyway, sorry for this digression, enter the Policy Injection Application Block.

Policy Injection Application Block

The new Policy Injection Application Block (PIAB) wisely focuses on just the separation of business logic from cross cutting concerns. Windows Communication Foundation is the way to go for distributing your system, i.e., for building connected systems.

The PIAB shares the idea of a pipeline of pre- and post handlers processing messages. It uses the MarshalByRefObject and TransparentProxy infrastructure that was originally designed for .NET remoting to transparently insert policies when they are enabled. The client just thinks it is calling the business logic object directly. Take a look at the pictures in Tom's blog entry to get a better idea of how this works and read Edward Jezierski's blog post.

You might also be interested in the comments posted to Tom's announcement. Several people are concerned about the performance impact that inserting policies will have on your code. This is caused by the technical implementation that Microsoft has chosen to insert policies (or should they be called aspects? ;). As I haven't looked into detail at the new block, I do not have a firm opinion on this matter yet.

The transparent aspect of the policy injection does conflict with the wisdom put into WCF. WCF follows one of the important tenets of service orientation: "Make boundaries explicit". Don't fool the client into thinking they are just performing a local method call, because the performance and reliability characteristics are entirely different. WCF achieves this explicitness by using DataContracts and ServiceContracts. It does not expose everything by default, you have to opt-in. It also makes you more aware that you should not use chatty interfaces across service boundaries.

One of the comments to Tom's blog post states that the overhead of just having a PIAB policy injection could mean that the mere act of calling a method is 50 times slower than a direct method call. If this is the case, you should be well aware and design your objects accordingly: don't implement chatty interfaces!

The future will tell if the PIAB will be more successful than EDRA at enabling the separation of business logic from cross cutting concerns in .NET enterprise applications.

Web Service Software Factory and Enterprise Library 3.0

Erwyn van der Meer — Mon, 05 Feb 2007 06:29:23 GMT

The December 2006 CTP of the Web Service Software Factory (WSSF) from Microsoft P&P ships with a 2.0 version of the Microsoft Enterprise Library. The Data Accesss factory inside Service Factory generates code which uses the Data Access Application Block from Enterprise Library.

This interface of the Data Access block hasn't changed significantly in the January 2007 CTP of version 3.0 of the Enterprise Library. I wondered if I could use this version of EntLib together with Service Factory.

It turns out that this is really easy. The Service Factory uses a registry key to locate the EntLib binaries. This key is HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\patterns and practices\Service Factory\EntlibBinaryPath.

It has a default value of C:\Program Files\Microsoft Service Factory\Enterprise Library Binaries\. After you have installed EntLib 3.0, change the value to the location of the new binaries. For the January 2007 CTP the default location is C:\Program Files\Microsoft Enterprise Library 3.0 - January 2007 CTP\Bin.