If you are even nearly as ignorant as every other developer including myself about any administrative aspect of SQL Server 2000 beyond the default install, this tool may be for you. I just installed it and I hate the tool already for what it tells me. Good sign. (Thanks to still-blogless SQL Goddess Kimberly Tripp for the link)
Ted Neward has a crusade against DataSets going on on his blog. At this point in time, I really only ever use them inside a service and only at times when I am horribly lazy or when I code under the influence. Otherwise I just go through the rather quick and mostly painless process of mapping plain data structures (generated from schema) to and from stored procedure calls myself. More control, more interoperability, less weight. I really like when my code precisely states how my app interacts with one of the most important components: the data store.
I don't even use DataSets on ASP.NET web pages anymore. The data binding logic allows to bind against anything and if I have a public or protected property "Customer" on my page class that is a data structure, I can simply have an expression like <%# Customer.Name %> on my page and all is good. Likewise, a DataGrid happily binds against anything that is an ICollection (Array, ArrayList, ...) and the DataGridItem.DataItem property will then contain the individual element. It's just that the design-time support in VS.NET is very DataSet focused and messes things up when you click the wrong things.
DataSets are really cool for Windows Forms apps. By now I've reached a point where I simply conclude that the DataSet class should be banned from the server-side.
The TechEd Europe session search tool starts to reveal what I am up to in Amsterdam ...
CTS308 Building Proseware, Inc. – a non-trivial service-oriented system (just me)
Proseware, Inc. is an online bookseller. A big one. They have warehouses all over Europe, have millions of customers, sell millions of different items and process tens of thousands of orders every day. So imagine they came around to you and asked you to build a system for them. What would you do? In this session, we explain what we would do and what we did. The Proseware Services Demo consists of 14 autonomous, collaborating services, designed with best-practice architecture principles and implemented on Windows Server 2003. Proseware leverages the power of technologies such as Enterprise Services, ASP.NET Web Services, the Microsoft Message Queue, Microsoft Web Services Enhancements 2.0 to implement a large scale, robust, secure and scalable service oriented system that shows how all these technologies can be put to work effectively and that reflects the complexity of real-life enterprise applications.
And this is going to be great fun, too:
ARC230 The Nerd, the Suit and the Fortune Teller (sharing the stage with Pat Helland and Rafal Lukawiecki)
Object Orientation promised to deliver us from all IT evil and to ensure longevity and reuse of software. With today’s business requirements changing faster than it takes to compile an application and an ever-present call for integration, even that approach does not seem to work. However, it seems that Service Oriented Architecture (SOA), Operational Service Orientation of IT departments (MOF, ITIL), Service-Based Interoperability (WS-Guidelines) and Service-Based User Interfaces (messenger, wizards) are quietly converging onto a new paradigm in IT. For the lack of a better name, we call it “Service Oriented Convergence”. Come to this session and see if this concept has any merit and value to you. Rather than endure a typical PowerPoint presentation, you will observe a discussion between: an experienced developer, an unforgiving businessman in charge of IT and a visionary technology innovator. On your behalf, they will battle out their differing points of view and leave you with useful guidance on ways to handle this very important issue that will affect your job, work and future. Oh, and we hope this session is unlikely to be boring.
There is also an updated sessions on the FABRIQ (ARC405, with Arvindra Sehmi) and even a hands-on lab where you can play with the FABRIQ yourself (ARC-IL01, led by newtelligence instructors Achim Oellers and Jörg Freiberger).
I am back home from San Diego now. About 3 more hours of jet-lag to work on. This will be a very busy two weeks until I make a little excursion to the Pakistan Developer Conference in Karachi and then have another week to do the final preparations for TechEd Europe.
One of the three realy cool talks I'll do at TechEd Europe is called "Building Proseware" and explains the the scenario, architecture, and core implementation techniques of Proseware, an industrial-strength, robust, service-oriented example application that newtelligence has designed and implemented for Microsoft over the past 2 months.
The second talk is one that I have been looking forward to for a long time: Rafal Lukawiecki and myself are going to co-present a session. And if that weren't enough: The moderator of our little on-stage banter about services is nobody else than Pat Helland.
And lastly, I'll likely sign-off on the first public version of the FABRIQ later this week (we had been waiting for WSE 2.0 to come out), which means that Arvindra Sehmi and myself can not only repeat our FABRIQ talk in Amsterdam but have shipping bits to show this time. There will even be a hands-on lab on FABRIQ led by newtelligence instructors Achim Oellers and Jörg Freiberger. The plan is to launch the bits before the show, so watch this space for "when and where".
Overall, and as much as I like meeting all my friends in the U.S. and appreciate the efforts of the TechEd team over there, I think that for the last 4 years TechEd Europe consistently has been and will be again the better of the two TechEd events from a developer perspective. In Europe, we have TechEd and IT Forum, whereby TechEd is more developer focused and IT Forum is for the operations side of the house. Hence, TechEd Europe can go and does go a lot deeper into developer topics than TechEd US.
There's a lot of work ahead so don't be surprised if the blog falls silent again until I unleash the information avalanche on Proseware and FABRIQ.
Only this week here at TechEd it became really apparent to me how many people read the things I write here. I've had dozens of "strangers" walking up to me saying "Clemens, I read your blog. Thank you for the things you write.". It's great to meet the real people behind the numbers (I get an insane amount of hits each day for what is effectively a personal opinion outlet) and it's absolutely fantastic to hear when people tell me that I am helping them to do their job better. So what I wanted to say is ... "Thank you for stopping by every once in a while and for helping me to do my job well"
All the wonderful loose coupling on the service boundary doesn't help you the least bit, if you tightly couple a set of services on a common store. The temptation is just too big that some developer will go and make a database join across the "data domains" of services and cause a co-location dependency of data and schema dependencies between services. If you share data stores, you break the autonomy rule and you simply don't have a service.
Separating out data stores means at least that every service has it's own "tablespace" or "database" and that in-store joins between those stores are absolutely forbidden. If you have a service managing customers and a service managing invoices, the invoice service must go through the service front for anything that has to do with customer data.
If you want to do reporting across data owned by several services, you must have a reporting service that pulls the data through service interfaces, consolidates it and creates the reports from there.
Will this all be a bit slower than coupling in the store? Sure. It will make your architecture infinitely more agile, though and allows you to implement a lot of clustering scalability patterns. In that way, autonomy is not about making everything a Porsche 911; it's about making the roads wider so that nobody (including the Porsche) ends up in a traffic jam all the time. It's also about paving roads that not only let you from A to B in one stretch, but also have something useful called "exits" that let you get off or on that road at any other place between those two points.
If you decide to throw out you own customer service and replace it with a wrapper around Siebel, your invoice service will never learn about that change. If the invoice service were reaching over into co-located tables owned by the (former) customer service, you'd have a lot of work to do to untangle things. You don't need to do that untangling and all that complication. As an architect you should keep things separate from the start and make it insanely difficult for developers to break those rules. Having different databases and, better yet, to scatter them over several machines at least at development time makes it hard enough to keep the discipline.
Omar has already posted the announced fix for version 1.6 and has updated all the downloadable files. Go here to get the updated versions. If you run 1.6, get the hotfix, otherwise just get one of the full archives. We should now be stable again. Thanks to Omar and Erv Walter for providing the fix and the repacking so quickly (while I am busy in San Diego at TechEd).
We'll have a fixpack for dasBlog 1.6 within the next two days that will roll back a few internal changes that had been made to improve performance, but unfortunately caused significant instability. The code is already checked into our tree and we're going to have the fix packaged up for download very soon. If you don't have 1.6 installed yet, wait until we have the fix. Within a week we are going to replace the 1.6 verson available from the Gotdotnet workspace with a version that incorporates the fix.
|