It dawned on me that my post on ObjectSpaces might have come across like I was reviewing production software. Obviously this is not the case. We are only in an alpha/tech preview build of Whidbey here, and there is still a lot of functionality planned to be added in other areas. I'm just hoping OS is one of them. The fact that OS has been under development for quite a while is a little disconcerting, but I am hopeful that the additional scrutiny that the Whidbey Tech Preview is getting on it will help make it more feasible.

Tuesday, December 30, 2003 12:55:14 PM (GMT Standard Time, UTC+00:00)
Comments [0]  | 

So I have spent the last few days trying to get ObjectSpaces working for some fairly straightforward stuff working with the pubs database that goes beyond the few simple examples they give in the Tech Preview docs. So far the experience is less than pleasant.

Conceptually I am enamored with ObjectSpaces. I am somewhat of an object bigot, and would love to cut out all the ADO.NET code I always end up writing that amounts to a mapping layer per app to populate my objects and store their state after changes. I haven't spent any time yet looking at any of the commercial products that do this because for the work and writing I do, I generally try to stay away from solutions that result in vendor lock in. I want to teach people how to get things done with the framework, not third party products. That is what they pay their marketing folks for. (OK, I realize this makes me an unpaid Microsoft marketeer, but that is a whole separate discussion).

I was able to get some one to one, one to many, and many to many scenarios working, especially for reading data. When it came to persisting changes, things got dicier until I realized that it was not hacking foriegn key constraints with inserting new object graphs too well. If I got rid of the FK constraints (not often an option in a production DB), I was able to persist new objects with one-to-one and one-to-many relations without a problem.

The real problem at this point is a combination of lack of documentation and REALLY uninformative exceptions. It is already a tough transition to make since all the talking to the database is done for you based on the mapping XML files that you author. There is no code to step into to see what is going on. At least when you have something really gooned in the mapping files, you will get an error message with some info on where you are breaking the schema.

But if problems occur at the DB, no usable information gets propagated back to you in your app. You just get really useful information like:

Error(s) updating one or more objects.

Yeah. Big help, thanks. Should have just stuck with an exception message like “You're screwed” until you have something useful to say.

Add to that the fact that in all of the three newsgroups (beta, private, and public) related to ObjectSpaces that I have found, people are more interested in debating the philosphies of ORM and whether MS should create a ORM layer or leave it to third party products than discussing how to actually use the product.

I think OS has a lot of potential and I want to figure out where it fits into the apps I develop. But we are going to need some better information to work with before that becomes viable for the masses.

Anyone out there working with it successfully for real world projects involving complex object mappings tied to other-than simple demo databases?

Monday, December 29, 2003 1:24:40 AM (GMT Standard Time, UTC+00:00)
Comments [0]  | 

I had one of those great “I told you so” moments with a consulting customer today. About a month ago, I recommended using the Exception Management Application Block (EMAB) for publishing their exceptions because of the ease of use and extensibility it offered. If you are unfamiliar, the EMAB lets you publish exception information in a catch block to any number of publishers with a single line of code:

catch (Exception ex)
{
ExceptionManager.Publish(ex);
}

Through the config file, you can then wire up zero to many publishers such as the built in Windows Event Log publisher, an XML file, a database, email, and so on. You can modify where the exception information gets published anytime without changing anything but the config file. You can create your own custom publishers and plug them in very easily as well.

So what I had proposed was to create a custom publisher that would log any exceptions to their existing application event log, which is just a SQL Server table that their monitor application accesses, with all the details that come along with the exception (message, stack trace, target, user, date time, etc.). The customer balked because they were intimidated by the block and thought it was too complex for their needs. “We never need to publish anywhere except our event log, and we already have code that does that”. Uh-huh, sure. Never huh?

Today the customer stumbled down a dark and windy road of synchronization nightmares due most likely to a shared data object class that was being hammered on by multiple threads and didn't have complete and safe synchronized access to its members. “Everything worked great in debug mode,  but when we run in release mode, it blows up right away with a null reference exception.”

Oh great, I love these. Where is it blowing up exactly, I asked? “We don't know, we didn't have room in the database fields for the full stack trace, so we just left that out.” Mmm. OK. Brute force time. Lets insert a trace statement in the exception handler to dump the context so we can see what is going on. Oh goody, just inserting trace statements in the method where it is occuring makes the problem go away. Surely no race condition here.

Then the customer ponders - “how can we get more information out about the exception if the exception goes away when we add more code to dump it?” Exactly. Wouldn't it be nice to just wire up a different publisher right now that can dump the full exception - type, message, stack trace, etc. - to an XML file or somewhere else for analysis without having to modify the code. Why yes it would.

Extensibility is your friend, especially when someone else (thank you Microsoft) has implemented it for you. I am absolutely against speculative design. But you also have to be realistic about things that might need to change after you ship and make allowances for them. If there are things you can use like the Exception Management Application Block, or any of the other applications blocks that give you an extensible design that just requires a little extra up front complexity to integrate, think seriously about what it might buy you down the road. We probably could have tracked down the exact cause of the problem today quickly if we just had complete information about the exception. And that information could have been easily obtained, even in release mode, without changing a line of code, if they had used the EMAB instead of a home grown, non-extensible solution.

.NET | Languages and Tools

Wednesday, December 24, 2003 12:24:17 AM (GMT Standard Time, UTC+00:00)
Comments [0]  | 

Well, it was worth a shot...

I thought to myself, “gee, I'm spending a lot of time working with Whidbey, wouldn't it be nice not to have to fire up a VM every time I want to try something out in Whidbey?”. Encouraged by some posts by some apparently more lucky people than I who claim to have successfully installed VS.NET Whidbey and VS.NET 2003 on the same machine, I decided to give it a try.

So now I am spending the afternoon trying to get my tablet back to a stable .NET 1.1 development platform.

Oh well, what did I expect. Its an alpha that says it is not compatible for side by side installation with 2003. Maybe when Beta 1 comes out. For now VMWare is my friend. Maybe Virtual PC 2004 will become my friend if it performs better than the Connectix version.

.NET

Friday, December 19, 2003 8:02:44 PM (GMT Standard Time, UTC+00:00)
Comments [0]  | 

I gave a talk on the Microsoft Application Blocks for .NET last night at the Capital Area .NET Users Group, which I help run as an executive member. Our scheduled speaker cancelled on us with short notice, so I had to jump in and pinch speak. Luckily I have given this talk a couple times before, at the WeProgram.NET and NW Ohio .NET Users Group, so it wasn't much of a stretch to give it again with only a few hours notice.

The talk seemed pretty well received. Lots of analogies drawn by some members of the crowd familiar with Java between the UIP and Apache Struts.

If you are not familiar with them, the Application Blocks are a set of best practice implementations that save you from writing common infrastructure code in your apps for a variety of situations. The current list of blocks include:

Data Access Application Block
Provides a thin, easy to use API on top of ADO.NET that can result in considerable code savings and cleaner code for data access.

Exception Management Application Block
Allows you to publish exception information to a variety of publishers with a single line of code in your catch blocks that does not need to change to publish the information to different locations - it is driven by publishers that are plugged in and wired up through the config file.

Configuration Management Application Block
Allows read and write access to configuration data in config files, other XML files, SQL Server, or the registry, unencrypted or encrypted, all with what comes “in the box“ with the block. You can also plug in custom storage and data protection providers.

User Interface Process Application Block
A model-view-controller pattern implementation for Web or Windows Forms applications that allows you to fully decouple the individual views of your application, even if those views form the steps of a navigation flow in your application. The controller manages the navigation flow between views using information in the config file and also manages the shared state between views. As a result, views never have to explicitly navigate to another view or pass it state, the controller and underlying classes in the block manage all that for you.

Application Updater Block
Allows you to make your apps auto-updating in a distributed or web-based environment. The block makes it easy for your apps to go out and check a known location to see if updates to your application have been deployed, and if so, downloads them and applies them on next run. 

Caching Framework
Supports the need in distributed, service oriented applications, to only retrieve data from services when needed by caching retrieved results at the call site. Supports a variety of caching scenarios and persistence providers. Works in conjunction with the Aggregation and Asynchronous blocks if desired, or can be used standalone.

Aggregation Framework
Supports the need in distributed, service oriented applications, to retrieve data from multiple sources and have it presented to your application as a single set of aggregated data. Works in conjunction with the Caching  and Asynchronous blocks if desired, or can be used standalone.

Asynchronous Framework
Supports the need in distributed, service oriented applications, to retrieve data in an asynchronous fashion so your app can continue doing other things until the data becomes available, which it finds out about through callbacks from the framework. Works in conjunction with the Caching  and Asynchronous blocks if desired, or can be used standalone.

These are the ones I am most familiar with. There is also a Logger block that came out recently that builds on the Enterprise Instrumentation Framework, but I haven't played with that one yet. You can find these through various searches on MSDN or GotDotNet workspaces.

Best centralized link is Ron Jacob's page on GotDotNet - lists alll the block lins:

http://www.gotdotnet.com/team/rojacobs/

Thursday, December 18, 2003 12:33:12 AM (GMT Standard Time, UTC+00:00)
Comments [0]  | 

While reflecting on yesterday's post on SOA, I realized I fell into the same old trap again that many are guilty of - blurring the distinction between Services and SOA. Most of what I was talking about in that post was really comparing Services to components or objects, not comparing SOA to component oriented or object oriented development. SOA is really about how you design and build systems composed of services, not about what a service is. I have fell into this trap a number of times, because talking about SOA inevitably leads to first defining what a service is and how it relates to components and objects, which is basically where my post left off. SOA is a much bigger beast, and I have to agree with Sam's post that it does lead to different methodologies at the high level architecture and design level. But at some point in that process, you have to build a service or services, and at that point you generally start to step right back into the comfortable world of component and object based development.

Architecture

Tuesday, December 9, 2003 12:29:55 AM (GMT Standard Time, UTC+00:00)
Comments [0]  | 

Thanks to Clemens and crew for v1.5 of dasBlog. Just like the initial install, this one went without a hitch. xcopy deployment rocks, and dasBlog 1.5 looks nice.

Blogging

Sunday, December 7, 2003 3:47:07 PM (GMT Standard Time, UTC+00:00)
Comments [0]  | 

SOA != Death of components and OOP

Sam is trying to get his head around SOA, along with many of us. He states:

“I must confess SOA to be one of those paradigm shifts - it really does mean the death of objects at least as we know them.”

I don't see it that way at all, any more than the development of component-oriented development meant the death of OOP. I see SOA as a semi-formalization of a higher level of abstraction that is needed in large scale applications. OOP developed as a good abstraction and way of encapsulting state and behavior in small-grained pieces of code for maintainability and (*potential*) reuse. Components evolved to encapsulate meduim grained chunks of functionality at a level where you could start to compose systems from pieces that could be more easily understood, managed, maintained, and yes, sometimes reused. I see SOA as a further evolution down that path - encapsulating functionality and processes at a course grained level - making it easier to describe and compose larger systems out of collaborating, interrelated parts.

I don't think SOA means the death of OOP or Components at all. Just like most people build components using OOP, I think most people will built SOAs using OOP and Components. They are not competing concepts but complementary.

Indigo gets into the game by not forcing you to choose up front in and all or nothing fashion about which particular communication technology is going to be used to let services collaborate by using the abstraction of SOA. If you have two pieces of a system, or two systems that need to communicate and share information, focus on the communication contract, not the implementation mechanism. Maybe for now they are both going to be sitting on the same machine, but you want strong security and have more than one resource manager - a good fit for Enterprise Services. Next year you find you need to scale out or relocate those services and now there is a firewall in between. Now Web Services start to make more sense. Today you would need a significant rewrite of the application. With Indigo it would mostly be tweaking configuration.

I spent a lot of time looking at, writing on, and speaking about the Microsoft Application Blocks before attending a workshop on Indigo in Redmond back in September, and it helped me understand Indigo in a big way. Many of the application blocks use abstractions of Providers and Publishers that can be configured and plugged in to change the behavior of the block without needing to change any of the application code. This is done by adding classes (components really) that implement the interfaces that constitute the contract of the block, and using config files to get them loaded dynamically at runtime. The application just programs against the interface, so it doesn't care which provider or publisher is servicing the functionality. They are very slick.

The Shadowfax project Sam mentions is another block in development addressing SOA.

With SOA, the contract just migrates from being a binary interface specification to being a more abstract and platform neutral WSDL specification. How you satisfy that contract depends on the requirements of your application.

Bottom line, I see SOA building on OOP and Components conceptually, and see SOA applications being built with OOP and components. I hope people don't decide that this means they should go back to procedural programming. 

Architecture

Sunday, December 7, 2003 1:48:42 PM (GMT Standard Time, UTC+00:00)
Comments [0]  | 

Great post by Rory about the theft of ideas.

I've often used the analogy that MS is to software what the Japanese are to cars - they are experts at taking a bunch of good ideas invented by others (and adding quite a few of their own), polishing the implementation, making them accessible to the masses, then mass marketing so the masses are bound to choose them. Bravo, capitalism at its best. Gives me an entire market economy to base my business in, along with thousands of other companies. How could that be a bad thing?

Wednesday, December 3, 2003 7:59:30 PM (GMT Standard Time, UTC+00:00)
Comments [0]  |