Dag König

Finally! Enterprise Library is released

Take a look at it!

Enterprise Library is a collection of seven reusable and extensible application blocks for enterprise .NET development. The blocks in Enterprise Library assist in the following scenarios: Caching, Configuration, Cryptography, Data Access, Exception Handling, Logging and Security.

Don't say that programming isn't a dirty work

This picture is from a colleague's keyboard. (Yes, I have his permission to publish these pictures.)

You may wonder what he works with. I wonder also. I think that he frequently work on the Microsoft platform. I will not tell you which company he works for, but it is not mine, Know IT. RegMaid.Exe will not help here. The worst thing is that I think that the keyboard has transformed to a new life form with a will on its own.

The three toughest questions in the world

Here is a list is of the three toughest questions in the world. I list them in no special order:
* Does God exist?
* What happens when you die?
* When should I use Enterprise Services?

It is the last question that I will discuss in this article.

It exists unfortunately no dead certain reply on this question. The reply depends on many different things: both of technical aspects and political aspects. The two most common replies on the question are the following:

1. Use Enterprise Services only when you need its services.
2. Always use Enterprise Services.  It is a part of the infra structure.

I am a "Reply 1" person. This conclusion has I, among other things, achieved when reading the book "Improving .NET Application Performance and Scalability" from Microsoft Patterns & Practices Team.

But as I earlier wrote, it can exist other reasons for choosing "Reply 2" instead. Examples on other factors that can play in:

1) Production department experiences that it has a better control of the environment with the aid of Component Service Explorer.
2) The organization does not permit saving connection strings in the registry or in configuration files.

Regardless of the position taken in this never-ending question, it is important to know what functionality that Enterprise Services provides. Without that knowledge, one can never decide the way to go in a concrete situation. Because Of that I want to recommend a new article by Microsoft, "Microsoft Enterprise Services". I recommend it to all that has to design and implement enterprise application on the Microsoft platform. It is a good document to fresh up the knowledge of this technology.

Nokia N-Gage, recharged for the last time?

A rumor is spreading on the net. I think that it however sounds a bit strange.  I thought that they soon ought to release a new model. However, I can understand if this takes place. I have not seen anyone using such a telephone. Well, now I have to buy another phone or gaming machine to use on the subway. Probably I will newer buy one anyway.

Remember its only a rumor and I got it from this place.

Different stakeholders benefits of SOA

Enterprise Architectural Space Organizing Table is a system that tries to describe which artifacts that should be produced when developing an Enterprise application. This could be described as a two-dimensional table where the rows are different architectural viewpoints and the columns interrogatives that have to be responded to. Some different variants on these tables exist. For this article, I have chosen to use Microsoft's own alternative. It is described in the following document.

Each viewpoint has one or more different stakeholders. I have identified four in my simplified table. These are:
1. CEO, CIO
2. Architect
3. Developer
4. System Engineer

This article tries to describe some benefits that each of those stakeholders can get from SOA. Because of lack of time and scope I can only make a short review of what I have found.

CEO, CIO
• Reusing existing systems and data.
• A competition advantage in the long-term. (I believe that SOA will become equally common and important as the Internet is for companies today.)
• Leverage the company's heterogeneous environments.

Architect
• Probably the best design paradigm that describes the realities of today's enterprise.
• A clear description of services, interfaces and communication between these.
• An effective way to design stable, but yet agile systems.

Developer
• Possibility to reuse components and other things such as language knowledge.
• Possibility to implement a solution in the best environment for that solution. For example, some services are best done in Java while other in .NET.
• Encouraging the reusing of domain models and data models.

System Engineer
• Simpler production environment.
• Easy to build secure communication between the different services. All services communicate with TCP/IP.
• Simple to load balance through doing “scale-out”.
• The infrastructure can be metadata-driven.

Architecture of WWW - very interesting new recommendation document from W3C

W3C have upgraded the document “Architecture of the World Wide Web, Volume One” to the status of Recommendation. This is a fundamental document that everyone that working seriously with Internet and the technologies that it consists of should be aware about.

This is part from the abstract of this document.
The World Wide Web uses relatively simple technologies with sufficient scalability, efficiency and utility that they have resulted in a remarkable information space of interrelated resources, growing across languages, cultures, and media. In an effort to preserve these properties of the information space as the technologies evolve, this architecture document discusses the core design components of the Web. They are identification of resources, representation of resource state, and the protocols that support the interaction between agents and resources in the space. We relate core design components, constraints, and good practices to the principles and properties they support.

Read it here.

Patterns & Practices Digest

Yesterday, I found an interesting PDF from "Patterns & Practices Group". It is a summary of some new interesting publications that they recently have published or that comes soon. It is not long, only 16 pages.

Read it here.

It is too easy, doing web services on the Microsoft platform

Isn't easy always good, especially when developing complex systems? I would say no, it is not always a good thing.

We currently have this kind of problem with Microsoft's implementation of web services. The situation is almost the same as we had with Visual Basic earlier. This was before it became a serious programming language for larger, multilayered, systems. It was extremely simple to build an application. All you had to do was to draw some controls and hit the F5 button. I remember that Gartner Group advised the market some years ago not to develop systems with Microsoft products because of this.
Unfortunately, the same now applies to web services. They too are very simple to create. If you in addition use DataSets as transfer objects then you are in serious trouble and probably heading in the wrong direction.

There are no easy ways to implement professional web services today.
In the future we will have better tools but this is not the case right now. You have to roll up our shirt-sleeves and do the messy work ourselves.

This conclusion and much more has Aaron Skonnard described in a new article in the MSDN Magazine. The following are some comments on his article. 

Today we have two common techniques to define service contracts. "Implementation-First" is the method that Microsoft, and probably other vendors, uses by default. You first write your components and from these the underlying platform produces the contracts for you. This is the easy, but erroneous, way to go.

"Contract-First" is the other technique to use. It is this method that both Aaron and I prefer. He does a short introduction to this method. In the rest of this article I'll do make some comments on that method. Some are drawn from experience I have gained the last year when I have been working for a company that right now implements a service oriented architecture in a heterogeneous environment.

The two languages that you have to learn when designing web services according to contract-first is Wsdl and Xsd. Aaron suggests that we should start, after we have designed the system, to write the Wsdl files. From my experience is it very important that we don’t write the Wsdl first. We should start by defining types. A type is, for example, a civil number, implemented as a simple type, or an address, implemented as a complex type. Both simple types and complex types are parts of the Xsd specification. When you have these fundamental types you start combining them to even more complex types. It will ends with one complex type that describe the request of a method in the web service and one that describes the response. When you have done this, then you start writing the Wsdl file. This way is sometimes called "schema-first".

Why schema (Xsd) before the web service description (Wsdl)? If we design the schemas first, and if we are serious about this, we should only have one schema repository for the whole company or organization, the interoperability and reuse will be easier to maintain. If we start with the Wsdl it could be tempting to include the schemas in that file. It is this technique that Microsoft use when they atomically generate the Wsdl. This is called Russian Doll because every type and sub type is contained in the same file.

A new book from Patterns & Practices about testing

I haven't seen this one before. I think it's a new one from this group within Microsoft. I have only briefly glanced through it contents. It looks interesting.

This guide presents recommendations on how to test .NET application blocks
during their development life cycle, during customization, and during their integration with an application. The recommended process can be easily used no matter what software development life cycle you use to develop, customize, and integrate these blocks.

Download it here.

You probably already use a DSL today

I'm currently reading a very good book. It the best I have read in months, probably the best computer book I read in 2004. The book, Software Factories, is a very comprehensive book. It is very substantial.

A big thing in that book is DSL:s (Domain Specific Languages). A DSL is in contrast to, for example, UML not a general propose language. One of the problems with languages that try to include everything is that it is harder for tools to translate the model into source code. Models used for computation must be more precise than UML could provide.

I'll try to give an example of this. This example is inspired from the book. DSL has been introduced as something that will come in the future. But if you write WinForms application with .NET you already use it today. Yes, the WinForm designer is a type of DSL language. The designer view is a tool that you use to draw the layout of the form. The source code is generated from this view. If you then make changes in the source code, the designer will be updated, synchronized, to reflect the changes that have been made. (This will happen almost immediately. It is not as good as the class design examples in Visual Studio 2005.)
With UML this synchronization should be almost impossible. With UML, if we are lucky, we could generate source code ones.

EXAMPLE
Here is a walk through that you could do to get a taste of DSL today. All you need is Visual Studio.NET.
1) Start by doing a new project. Create the project from a Window Application template. It doesn't matter if you use Visual Basic or C#. (But you can't use C++. The form designer for C++ will be included in the next version of Visual Studio.)
2) Go ahead and draw some controls on the form. When you have played with that for a while you could choose to see the code that has been generated. You do that by right-clicking on the form and choose "View Code".
3) The generated code will be hidden when you firsts open the code view. You have to click on the plus sign to the left of the text "Windows Form Designer generated code" to reveal the code.
4) Try to change something, for example the position of one control. This is done with the Location property. Switch back to the designer and the code change will be synchronized with this view.
5) Try to split the Visual Studio window in two panes so you see both the designer and the code at the same time. Change some more code. The form designer will not change immediately when the code changes. In the new class designer this will happens. Here, you have to click somewhere in the designer first.