Enterprise Library 2 Architecture: Part I


Click ARCast. Enterprise Library 2 Architecture: Part I to listen to this ARCast.

Ron Jacobs.   Welcome, everyone, welcome to ARCast. Hey, I am your host, Ron Jacobs, your source for architecture information. And today we have a really special program about one of... Well, it has to be one of the most amazing stories of the year: Enterprise Library. Many of you have been waiting for Enterprise Library 2.0, and it's just around the corner. Well, I sat down the other day to do a Web cast with Tom Hollander and Scott Densmore, and, you know, we kind of covered ground there about the architecture of Enterprise Library, and it was a great, great Web cast. But here is the thing that totally bugs me about Web casts. When you listen to one, you are basically listening to an analog recording of a conference call. I mean, how lame is that? We are in the digital age, my friend, we can do better, and we WILL do it better here on ARCast. So, listen up, it sounds really good on this version.

Alright! Thank you very much! And welcome, welcome, everybody to ArcTalk. Hey, we're so glad that you are here. Well, it was the Cinderella story of the 2005 season. A small group of upstarts, working in the dark corner of Redmond known as the Delta Lounge, put together Enterprise Library. The stats of this team are just amazing: in less than a year, over 200,000 downloads. Now, the question is, "Can they repeat the miracle in 2006?" or "Was 2005 just a fluke?" In the off-season, everything changed with the introduction of .NET 2.0, System.Configuration, and ASP.NET membership and personalization, and 2006 looks like a brand-new ballgame. Today, I am joined by Tom Hollander, the head coach and product manager for Enterprise Library. Tom, welcome to ArcTalk.

Tom:   [Crowd cheers] Thanks, thanks Ron. That is the…! I do not know! I can't respond to that. That's the strangest introduction I've ever had.

Ron:   And also team captain and lead-developer guy, Scott Densmore. Scott, welcome to ArcTalk.

Scott:   Thank you, thank you very much. [Attendees: Ooh…]

Ron:   You are so...! I am so glad to have you back, because, you know the technical difficulties this morning remind me of... Do you remember, last March, we made the very first Enterprise Library Web cast?

Scott:   I am trying to forget that…

Ron:   We had the same exact problem. We started, like, 10 minutes late or something. It was, it was really lame.

Scott:   At least we have the right title on the slides, this time… You got the title wrong every single Web cast, last time.

Ron:   That's right, and thanks to you for making sure that everybody remembers that. OK! [Laughs] Alright, so, today we are going to be talking about Enterprise Library for .NET Framework 2.0 and, Tom, what we want to get into here is really, what is, what is new? What is different? You know, Enterprise Library was a great success, but what are we looking at for 2.0?

Tom:   So, we went into a lot of detail about this, I do not know, around a month ago, the last Web cast, so I do not want to bore you all by telling you the same thing again. But… [Scott: Just to kind start… Just go ahead and be quiet.]

Too late. [Laughs] (Unintelligible)

Just to give you a quick summary. Basically, this is a significantly new release of Enterprise Library, really, because it's designed for .NET Framework 2.0. We didn't just take our own code, old code and compile it and say, "Hey, it still works, so let's go." Although the June version does still work, we really made sure whether we are leveraging the new cool stuff, using all the new features. The scenario was supporting, really, pretty similar when do not have brand-new blocks or really, really different kind of scenarios. But we did take lot of your feedback and made lot of things easier. So, yes, it's hopefully a great release. Not quiet finished yet, we are sorry. The… There is a couple of great community technology-preview releases available. The November release is kind of a full MSI documentation, nice and polished, that's been out for a little while. We've also sort of snuck this extra bonus release, which we just called Interim Community Drop. We called [it] that, because we just wanted to get that out as quickly as possible, so [we] didn't take [our] eye off the ball, to reuse your sporting analogies here, Ron. [Ron: OK.] [Laughs] So that, it has got [a] configuration tool, it is very close to being complete. But we didn't really have a lot of time to go and kind of make it look all glossy and shiny. But there are available to download from the GotDotNet site there and [a] final version should be out, I do not know, by about a month from now.

Ron:   OK. So, it's still baking, as we say.

Tom:   It's so crisp, the smells coming from the kitchen is going to be nice.

Scott:   It's actually sitting on the cake rack, you know.

Ron:   Oh, it's cooling... It's cooling now.

Scott:   It's cooling off now. We are waiting for the final say-so from the referees and making sure we have no penalties left. [Ron: Alright!]

Tom:   You can't keep… mix kitchen analogies and sporting analogies! [Scott. Yes, I can, I can do anything I want to!]

Ron:   OK. Alright! There have been some changes from Enterprise Library version 1.x, OK. So, what are those changes?

Scott:   Majorly, the config… The System.Configuration introduced a whole new ballgame, as you would say. Now, System.Configuration and their newly… I am trying to be nice here sometimes. The new classes they introduced actually did a lot of functionalities that we had in 1.x. [Ron: Yeah.] And they allowed you to do strong typed classes, of course, they used a internal XML, their own XML serialization, we no longer reply, rely on the external XML serialization. So, what we did was, because System.Configuration handles that, we basically, I want to say, dropped configuration blocks in favor of [a] bunch of configuration helpers, and introduced dependency injection to get rid of a lot of the hard things to do to get into building your own block.

Tom:   We'll be going through that for most of the talk today [Ron: Yeah. Yeah. OK.]

Scott:   But the new instrumentation is completely configurable. Tom made us go through the whole thing and rip it all apart.

Ron:   Ha! Here we [...] Here, that's right, you had to answer all these e-mails, that's right. Why is that?

Tom:   I wasn't going to go through this "How do you…? Why are we always getting these instrumentation areas and security problems again, like. [Ron. OK.]

Scott:   So, we do not have to post to 300 blog postings and 300 message replies in the board. [Ron: Ah! Alright.]

Much-improved logging block, it's not as complicated and it's muchos faster. Better data-access integration with the .NET tool, because they have [a] lot of [the] same functionality and the security application block, we have removed the things that ASP.NET duplicated for us and they took over, and that is pretty much the major changes. [Ron. OK.] At a higher level.

Ron:   OK. But just [to] be clear Tom, this was not unexpected, right? I mean, that is sort of the plan for patterns & practices, right? That, you know, we'll solve some problems in the release and [the] next release of .NET Framework, then some of these problems are solved by Framework, right?

Tom:   It's, it's a moving target, and we expect here every time the platform has great new functionality, we are going to totally use the platform. It's like fully supported. It's more stable from an API perspective. We sort of look what are the things people are doing above what platform supplies and that change over time, so we'll listen to you guys and we'll hopefully come up with [a] great release at any given moment.

Ron:   OK. So, here is new Enterprise Library and a much cooler diagram, thanks to Tom!

Scott:   And this is actually [the] final version right here, and this is all you are getting.

Ron:   [Laughs] Just a big picture, OK. OK, so we're gonna kind of make our way through the various blocks, and first of all we're gonna start with the big circle in the middle, right there at the core.

Tom:   We actually went through blocks in the last Web cast. So, really, the core is where [we] are really focusing on today. So, we have got… how many blocks left? 1, 2, 3, 4, 5, 6. But the core is kind of this new concept, and rather having like configuration blocks, we have before, core really is kind of a bunch of different kind of component and couple of different assemblies. But we got there configuration helpers that Scott just mentioned and design-time classes. We got our instrumentation library, and we got this thing called Object Builder.

Ron:   OK. So, let me ask a, first a question about the core. Is the core, kind of... Should I think about the core as, like, "Oh, that's internal stuff and I do not need to know it, I do not want to use it"? Or I should... Or is this stuff I learn about and use it, if I want to?

Tom:   I think either, really, is the answer. If you want to go and use one of the blocks and say, "Hey I feel like using access blocks," all you need to know is you've got to copy the common object and the Object Builder assemblies, and you can basically ignore them. But if you want to go and extend things and build some slightly more advanced functionality, you can use all this stuff […] has got.

Scott:   Yeah. I mean, the whole idea is, a lot of the time, people… The feedback that we got was that using the blocks were a little bit difficult, because it involved having a kind of carnal knowledge of the configuration and underlying configuration. Now, we have removed all that knowledge requirement.

Ron:   Wait, wait, wait. Did you say "carnal knowledge"? No one else knows.

Tom:   I was going to word that. No one else noticed.

Attendees.   Ooh!

Ron:   OK! All right! Let's go on. OK.

Scott:   Well, that's why I called carnal, because most people did not want to. And so what we did was, Object Builder allowed us, again, if you had one of the earlier August previews, you saw that we are moving towards dependency injection, and I am not going over about what that is. But basically we had a… doing dependency injection that allows you to kind of separate the concerns of the configuration versus what the actual block does. So, you don't have to have configuration to make it work. So, Object Builder is just a pipeline to help us do the dependency injection and, again, you can know all about this or use the block as is and not worry about it.

Ron:   OK! Great! Let's take a look at some of the issues in the core architecture. And, so Tom, this is the list of things we are going to be talking [about] here?

Tom:   It's certainly is.

Ron:   OK, so, we should then just press on ahead then, right? [Tom: That's a great idea.] Alright, so, let's talk about configuration.

Tom:   OK, so first just, why do we need this configuration stuff in [the] first place? And, really, the Enterprise Library Application Blocks—in fact, the Application Blocks from really long before Enterprise Library—had really been very configuration-driven. Configurations [were] used for a few different things. Sometimes, there's just some knobs and dials you can kind of twiddle on the application blocks to change their behavior, and one of the great things about configuration is, it is easy to change, kind of, at any stage in the development life cycle from development through testing into production. The other thing is, all the blocks are extensible, so you can use different kinds of plug-ins that change the functionality and plug in your own code. And configuration is really where you tell the blocks to load your own types and your own plug-ins. So, that's kind of what we are doing with configuration. Scott mentioned we used to have a Configuration Block. The reason why it was a block is, the System.Configuration in .NET 1.0/1.1 was really only supporting very, very simple scenarios. So, if you wanted to be able to read as well as write configuration or deal with kind of rich objects graphs, it really wasn't very flexible. So, the Configuration Blocks—sort of from when we first did it about three years ago—was kind of about helping you support those more advanced functionalities in your own application. With .NET 2.0, that really isn't needed so much, because System.Configuration really supports all of those same pieces of functionality. So, what we did this time is, we really built some helpers that will fine-tune the way the configuration works for Enterprise Library. Again, you can reuse some of the stuff if you have some more advanced functionalities, but you probably won't need to…

Scott:   Right. The biggest piece that our helpers allow you to do is… Out-of-the-box, the System.Configuration does not support polymorphic collections across, you know, different types. And when… Since we have a lot base types—if you talk about logging and trace listeners, and you can have all kinds of different trace listeners—well, there is really no support for saying, well, this type of trace listener is in this collection, you know, trace listeners are in this collections, but this trace listener is an e-mail trace listener versus data… logging database trace listener or whatever that is. And, so, what we built all these helpers for is to support that polymorphic types around those collections, and a lot of helpers around not having to know all the different, you know, pieces of, you know… System.Configuration is basically plumbing, and we just kind of tied it all together to do the reading and writing. Even though it supports it, we have a lot of helpers just to wrap over that, so you can kind of abstract all the little pieces away.

Ron:   OK, so, I think I heard you say that if I, like... In the previous version, I have an object graph for all different kind of objects, just using typically the XML serializer, which handles that just fine. But System.Configuration, though it supports strongly typed objects, it does it with just the single type of strongly typed objects, not a whole bunch of different types.

Scott:   Right. So, you have collection of types and they are based on a polymorphic type… You have an interface or you have a base class type… It doesn't support that out-of-the-box. You can always build that yourself. I mean, they… you… they support building it yourself, but they had no scenario for doing that themselves. And, of course, they have the provider base [Ron: OK.] version, which only supports name value pairs, so [we] wanted to be able to give you more of the same functionality that you had in 1.x to support having strong typing, instead of just having this name-value collection to pass in to your constructor or this initialize method. So, we went ahead and built all that, those helper classes, to do that for you.

Tom:   The other big thing that we [had] in the Configuration Block before was the notion of kind of pluggable storage. That was kind of cool, because most people kind of want to store their configuration in XML files. But sometimes you might want to put them in maybe a different XML file or somewhere like a database or a configuration-management database, and that was also something which System.Configuration didn't support, which we will discuss how we got around that in the next couple of slides. And the other thing is monitoring files for changes. Inside ASP.NET, as always, if the file changes, then the [...] will be recycled, but sometimes you might want to go and be notified.

Scott:   Not necessarily now.

Tom:   Not necessarily now. But you can control that a bit more. There are a couple of things that we thought were important scenarios for Enterprise Library, maybe a few applications, which we've also looked to build on top of with our helper classes.

Ron:   OK. One thing I was curious about is, the Configuration Block in the past supported encryption of sections, and so, you know, I knew that... I had heard that .NET 2.0 Configuration now supported encryption. But everything I read was all about how you encrypt connection strings and Web.config. But you are writing like a smart-client app, and maybe if you don't have a Web.config, you know. How could I do it? I couldn't come up with good way.

Scott:   The interesting thing is… And this is just a quirk. I do not call it a bug. It's a quirk.

Ron:   [Laughs] OK. I got it. [Laughs]

Scott:   You can encrypt sections in any type of config file. The problem is that you have to name it "Web.config" and then pass that to the command line of the encryption, and then you can rename it to "app.config" and it still works.

Ron:   Ahh...

Scott:   And you can actually do this through APIs. But…

Tom:   The API is kind of the official way of doing it. The kind of quick-and-dirty and much easier way is to go and trick it by calling it "Web.config". Don't know if we necessarily recommend that as best practice. But it works.

Scott:   The best way to do is through… There is an API and System.Configuration to do it. So that you read and write, you can set up your encryption provider, and then you can read and write encrypted section.

Ron:   So, we're still supporting that with the tool?

Scott:   We are not supporting it in the tool. We are supporting it through the command-line tool. You have to do it yourself. [Ron: OK.] There were certain things we could not do [to] get it working, and so we opted to drop that feature for now.

Tom:   But it's supported by .NET. Just to be clear.

Scott:   It's possible to do. It's not… We have not removed the functionality. It's just not part of the design-time tool. Actually, you have to go out and either play that trick quirk or use the APIs to do it.

Ron:   OK. OK. I got you. Alright. So, Tom, let's move on and look at this configuration run time.

Tom:   So, we have already discussed most of this. Basically, we are using System.Configuration, and it's not a block. Things we have changed… is kind of… on top of System.Configuration. That means that the sections are all derived from the configuration section class and they use data deriving from configuration element and they're stored in app.config or Web.config file by default. So, in v1, the default configuration—although you could change within Enterprise Library—was that each block had its own separate file. In this new version, the default configuration is, everything goes in that one file. But since System.Configuration actually does let you put any section in your own file, you can still kind of get either behavior. And, yes, so we mentioned encryption before. And so configuration run-time helper classes, they are in a common assembly. So, we have not got a configuration assembly, although there is configuration-design assembly. But the configuration run-time helpers are part of the Common. And you can use them if you want, if you like—what we are gonna talk [about] in the next couple of slides. But don't feel that every time we're using configuration, then it's necessary to use the Enterprise Library functionality.

Ron:   OK! Great! And, by the way, let me just mention, there's already a whole bunch of questions in the queue, and we are gonna actually stick around in the studio today and, after the Web cast is over, we are gonna record an ArcTalk episode that will be posted on Channel 9 in the next day or so with the answers to many of the questions that we could not get to during the Web cast. So, if we do not get to your question on the Web cast, we'll get to it in the post... post show.

Scott:   Post-game show, that's it! You will be James Brown and I will be Terry Bradshaw. [Ron: OK, there you go.]

Ron:   Alright, so let's talk about what's this The configuration sources now? How does that work?

Scott:   So, in the 1.x of Enterprise Library, we had this configuration context. Now, we named it to Configuration Source to abstract away what's going on underneath the covers. Since out-of-the-box System.Configuration doesn't actually support going to multiple sources. Now, I will say this: There is way to do it. It is very complicated. We chose not to go that route. So, we went the route of having this wrapper over a configuration source. Now… over System.Configuration, to support file, external files, although System.Configuration, you can put an external file in your section; that support is still there. But, for example, if you don't want to use app.config, you want to use this foo.config, because multiple applications used that same assemb… that same configuration source; that is what we are supporting in that… in this scenario. And, of course, you still have a sample for doing SQL configuration source. So, this configuration source allows you to… abstracts away, what… where you are actually getting your section information. Now, we [are] still support getting, you know… IConfigurationSource basically has a GetSection(), just like configuration manager off of… from System.Configuration, and what you get back is based on what source you've set up through your configuration.

Tom:   So that System Configuration source and file configuration source, for that matter, are really pretty thin facades. They basically pass everything through System.Configuration.

Scott:   Exactly. Because System.Configuration allows you to open sources from a file, they have an open mapped file, an open .exe-mapped file configuration that you can open any file and call it your configuration source. We have that thin wrapper for the file configuration, of course. System.Configuration just uses, basically, the one that goes […] app.config, and of course we have other… interface IConfigurationSource to go over and build like your own SQL Configuration source or if you had a hardware device that you want to put that on, or whatever, to support the exact same scenario that we did in 1.x.

Ron:   OK. So here is a question for you. If I have got an Enterprise Library app already, you know, it's running, and I did the default behavior where I had, you know, my DataConfiguration.config and my LoggingBlah-blah-blah.config, and say I have five different config files from all the different app blocks, and I am gonna move this over to the new Enterprise Library. Am I going to then? I could still use this file configuration source to read those independent config files, if I wanted to.

Scott:   Well, you can't read them by default.

Tom:   Yes. So, the configuration formats have all changed, so you really have to rebuild your configuration files, anyway. If you just wanted to have kind of what we have one by default, you probably would still use System.Configuration source and then use… What is it called, the external file attribute? Just like […] somewhere else. [Ron: Oh, OK.] But the biggest reason why people might want the file configuration source… This is one of those things, if I had penny for every time someone asked me, I'd have $1.32 or something. People have DLLs, and they want the DLL to own the configurations for the EXE, so rather than have MyApp.exe.config or Web.config, you want MyDll.Config. You can use the file configuration source… This is not the optimized default file, but everything is going to come from [a] separate file.

Ron:   OK, OK, so I got this. So, really, you just build this abstract interface to kind of allow us to support the scenario that System.Configuration does not support really or very easily, I guess I should say. [Scott: Right.] Because when I was reading docs on System.Configuration, I thought, "Oh, it looks like you can support SQL store through that." But...

Scott:   And you can't. Of course, doing that involves a lot of code, because you have to duplicate lot of functionality in there, in what they do. And, of course, we didn't want to do that in that way. We found an easier way to go about doing that. And, of course, we know that, you know, that $1.32 bought us not everybody having to do it by themselves.

Ron:   OK. OK I got it. OK, so we talked about most of the stuff here on the slide. Let's talk about how you choose a configuration source.

Tom:   So, we wanted to this, kind of, the default experience, it just works, you don't have to think about it. But if you want something a little bit advanced, then there are ways you can go and do this differently. So, the default… You do not have to go and add a configuration block, you do not get it automatically, like you did in v 1. In fact, if [you] don't do anything special, it will just assume everything is in your app.config or Web.config file, and you will be using the SystemConfigurationSource. The other thing you can do, though, is you can go and define this configuration source's section, which we'll show you in the next slide. But that's basically saying, every time a block needs configuration, rather than go to this System.Configuration source, go to this other one. That's kind of equivalent to what we kind of informally call meta-configuration: configuration about the configuration. So, that information still goes in your app.config or Web.config file, just like it did in v.1. But it's saying, "Hey, get all the actual real settings from this file or this SQL Server" or something like that. And, finally, you can actually do everything programmatically, if you do not want to have a configuration file at all, you can go […] a new app and configuration source or use a factory and do it all from code.

Scott:   And we got it… All of them got it right, this time.

Ron:   OK. You know, I have to point out that... When was it, like, almost 3 years ago, it was shortly after I started in patterns & practices, I wrote down my little thoughts on Application Blocks, and one of the things I said was that you ought to be able to use them without having to define a configuration file. Somehow, that paper got lost in our sources, say, for something like that, and we never did it. But we finally got there.

Scott:   We had that support in v1.x. And it was… And if I had a penny for every question I got on that, I'd have about $1.31. And we did support it. It was [a] lot more difficult than it needed to be. [Ron: With the config context. Yeah.] Right. This one is much easier, and we'll… It can be done just the same way, but it's a much better implementation of the scenario.

Ron:   OK, so here we have a little ConfigSource example. Let's talk about this one.

Tom:   Yup. So, what you can see here is the XML, it's really pretty simple, it's saying, "Hey, we're gonna define the file configuration source, which has a path," I mean, to be consistent here, it's called Test.Config at top and Tom1.config at the bottom. But, either way, it's defining the file and we are also defining the System1. And then you can see, at the very top, that we are saying, "Hey, if there is one that wants to use by default, if you don't ask for a different one." But, of course, in these happy days with the configuration tools back again, you can actually go and use the configuration tool and do it just like you can see here; so really, really simple. If you look at the code below of it, we are creating a couple of different database objects. The first one is just [the] standard way, you have been doing it for a year now, which is DatabaseFactory.Createdatabase. And if you've got no configuration sources section, that will use System.Configuration source. If you have this midi configuration section, that will use the one that's specified. So, in the example here, we have to use the file source. And the code below is what happens if you want to go and programmatically say, "Hey, here is where my configuration source is." So, if you don't want to have, again, if this was in DLL and you wanted to always load from your DLL file and you know what it is called, you won't need to have your app.config file with that second example.

Ron:   Oh, OK, so that, that would be cool. Alright. And, then, change notifications are another very cool feature of the config block. So, how do we handle that now?

Scott:   The exact same way. [Ron: Ah, lovely!] You will actually notice a lot of similar code, if you were interested in going and looking at that. Except that this time, we do not auto-magically all the time hook up everything for you, we allow you to actually add and remove your own handlers. Now, we do it for the file in the System.Configuration source, and it works pretty much the same way. If that source changes, we will reload those things in [...], now when I say we don't do by default, it does not work for every block. In other words, we didn't hook it up [for] every block by default. The only block we hooked it up for, if I am correct, still correct, is the logging block. So, by default, you don't get configuration changes for the data-access block or the exception-handling block. You can blame Tom. [Laughs]

Tom:   The configuration runtime will fire the events. But it's up to any code, whether it's our code or yours, what it does with those events. We support logging, because everyone says that's by far the most important. We really want to change logging dynamically. If applications are not running well, we want to up the level. It's really just the timing thing, we didn't want to go… It takes lot of testing to make sure if all is OK. And we may look at it again, if it has lot of demand, but we want to support what we are working for.

Ron:   Just to be clear, what we are saying is that if your app is running and you change something about the logging config, the logging block is gonna see that, because it knows it's signed up for the notifications, and it's gonna apply the change immediately. But any other block, it's not gonna apply the change if it changed, and if you want that behavior, you're gonna have to make that happen by registering the notifi... delegate or something like that.

Tom:   You have to make changes to the Core block to deal with that.

Scott:   Yes. So, the good part is, is that you can do it for yourself. You can sign up for those notifications, and just like you could before, we found that probably doing it for every single block was overkill, and so if you want to do that. And because the way System.Configuration works, we had to make some compromises about how the notification works. So, by doing that, we didn't want to do every single block.

Ron:   OK. OK. Got it.

[STCHHHHH... sounds like signal is lost.]

I am sorry. We're gonna have to stop it right there. Hey, we are just running out of time. You know, these Web casts go, like, for a whole hour. Now, I think an hour makes a little bit too long of a download, especially when we encode it with such rich, high-quality digital audio. So, we're gonna do Part II of Enterprise Library 2.0 architecture. And, you know, hey, I think this sounds pretty good, and it works pretty good, too. All this time, you have been listening to this lousy little puny analog signal over a telephone, when you can have the rich, full FM-quality or better. Even better.

Yeah, I know, I know, at the beginning of the show, I said, "ArcTalk," didn't I? Well, newsflash: ArcTalk is no more. It has been subsumed, acquired, swallowed up by ARCast. And that's what this show is, going forward. So, it's ARCast, you know, live with it, OK? Because, we recorded this before I knew that, OK? That's why I said it. Alright, done!

Next episode, we will have another shot of Enterprise Library 2.0 architecture, so stay tuned for more ARCast.