"Software + Services" is Microsoft's representation of what a large part of the future of computing is going to be. Microsoft, however, has not done a great job of explaining what "Software + Services" is.

Based on what I have read and heard, let me try to explain it as I see it.

The fundamental question that one has to ask is "Where does computation happen?"

The obvious answer to everyone today is: "Everywhere".

 We compute on mobile devices, appliances, desktops and laptops, and remote computers. We communicate with text and voice.

Everybody understand this. The key question is: "Why?"

I think the answer is because "Hardware is cheap, and data is expensive to move."

The late Jim Gray did an analysis¹ of the economics of distributed computing. His analysis came to two conclusions:

1. Put the computation near the data. Unless you have something that is very compute intensive, it is much cheaper to not move the data.
2. If you need data from multiple sites, push the processing closer to the data source by filtering the data early.

The assumption here is that telecommunication prices drop slower than Moore's Law.  So far this has always been the case.

The natural conclusion is to do the computation where the data naturally resides. In other words: Do what makes sense. Some things will be in the cloud, some things will still be on the desktop. As long as Internet connectivity is not ubiquitous, and not always connected, you may have to cache data somewhere. Depending on the mission criticality of your application, a few seconds could be a long time.

As Ray Ozzie put it in his MIX Keynote, we live in a "World of small pieces loosely joined."

Software + Services means some things will be services in the cloud, others will be software as we know it today.  That includes mobile devices and appliances that we are learning to love and hate, just as we have always done with traditional software.

1. MSR-TR-2003-24 "Distributed Computing Economics"

To further simplify the example, let us assume that the we want to use the certificate to encrypt a message from the client to the service. It is easy to apply what we discuss here to other scenarios.

 

As we discussed in the previous post, we need to generate two certificates, the root certificate that represents the Certificate Authority, and the certificate that represents the identity of the client or service. We will also create a Certificate Revocation List (CRL).

 

We will use a tool called makeCert to generate our certificates. Makecert, which ships with the .NET platform,  allows you to build an X509 certificate that can be used for development and testing. It does three things:

1. Generates a public and private key

2. It associates the key pair with a name

3. It binds the name with the public key.

 

Many of the published examples use makecert to both create and install the certificate. We will do the installation in a separate step because this approach is closer to the use of real certificates.  Separating the certificates also allows the certificates to be installed on many machines instead of just one. This makes distributing certificates to developer machines much easier.

 

First we will create the Root Certificate with the following command:

 

makecert -sv RootCATest.pvk -r -n "CN=RootCATest" RootCATest.cer

 

-n specifies the name for the root certificate authority. The convention is to prefix the name with "CN=" where CN stands for "Common Name"

-r indicates that the certificate will be a root certificate because it is self-signed.

-sv specifies the file that contains the private key. The private key will be used for signing certificates issued by this certificate authority. Makecert will ask you for a password to protect the private key in the file.

 

The file RootCATest.cer will just have the public key. It is in the  Canonical Encoding Rules (CER) format. This is the file that will be installed on machines as the root of the trust chain.

 

Next we will create a certificate revocation list.

 

makecert -crl -n "CN=RootCATest" -r -sv RootCATest.pvk RootCATest.crl

 

-crl indicates we are creating a revocation list

-n is the name of the root certificate authority

-r indicates that this is the CRL for the root certificate, it is self-signed

-sv indicates the file that contains the private key

 

RootCATest.crl is the name of the CRL file.

 

At this point we could install the root certificate, but we will wait until we finish with the certificate we will use in our scenario.  Here we need two files. We will need a CER file for the client machine so that we can install the public key associated with the service. Then we will create a PKCS12  format file that will be used to install the public and private key in the service.

 

The initial step is :

 

makecert -ic RootCATest.cer -iv RootCATest.pvk -n "CN=TempCert" -sv  TempCert.pvk -pe -sky exchange TempCert.cer

 

-n specifies the name for the certificate

-sv specifies the file for the certificate. This must be unique for each certificate created. If you try to reuse a name, you will get an error message .

-iv specifies the name of the container file for the private key of the root certificate created in the first step.

-ic specifies the name of the root certificate file created in the first step

-sky specifies what kind of key we are creating. Using the exchange option enables the certificate to be used for signing and encrypting the message.

-pe specifies that the private key is exportable and is included with the certificate. For message security is this required because you need the corresponding private key. 

 

The name of the CER file for the certificate is specified at the end of the command.

 

Now we need to create the PKCS12 file. We will use a the Software Publisher Certificate Test Tool to create a Software Publisher's Certificate. You use this format to create the PKCS12 file using the pvkimprt tool.

 

cert2spc TempCert.cer TempCert.spc

pvkimprt -pfx TempCert.spc TempCert.pvk

 

We now have four files:

 

RootCATest.cer

RootCATest.crl

TempCert.cer

TempCert.pvk

 

The next step is to install these on the appropriate machines. I could not get certmgr to work properly to do an automated install.  The Winhttpcertcfg tool works for PKCS12 format files, but not CER format files. We will use the MMC snap-in for this.

 

 

Run the mmc snapin tool (type mmc in the Run menu). First we will open the Certificates snap-in.  Choose: Add/Remove Snap-In.

 

 

Then Add the Certficate Snap-In.

 

 

 

When you add the snap-in, choose local computer account for the computer you want to install the certificate (usually the local one).




We want to install the root certificate on both the client and service machines  in the Trusted Root Certificate Store. 

 

 

 

Select that store, right mouse click and install both the RootCATest.cer and RootCATest.crl files.  On the client side you want to install only the public key in the TempCert.cer file.  On the service side only you want to install the PKCS12 format file (TempCert.pvk) which has the private key for the certificate. Install that in the Personal store. For private key installation you will have to provide the password for the PKCS12 file.

 

On the service side, we need to give the identity of the running process (NETWORK SERVICE) the rights to read the private key. We use two tools FindPrivateKey and cacls to do this. Run the following command:

 

for /F "delims=" %%i in ('FindPrivateKey.exe My LocalMachine -n "CN=TempITNCert" -a') do (cacls.exe "%%i" /E /G "NT AUTHORITY\NETWORK SERVICE":R)

 

Remember to delete these certificates when you are finished with them.

Working with X509 certificates can be very frustrating for WCF developers.

This is the first of two posts. In this post I will explain just enough of the background for X509 certificates so that I can explain in the next post how to create and use certificates during .NET development with WCF.   The second post is here.

I do not know any good books for a developer that explains how to use certificates. Even the excellent books on WCF just give you the certificates you need to get the sample code to work. They do not really explain to you why you are installing different certificates into different stores, or how to generate the certificates you need to get your software to work. Very often the examples run on one machine with the client and service sharing the same store. This is not a realistic scenario.

Obviously I cannot explain all about certificates in one blog post. I just wish to share some knowledge. Hopefully it will spare you some grief.

Here is the problem I want to solve.

Suppose you have a set of web services that is accessed by either an ASP.NET or rich client. The service requires the client application to use an X509 certificate to access the service. This could be to encrypt the data, to identify the client, to sign the data to avoid repudiation, or for a number of other reasons. How do you install the certificates on the client and service machines?

Certificate technology is based on asymmetric encryption. 

In the encryption scenario, the client would use the public key of the service to encrypt the traffic.  The service would use its private key to decrypt the message.  In the identification scenario the service would use the public key of the client to identify a message signed with the client's private key.

One of the key issues is how you can be sure that the public key is associated with a given identity. Perhaps somebody substituted their key for the one you should be using.  Perhaps somebody is hijacking calls to the service, or you made a mistake in the address of the service.  A classic example of these types of vulnerabilities  is the "man in the middle attack".  Another key issue is that the private key cannot be read or modified by unauthorized parties.

Public Key Infrastructure (PKI) is the name for a technology that uses a certificate authority (CA) to bind the public key to an identity. This identity is unique to the certificate authority. X509 is a standard for implementing a PKI.  An X509 certificate represents an association between an identity and a public key.

An X509 certificate is issued by a given Certificate Authority to represent its guarantee that a public key is associated with a particular identity. Depending on how much you trust the CA, and the amount of identity verification the CA did, would determine how much trust you have in the certificate. For example VeriSign issues different types of certificates depending on how much verification was done. Sometimes organizations will be their own certificate authorities and issues certificates because they want the maximum amount of control.

This relationship between a CA and its issued certificates is represented in the "chain of trust". Each X509 certificate is signed with the private key of the CA. In order to verify the chain of trust you need the CA's public key.  If you are your own CA authority you can distribute the X509 certificate representing this "root certificate".  Some browsers and operating systems install root certificates as part of their setup. So the manufacturer of the browser or operating system is part of the chain of trust.

The X509 standard also includes a certificate revocation list (CRL) which is a mechanism for checking whether a certificate has been revoked by the CA.  The standard does not specify how often this checking is done. By default, Internet Explorer and Firefox do not check for certificate revocation. Certificates also contain an expiration date.

Another approach to trust is called "peer to peer" trust, or "web of trust".  Given the difficulties of peer trust it is not practical for most Internet applications. It can, however, make development scenarios simpler. Your development environment, however,  should mimic your deployment environment.  Hence I do not recommend using peer to peer trust unless that is practical for your deployed solution.

There are various protocols for transmitting certificates.  We will be interested in two of them.

The Canonical Encoding Rules (CER) protocol will be used to digitally transmit the public key of a given identity. The PKCS12 protocol will be used to transmit the public and private keys. The private key will be password protected.

The next post will describe the mechanisms for creating and installing certificates in a .NET development environment.

"this is a well-known problem with code files that have desigable classes in them - the class that is to be designed has to be the first class in the file.  If you do the same thing in windows forms you get the following error: the class Form1 can be designed, but is not the first class in the file. Visual Studio requires that designers use the first class in the file. Move the class code so that it is the first class in the file and try loading the designer again."

It turns out I had changed a struct that was defined first in my file to a class. I moved that class to the end of the file and "mirabile dictu" everything worked.

So if this is a well known problem, why can't we get an error message just like in the Windows Forms case?

While it was clearly my mistake, Microsoft has a share of the blame here. Clearly this requirement makes it easier to build the workflow designer. It would have been just as easy to check if this class was not defined first, and issue an error message.

You can use the debugger in Visual Studio 2008 to step into some of the .NET Enterprise Libraries. This is a feature I asked for a number of years ago. Scott Guthrie just blogged about this. Here is his post and it includes the list of libraries to which this applies and some information about how to do it:

http://weblogs.asp.net/scottgu/archive/2008/01/16/net-framework-library-source-code-now-available.aspx

 Here is a short MSDN video about this:

http://www.microsoft.com/uk/msdn/screencasts/screencast/304/Debugging-Into-the-NET-Framework-Source-Code-with-Visual-Studio-2008.aspx

The Windows Workflow Foundation (WF) ships with a Policy Activity that allows you to execute a set of rules against your workflow. This activity contains a design time rules editor that allows you to create a set of rules. At run time, the Policy Activity runs these rules using the WF Rules engine.

Among other features, the rules engine allows you to prioritize rules and to set a chaining policy to govern rules evaluation.  The rules engine uses a set of Code DOM expressions to represent the rules. These rules can be run against any managed object, not just a workflow. Hence, the mechanisms of the rules engine have nothing to do with workflow. You can actually instantiate and use this rules engine without having to embed it inside of a workflow. You can use this rules engine to build rules-driven .NET applications.

I gave a talk at the last Las Vegas VSLive! that demonstrates how to do this. The first sample in the talk uses a workflow to demonstrate the power of the rules engine. The second and third samples use a very simple example to demonstrate how to use the engine outside of a workflow.

Two problems have to be solved.  You have to create a set of Code DOM expressions for the rules. You have to host the engine and supply it the rules and the object to run the rules against.

While the details are in the slides and the examples, here is the gist of the solution.

To use the rules engine at runtime, you pull the workflow rules out of some storage mechanism. The first sample uses a file. A WorkflowMarkupSerializer instance deserializes the stored rules to an instance of the RuleSet class.  A RuleValidation instance validates the rules against the type of the business object against which you will run the rules against. The Execute method on the RuleExecution class is used to invoke the rules engine and run the rules.

How do you create the rules? Ideally you would use some domain language, or domain based application, that would generate the rules as Code DOM expressions. If you were masochistic enough, you could create those expressions by hand.

As an alternative, the second sample hosts the Workflow rules editor dialog (RuleSetDialog class) to let you create the rules. Unfortunately, like the workflow designer, this is a programmer's tool, not a business analyst's tool. A WorkflowMarkupSerializer instance is used to serialize the rules to the appropriate storage.

I would be interested in hearing about how people use this engine to build rules driven applications.

My series of four digitial articles have been published by Addison-Wesley. You can get the links to purchase them and the associated source code from my web site.

I have tried to explain, in practical terms, what you need to know to actually build real world software using Windows Workflow. There is a tiny amount of theory to explain the underpinnings. The vast majority of the explanation uses code examples to illustrate all the key points. The last shortcut in the series has two extended examples that illustrate how to build custom activities.

If you were to believe some of the more vocal advocates of the agile approach to building software, you would think that the word planning is evil. If you change the comparison to agility and discipline, then the contrast is more interesting.

This is exactly what Barry Boehm and Richard Turner do in their book "Balancing Agility and Discipline". They argue that the agile approach to software development, and the discipline approach to software development have much to teach each other. Any given project must achieve the right mix of agility and discipline based on the nature of the project.

One of the more interesting graphs in their book makes this point clear:

You have to understand:

How mission critical your project is?

How many people are on the project?

How experienced are your people?

Do the people on your project handle uncertainty well, or do they prefer order?

How dynamic can the changes to requirements be?  Do you understand the domain model well?

As the graph makes clear, the more experienced developers you have that can handle vagueness and ambiguity, the more likely you can use more agile methods. On the other hand, the more mission critical, the more lives at stake, and the larger the project, the more project discipline you need.

This is not an all or nothing choice. As the book makes clear, most of your projects will need some combination of agility and discipline. Nonetheless, no method is a silver bullet.

Arthur Pyster (the Deputy Chief Information Officer for the FAA) writes in his foreword that even building air traffic control systems can incorporate some agile processes.

I had not read their book in 2005 when I made this entry to my blog: http://www.reliablesoftware.com/DasBlog/PermaLink,guid,847f84e5-3629-400b-807b-c6f8a1345454.aspx. Reading this book reinforced my belief that one must continually evaluate the risk associated with a project, and adopt the appropriate methods that reduce that risk.

Here are good instructions on how to install RC1 for the .NET Framework 3.0: http://blogs.msdn.com/pandrew/archive/2006/09/07/745701.aspx. People, including myself, have been having problems getting the Workflow Extensions for Visual Studio 2005 installed. I moved the installer file (Visual Studio 2005 Extensions for Windows Workflow Foundation RC5(EN).exe) to a different directory from the other installation files. The workflow extensions then installed just fine.

David Chappell (http://www.davidchappell.com/HTML_email/Opinari_No16_8_06.html) argues that SOA may not foster the service reuse that everyone has been hoping for. I think his analysis is correct, but I think with business services we at least have a reasonable hope of achieving reuse. Here we are least dealing with the way things actually happen in the world as opposed to programmer abstractions such as objects or components. That combined with the looser coupling of services gives me some hope.

The reason why frameworks like .NET are successful is they reflect years and years of experience with programming problems. Many examples of reuse (such as file systems and compilers) are so embedded in our experience that we no longer see them for what they are.

Reuse may fail here as well for all the reasons mentioned in David Chappell's analysis. At least now I feel we are on the right track.

The Reference Model for Service Oriented Architecture defines a vocabulary for building service-oriented systems. Put together by a technical committee operating under the auspices of the OASIS standards organization, it is the result of individuals and organizations representing vendors, users, governments, consulting organizations, and academic institutions.

The Reference Model (RM) sees SOA as a means for organizing and using distributed capabilities that may be under the control of different ownership domains. The RM is not an architecture. It does not attempt to make any architecture normative. It does not try to make any standard or set of standards normative.

It does provide a common set of semantics that can be used across different implementations. This does sound rather fancy. Nonetheless, just like Moliere's bourgeois gentlemen that found out he was speaking prose all his life, many industries have been using reference models all along. They just never had to define them explicitly.

An architect for a residential dwelling knows that if they use the term door or window, the builder will understand what is meant. There are widely varied implementations of doors and windows depending, for example, if you are building a space station or an igloo. Nonetheless, everyone knows what the terms mean. Many of these terms are codified in building codes, and by standards bodies, and have evolved over the years. The software architecture community moves too quickly for such evolution; this is where standards organizations can help.

Software architectures, for sure, can have views and viewpoints, but the terms in which they are discussed have to be understood.

The core concepts that the RM discusses are service, visibility, execution context,  service description, real world effect,  interaction, and contract and policy.

I will discuss these core concepts over the next few posts.

None of this work is going on in isolation, or is it intended to denigrate other work such as the WS* specifications, or organizations such as the ISO, IEEE, IETF, the Ontolog Forum or other groups. The reference model just supplies standard definitions so that it becomes easier for each group to communicate with the others.

I have updated the workflow examples on my site to the most recent Workflow version.

I would like to thank all those who helped me achieve an Microsoft MVP award for Visual Developer - Solutions Architect.

"You are so young; you stand before beginnings. I would like to beg of you,

dear friend, as well as I can, to have patience with everything that remains unsolved in your heart. Try to love the questions themselves, like locked rooms and like books written in foreign languages. Do not now look for the answers. They cannot now be given to you because you could not live them. At present you need to live the question."

• Rainer Maria Rilke, Letters to a Young Poet

I learned programming in high school from a Fortran IV manual, which was like learning how to drive a car from the owner's manual—unexciting. Later, after taking an operating systems course at MIT, I gave up entirely on programming as a profession. I did not want to spend my life doing the same thing over and over again.

What made me change my mind and become a professional programmer? In large part it was Gerald M. Weinberg's The Psychology of Computer Programming, which I first read in 1982. Weinberg not only demonstrated that programming was more than technology, it is a social activity, but he showed how the social element related to the technical. In essence, he identified and addressed the types of fundamental questions that Rilke advised the young poet Franz Kappus to study. Such as:

• “What does it mean when we say a program is good?” I learned from Weinberg that a good program is as much a matter of cultural fit as technological merit. A designer has to understand that tradeoffs are made not only among technical factors, but among technical, social and economic constraints. Too often, I have seen engineers try to build the “perfect” product while ignoring ease of use or budget constraints.

• “How do you get programmers to work together as a team?” One programmer cannot do it all. Different people have different skills, different skills are needed at different parts of the project.

• “What is leadership all about?” How do you manage change and performance? Why do many managers manipulate programmers and tread them poorly and then wonder why they get poor results?
• “How do you find good programmers?” And just what does it mean to be a good programmer? Weinberg was one of the first to point out the stupidity of aptitude testing for programmers, and the importance of understanding individual psychology in dealing with programmers.

Weinberg confirmed my own intuition that software could have an enormous impact on society, and his discussion of programming as a social activity helped explain much of the “strange behavior” I saw around me as I began working on my first programs. For example, during one of my first projects, I saw that the inability of certain people to work together had more impact on the project’s outcome than the technological issues being debated.

Weinberg examined what a naïve programmer would consider just technical topics and demonstrated how the elements of human personality and interactions between people had just as much, if not more influence over the outcome of a computer programming project than the technical issues and debates.

By understanding the importance of questions such as these, even if not every question can be answered in every situation, my value as a programmer and designer transcends whatever today’s technology du jour happens to be. I would have to say that Weinberg’s book took years off my apprenticeship, and saved me much aggravation.

To this day, I view programming primarily as a human activity, with the technical merits secondary. This does not mean you can ignore the technical merits. What makes a programmer really great is not technical genius, but an understanding of the human context of what he or she is doing. Any programmer who creates a truly revolutionary and world-changing program understands this. Others did not, or did not care to, and their contributions are hidden behind or overwhelmed by others’ accomplishments.

It is incredible that a twenty-five year old programming text containing examples illustrated with technologies that many programmers today cannot even conceive of—I recently taught a programming class where not one of the students had any idea what a punched card or paper tape was—is still a great book.

Here is my final dnrTV session: http://dnrtv.com/default.aspx?showID=24. It covers advanced topics in Windows Workflow Foundation such as synchronization, transactions, and compensation.

I have signed the petition at: http://www.mwdadvisors.com/resources/stop-the-madness.php. SOA does not need another buzz word. I think SOA 2.0 ranks belong even ESB on the buzz word list.

This is also an experiment. We have heard of viral marketing. Let us see if we can have viral common sense.