Tom Hollander's blog

patterns, practices and pontification

What's next in the LOB Program?

What's next in the LOB Program?

  • Comments 4

Not many people know (or for that matter, really need to know) that the patterns & practices team is internally organized into four "programs". A program is basically an umbrella used to group related projects, with a dedicated budget and core team (although some people do work on different projects that span programs).

The programs we have at the moment are:

  • Line of Business (LOB) Applications (I'm the Product Manager for this program)
  • Smart Client (Eugenio Pace is the Product Manager)
  • Integration and Web Servcies (Don Smith is the Product Manager)
  • Engineering Practices (no full time Product Manager; J.D. Meier is the Architect)

As regular readers must have noticed, most of my time has been taken up by Enterprise Library since I've joined p&p - but EntLib isn't the only project in the LOB program. Earlier in the year we shipped the Guidance Automation Toolkit, and we'll be revving this for the RTM version of Visual Studio 2005. And after we ship Enterprise Library for .NET Framework 2.0, we've got some new projects planned. Today I'd like to give you a bit more information on what we've got planned for next calendar year - and in return I'm hoping for your feedback and ideas on how these projects should evolve. (Disclaimer: this information is based on early plans, and is subject to change - but I'll try to keep you informed on major changes of direction on this blog).

"LOB Application Toolkit"

Ever since we first shipped Enterprise Library, we've heard two related questions:

  1. What is the best way of using multiple application blocks together in an application?
  2. Do you have any end-to-end sample applications that use all of the Enterprise Library blocks together?

These questions aren't at all surprising - while the blocks all provide useful functionality, and many of them are designed to be used together, at no time do we prescribe an overall application architecture or demonstrate any particular way of assembling the blocks together. This was done deliberately - in order to make the blocks applicable across a wide range of application types and architectural styles, we kept them as independent as possible. However we realize that this puts the onus of coming up with a viable architecture using the blocks back on you, and so far we have little in the way of guidance to help you.

So we know what problem we are trying to solve, but what's the best way of solving it? One possibility is to ship a "reference implementation" or sample application using all of the Enterprise Library blocks. While we know a lot of people want this, we're reluctant to do this in isolation. This is because a reference implementation must necessarily implement some synthesized business requirements for a ficticious organization (think IBuySpy or Global Bank). While sample apps can be valuable learning tools, the problem is that it's not always obvious how to "project" the guidance in the sample app onto your own business requirements for your own organization (unless of course you are in the business of selling equipment for spies!). Another option was to update our aging but still popular Application Architecture for .NET guide - but we'd prefer not to couple this guide too closely with any version of our blocks, plus we know that written guides don't provide the productivity benefits provided by code-based guidance.

The project we are currently calling the "LOB Application Toolkit" aims to address this by providing tools (built using the Guidance Automation Toolkit) to help you build your own customized baseline that uses Enterprise Library blocks and adheres to our recommended architecture for LOB apps. This will likely involve a combination of techniques integrated into Visual Studio, including templates, wizards, recipes and code generation. The idea is that the Toolkit will ask you a bunch of questions about what application you are trying to build, and it will generate an application skeleton that will your requirements as closely as possible. Still we don't want this to be a mysterious process that generates vast amounts of unmaintainable code (anyone ever use the MFC wizards in VC++ 6.0? :-). While we will likely use project templates and some code generation to get you started, GAT makes it possible to surface guidance incrementally throughout the development cycle, making it much easier to take just what you need when you need it, and understand what the toolkit is doing. We also plan to include the oft-requested Reference Implementation - but this will be built using the toolkit - giving you an example of what a finished product could look like (kind of like including a picture on a box of lego that shows what you can build with a particular kit).

I hope I've sold you on the vision. Where we need to do a lot more work is to figure out exactly what the architecture should look like, which features to include, and how much variability to support through wizards, recipes and designers. Our definition of LOB Apps focuses on what happens inside a service - from the service interface to the database - user interfaces and integration with other services are technically out of scope, but we know we need to provide some guidance on these, even if it means taking a dependency on toolkits from other programs. Probably the biggest challenge that we need to address with the LOB Toolkit is around the representation of, and persistence of custom business entities. We want to provide solid guidance in this space, while avoiding the ORM can of worms and providing a smooth migration path to the LINQ features coming in the next version of .NET. We have some ideas about waht this might look like, but I'd love to hear your views on what the scope and architecture of the LOB Toolkit should be.

I should also mention that the LOB program isn't the only one investigating this "toolkit" approach. The Smart Client team is already well underway in developing a toolkit for building smart client apps, and the Integration & Web Services team also has some great ideas for using this approach in their program.

Other Application Blocks

The LOB Application Toolkit is likely to be our next major priority after shipping Enterprise Library for .NET 2.0. However we do have a couple more application blocks that we hope to build in the next year or so - probably after we ship the Toolkit.

The first is an update to the User Interface Process Application Block, specificially targeting web apps. As you may know, UIP v1 and v2 provided guidance for both web and smart client scenarios. However we got a lot of feedback that it didn't make a lot of sense to support two very different architectures and scenarios in a single block, so we're merging the key smart client scenarios for UIP into the Composite UI Application Block. This has left the web scenarios orphaned, and we plan to deliver this in a new block. While we haven't worked out the details, it's likely that we'll be leveraging the new Windows Workflow Foundation services in this block.

The second is a new Validation Application Block. This isn't anything that we expect to revolutionize development - but we consider it as relatively low-hanging fruit that will save time and encourage more code reuse. The idea is to provide a consistent way of expressing validation rules that can be leveraged in many different parts of an application. This block is likely to make its way into a future version of Enterprise Library.

Sorry that the details on these new blocks are vague - but I wanted to let you know what we're thinking about at the moment. As always, your feedback is appreciated (and necessary to make sure we're investing the right amount in the right areas!)

This posting is provided "AS IS" with no warranties, and confers no rights.

  • I really like the way validation controls work in ASP.NET, but the validation model is completly different in WinForms. And what about validating input of a web service where the are no controls? A consistent model in this aspect of application design will be most welcomed.

    One aspect of my applications that could use some "EntLib magic" is in the area of business rules validation. I've seen solutions ranging from rule validation duplicated and sprinkled all over the application, to home-grown rules engines tailored for the applications into which they were built (read: not reusable). Some guidance in how to design/implement business rules validation in the context of the various architectures (WinForms, WebForms, Web Services, Mobile, etc.) would also be greatly welcomed.

    And lastly, I want to express gratitude toward Microsoft and the EntLib team for the efforts put forth for the community. Thanks for all that you do to help up build better software.
  • Did you ever think about a Business Rules Application Block? Something that would allow building simple business rules engine and wire it up to a configuration module?
  • Here is the definition according to the Microsoft internal Glossary Service we have: A Microsoft collection

  • A little about the history... At present EFx ( Enterprise Framework ) is in a state of transition from

Page 1 of 1 (4 items)