I believe that we can produce models that can be 'executed'. I also believe that UML is not the way to go to achieve it.
There is an article in the Microsoft Architecture Center about 'Software Factories and DSLs' which I find quite interesting:
Software Factory is a product line that configures extensible development tools like Visual Studio Enterprise with packaged content like DSLs, patterns, frameworks and guidance, based on recipes for building specific kinds of applications. For example, we might set up a Software Factory for thin client Customer Relationship Management (CRM) applications using the Microsoft .NET Framework, C#, the Microsoft Business Framework (MBF), Microsoft SQL Server Yukon and the Microsoft Host Integration Server (HIS). Equipped with this factory, we could rapidly punch out an endless variety of CRM applications, each containing unique features based on the unique requirements of specific customers. Better yet, we could use this factory to create an ecosystem, by making it available to third parties, who could extend it to rapidly build CRM applications incorporating their value-added extensions.
The idea of having a set of diagrams an metadata-based models that are very focused on the domain problem and the technologies that will be used to implement it is very good. As far as I know it's a unique approach in the industry. I've been hearing about DSLs from Microsoft for a long time but it's the first time I see an example of it that makes me understand what they are trying to achieve, and I like it.
Some interesting discussions around datasets and webservices are happening in the blogsphere.
First, Scott Hanselman says you should not use them from WebServices. Then Ted Neward agrees, and then he disagrees.
Meanwhile, Doug Pourdy gets to the point and says that the real root of all evil are PurchaseOrders, and Clemens admits he does not use them anymore (that one hurted me! ;)
I'll be bold and try to wrap this up.
a) DataSets can be consumed from a Java client with no effort given you follow the recommendations in DataSets, Web Services, DiffGrams, Arrays, and Interoperability. Is probably not the best performant solution but it works.
b) From the four basic CRUD operations, there are two that are very easy to expose in webservices, which are the 'C'reates and 'R'etrieve operations. 'D'elete and 'U'pdates are easy if you don't try to cover optimistic concurrency scenarios. They are very hard if you want to cover them and you need the older values, i.e., I retrieve an order, I change it, and send it back, my optimistic concurrency strategy could need the old Order values in addition to the new ones. The only way that I'm aware this can be done well today is with a diffgram, so if you don't use DataSets you need to write something similar by yourself or keep state in the server. Anyway, I think most people just exposes the Create and Retrieve operations in webservices.
c) If you decide to not to use DataSets, you should _not_ expose your domain model. That's what Doug and Ted mean. You need to explicitly describe the view of that object model that you want to use, and do it with XML Serializable data types. Doing it with DataSets forces you to make that explicit. Of course, is not the only way, you can map it to simple classes, which leads me to the following point
d) If you are very performance oriented, you only do the C/R operations, and you like to have fine tuned code in each scenario, then Clemens approach is the best. Write the business logic in a stored procedure and load a simple type bound to the data you need for that service. I think this is overkill for projects where you can buy enough hardware to run the application with no problems and you prefer to save in programming hours.
e) If you are doing just ASP.NET applications with mostly read-only data, then DataSets aren't that great. They are easy to work with and easy to bind and cache, but is not that different from working with a simple collection. If you are doing updates of hierarchical structures (i.e. an Order + Order Lines) then it makes more sense, as you can keep track of which row was added, changed, etc). If you are doing Windows Forms apps, then they make a lot of sense. The problem is that I want to have only one business logic layer and reuse it from ASP.NET apps, Windows Forms and WebServices, so I need to choose which data structure I should use. DataSets are quite usable from all of them. Plain CLR objects are not.
Risking to sound arrogant, I'd say that there are two levels of DataSet 'understanding'. The usual trip is first to like them (some people skips this one;), then to see them as an ugly thing designed for novice programmers and move to .net plain classes. Then some people reaches to the next level of enlightment and understands that they are really a very powerful and versatile data container that works OK in most scenarios.
From an exhibitor point of view, TechEd was really good. I only had the chance to go to some BOFs and a couple of presentations (Luca's on ObjectSpaces and a couple of VSIP ones), because I was quite busy in the booth, and when the hall was closed I needed to catch up with email, write some code because I was working on a supercool new feature, and meet people.
I did some personalized DeKlarit demos to Peter Provost, Barry Gervin and Jon Galloway, and they seemed to like it. I just noticed that we all four have in common some issues with the amount of hair in our heads ;).
The project name that VS.NET suggests for the c:\Teched folder is now Project86 so it seems I did 85 demos.
There was a lot of people in the Exhibit hall at all times. We were near the Microsoft products area, and they were very busy. I never saw that many people in an exhibit hall.
The SeaWorld party was good, but I really preferred last year's Smashmouth and Wallflowers (even if I never listen to them) to Whales and Dolphins. I did not get an invitation to the San Diego Zoo one, I missed one regatta with the VSIP team because of the O/R BOF, but I attended to the MSDN Mag one that was good, with lot of 'important' people around.