I just deleted a „direct marketing message“ for a lottery with the subject line: “[SPAM] category B winner”. The fact that a spammer labels his spam as [SPAM] is either funny, fair or exhibits an unprecedented case of idiocy. I still have to make up my mind.

By the way, my little experiment started August 8^th, where I set up an unmonitored and unused mail account just to see how much spam it attracts by just “being out there” is starting to yield the expected result.

(Before you follow the above links, I recommend that you have a virus scanner running that monitors your web traffic; the “spamthisaccount” page has literal copies of the e-mails, including attachments. We are scanning for viruses and right now there’s nothing harmful in the content directory, but you never know when it hits ….)

Steve Swartz, who is one of my very good personal friends and who is, that “personal function” aside, Program Manager in Microsoft’s Indigo team and also was the lead architect for a lot of the new functionality that we got in the Windows Server 2003 version of Enterprise Services (COM+ 1.5 for the old fashioned folks), wrote a comment on my previous post on this topic, where I explained how you can get the XML configuration story of the Framework to work with Enterprise Services using the .NET Framework 1.1.

In response to what I wrote, someone asked whether this would also work on Windows XP, because I was explicitly talking about Windows Server 2003. Steve’s answer to that question completes the picture and therefore it shouldn’t be buried in the comments. Steve writes:

In fact, this will work on XP and Windows Server 2003 so long as you have NETFX 1.1. The field has been there since XP; in NETFX 1.1, we set the current directory for the managed app domain.

This field was originally added to configure unmanaged fusion contexts. In that capacity, the field works with library and server apps alike. In its capacity as a setter of current appdomain directory, it works less well with library apps (natch).

A long while back, I wrote about a hack to fix the dllhost.exe.config dilemma of Enterprise Services. That hack no longer works due to changes in the Framework, but the good news is there is an “official” and very easy solution for this now. Unfortunately there is no documentation on this (or at least it’s not easy enough to find that I could locate it) and Google only yields a few hints if you know exactly what you are looking for. So, index this, Google!

What I call the “config dilemma” of Enterprise Services is that because all out-of-process ES applications are executed using the surrogate process provided by %SystemRoot%\System32\dllhost.exe and the runtime is loaded into that process, the default application configuration file is dllhost.exe.config, must reside just next to dllhost.exe (in System32) and is therefore shared across all out-of-process Enterprise Services applications.

That makes using the XML configuration infrastructure for Enterprise Services very unattractive, to say the least.

Now, with COM+ 1.5 (Windows Server 2003) and the .NET Framework 1.1, things did change in a big way.

To use per-application application configuration files, all you have to do is to create an (possibly otherwise empty) “application root directory” for your application in which you place two files: An application.manifest file (that exact name) and an application.config file. Once your application is registered (lazy or using the RegistrationHelper class or through regsvcs.exe), you will have to configure the application’s root directory in the catalog – that can be done either programmatically using the catalog admin API (ApplicationDirectory property) or through the Component Services explorer as shown above.

The picture shows that the example that you can download using the link below is installed at “c:\Development\ES\ConfigTest\ESTest” on my machine and has these two said files sitting right there.

The application.manifest file content is embarrassingly simple

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
</assembly>

and the application.config isn’t complicated either:

<?xml version="1.0"?>
<configuration>
  <appSettings>
     <add key="configBit" value="This rocks!"/>
  </appSettings>
</configuration>

These two files, placed into the same directory and properly configured as shown in the above picture, let this class

       public class SimpleComponent : ServicedComponent
       {
        public string GetConfigBit()
        {
            return ConfigurationSettings.AppSettings["configBit"];
        }
       }

yield the expected result for GetConfigBit(): “This rocks!”

I am in a blogging mood today … Here are some thoughts around composite metadata. Sorry for the bold title ;)

* * *

Whenever I am asked what I consider the most important innovation of the CLR, I don’t hesitate to respond “extensible metadata” coming in the form of custom attributes. Everyone who has followed this blog for a while and looked at some of the source code I published knows that I am seriously in love with attributes. In fact, very few of the projects I write don’t include at least one class derived from Attribute and once you use the XmlSerializer, Enterprise Services or ASMX, there’s no way around using them.

In my keynote on contracts and metadata at the Norwegian Visual Studio .NET 2003 launch earlier this year, I used the sample that’s attached at the bottom of this article. It illustrates how contracts can be enforced by both, schema validation and validation of object graphs based on the same set of constraints. In schema, the constraints are defined using metadata (restrictions) inside element or type definitions, and in classes, the very same restrictions can be applied using custom attributes, given you have a sufficient set of attributes and the respective validation logic. In both cases, the data is run through a filter that’s driven by the metadata information. If either filter is used at the inbound and outbound channels of a service, contract enforcement is automatic and “contract trust” between services, as defined in my previous article, can be achieved. So far, so good.

In my example, the metadata instrumentation for a CLR type looks like this:

      [System.Xml.Serialization.XmlTypeAttribute(
           Namespace="urn:schemas-newtelligence-com:transactionsamples:customerdata:v1")]
       public class addressType
       {
              [Match(@"\p{L}[\p{L}\p{P}0-9\s]*"),MaxLength(80)]
              public string City;
              public countryNameType Country;
              public countryCodeType CountryCode;
              [MaxLength(10)]
              public string PostalCode;
              [MaxLength(160)]
              public string AddressLine;
      }

… while the corresponding schema is a bit better factored and looks like this:

    <xsd:simpleType name="nameType">
              <xsd:restriction base="xsd:string">
                     <xsd:pattern value="\p{L}[\p{L}\p{P}0-9\s]*" />
              </xsd:restriction>
    </xsd:simpleType>
    <xsd:complexType name="addressType">
              <xsd:sequence>
                     <xsd:element name="City">
                            <xsd:simpleType>
                                   <xsd:restriction base="nameType">
                                          <xsd:maxLength value="80" />
                                   </xsd:restriction>
                            </xsd:simpleType>
                     </xsd:element>
                     <xsd:element name="Country" type="countryNameType" />
                     <xsd:element name="CountryCode" type="countryCodeType" />
                     <xsd:element name="PostalCode">
                            <xsd:simpleType>
                                   <xsd:restriction base="xsd:string">
                                          <xsd:maxLength value="10" />
                                   </xsd:restriction>
                            </xsd:simpleType>
                     </xsd:element>
                     <xsd:element name="AddressLine">
                            <xsd:simpleType>
                                   <xsd:restriction base="xsd:string">
                                          <xsd:maxLength value="160" />
                                   </xsd:restriction>
                            </xsd:simpleType>
                     </xsd:element>
              </xsd:sequence>
       </xsd:complexType>

The restrictions are expressed differently, but they are aspects of type in both cases and semantically identical. And both cases work and even the regular expressions are identical. All the sexiness of this example aside, there’s one thing that bugs me:

In XSD, I can create a new simple type by extending a base type with additional metadata like this

<xsd:simpleType name="nameType">
       <xsd:restriction base="xsd:string">
              <xsd:pattern value="\p{L}[\p{L}\p{P}0-9\s]*" />
       </xsd:restriction>
</xsd:simpleType>

which causes the metadata to be inherited by the subsequent element definition that again uses metadata to further augment the type definition with metadata rules:

<xsd:element name="City">
       <xsd:simpleType>
              <xsd:restriction base="nameType">
                     <xsd:maxLength value="80" />
              </xsd:restriction>
       </xsd:simpleType>
</xsd:element>

So, XSD knows how to do metadata inheritance on simple types. The basic storage type (xsd:string) isn’t changed by this augmentation, it’s just the validation rules that change, expressed by adding metadata to the type. The problem is that the CLR model isn’t directly compatible with this. You can’t derive from any of the simple types and therefore you can’t project this schema directly onto a CLR type definition. Therefore I will have to apply the metadata onto every field/property, which is the equivalent of the XSD’s element declaration. The luxury of the <xsd:simpleType/> definition and inheritable metadata doesn’t exist. Or does it?

Well, using the following pattern it indeed can. Almost.

Let’s forget for a little moment that the nameType simple type definition above is a restriction of xsd:string, but let’s focus on what it really does for us. It encapsulates metadata. When we inherit that into the City element, an additional metadata item is added, resulting in a metadata composite of two rules – applied to the base type xsd:string.

So the about equivalent of this expressed in CLR terms could look like this:

    [AttributeUsage(AttributeTargets.Field)]
    [Match(@"\p{L}[\p{L}\p{P}0-9\s]+")]
    public class NameTypeStringAttribute : Attribute
    {
    }

    [System.Xml.Serialization.XmlTypeAttribute(
       Namespace="urn:schemas-newtelligence-com:transactionsamples:customerdata:v1")]
    public class addressType
    {
        [NameTypeString,MaxLength(80)]
        public string City;
       
        …
    }

Now we have an attribute NameTypeString(Attribute) that fulfills the same metadata containment function. The attribute has an attribute. In fact, we could even go further with this and introduce a dedicated “CityString” meta-type either by composition:

   [AttributeUsage(AttributeTargets.Field)]
   [NameTypeString,MaxLength(80)]
      public class CityStringAttribute : Attribute
    {

    }

 … or by inheritance

    [AttributeUsage(AttributeTargets.Field)]
    [MaxLength(80)]
       public class CityStringAttribute : NameTypeStringAttribute
    {
    }

Resulting in the simple field declaration

    [CityString] public string City;

The declaration essentially tells us “stored as a string, following the contract rules as defined in the composite metadata of [CityString]”.

Having that, there is one thing that’s still missing. How does the infrastructure tell if an attribute is indeed a composite and that the applicable set of metadata is a combination of all attributes found on this attribute and attributes that are declared on itself?

The answer is the following innocent looking marker interface:

    public interface ICompositeAttribute
    {  }

If that marker interface is found on an attribute, the attribute is considered a composite attribute and the infrastructure must (potentially recursively) consider attributes defined on this attribute in the same way as attributes that exist on the originally inspected element – for instance, a field.

    [AttributeUsage(AttributeTargets.Field)]
    [Match(@"\p{L}[\p{L}\p{P}0-9\s]+")]
    public class NameTypeStringAttribute : Attribute, ICompositeAttribute
    {   }

Why a marker interface and not just another attribute on the attribute? The answer is quite simple: Convenience. Using the marker interface, you can find composites simply with the following expression: *.GetCustomAttributes(typeof(ICompositeAttribute),true)

And why not use a base-class “CompositeAttribute”? Because that would be an unnecessary restriction for the composition of attributes. If only the marker interface is used, the composite can have any base attribute class, including those built into the system.

But wait, this is just one side of the composition story for attributes. There’s already a hint on an additional composition quality two short paragraphs up: *.GetCustomAttributes(typeof(ICompositeAttribute),true). The metadata search algorithm doesn’t only look for concrete attribute types, but also looks for interfaces, allowing the above expression to work.

So how would it be if an infrastructure like Enterprise Services would not use concrete attributes, but would also support composable attributes as illustrated here …

    public interface ITransactionAttribute
    {
        public TransactionOption TransactionOption
        {
            get;
        }
    }

    public interface IObjectPoolingAttribute
    {
        public int MinPoolSize
        {
            get;
        }

        public int MaxPoolSize
        {
            get;
        }
    }

In that case, you would also be able to define composite attributes that define standardized behavior for a certain class of ServicedComponents that you have in your application and should all behave in a similar way, resulting in a declaration like this:

      public class StandardTransactionalPooledAttribute :
        Attribute, ITransactionAttribute, IObjectPoolingAttribute
    {
    }

      [StandardTransactionalPooled]
    public class MyComponent : ServiceComponent
    {

    }

While it seems to be an “either/or” thing at first, both illustrated composition patterns, the one using ICompositeAttribute and the other that’s entirely based on the inherent composition qualities of interface are useful. If you want to reuse a set of pre-built attributes like the ones that I am using to implement the constraints, the marker interface solution is very cheap, because the coding effort is minimal. If you are writing a larger infrastructure and want to allow your users more control over what attributes do and allow them to provide their own implementation, “interface-based attributes” may be a better choice.

Bob Cancilla’s CNet article is so full of FUD that I can’t help but making a few more comments and post a few questions. Unfortunately, his email address isn’t mentioned near the article … therefore I have to blog it. Mr. Cancilla, feel free to use the comments feature here, if you find this…

Unlike IBM, Microsoft falls short when it comes to helping customers use standards in a productive, cost-effective way. […] Sure, both companies have worked closely to develop and promote a sizable number of important industry standards that will continue to have a big impact on the way business is conducted in the foreseeable future. But cool specs are meaningless to the IT people who must actually assemble all those standards into real business solutions. That's where the rubber meets the road for Web services. Redmond's approach to Web services is a dead-end of closed, Windows-only systems that lock customers into a single computing model. Customers don't have the freedom to choose the best hardware or operating system. Where does that leave the millions of users who rely on non-Microsoft platforms such as mainframes, Unix or Linux?

First of all, Mr. Cancilla, you haven’t understood Web Services, at all. Web Services are about connecting systems, irrespective of operating system, application platform or programming model. Redmond’s approach to web services is just like IBM’s and BEA’s and Sun’s and Oracle’s approach to Web Services. All of them think they have a superior application platform and their embrace of Web Services serves to make that platform the hub of communication for their and all other systems that are (for them: unfortunately) running on other platforms in the reality of today’s heterogeneous IT landscape. It’s about opening services for access by other platforms. I wish I would know how you get the idea that “lock-in” and “Web Services” belong in the same sentence?

Secondly, show me an environment that enables the average programmer to be more productive and hence more cost effective when developing XML and Web Services solutions than Microsoft’s Visual Studio .NET – to a degree that it backs up your “falls short” claim.

Third, I wonder how someone who has dedicated his career to one of the most monopolistic, locked-down and proprietary platforms in existence, that is IBM’s midrange and mainframe platforms, feels qualified to discredit Microsoft for their platform strategy. In fact, I can run Windows on pretty much any AMD and Intel-based server or desktop from any vendor – how’s that with your AS/400 and mainframe apps?

Ultimately, .Net defeats the purpose of open standards because Microsoft products are open only as long as you develop applications on the Windows platform. To me, this doesn't say open, it says welcome to yet another Microsoft environment that is anything but open.

Likewise, IBM’s full Web Services stack is only open as long as you write applications for their WebSphere environment. WebSphere is IBM’s application server and Microsoft’s application server is Windows Server 2003. Every vendor who makes money from software tries to build a superior platform, resulting in features that aren’t covered by standards and therefore cause vendor lock-in. That’s a direct result from market economy. However, this still doesn’t have anything to do with Web Services, because these are “on-the-wire” XML message exchange standards that primarily exist for the purpose of cross-platform interaction.

Proprietary environments deny businesses the flexibility to chose best-of-breed solutions that are fine-tuned to their industry's unique environment.

… like OS/400 and OS/390 ?

Additionally, Microsoft's claim that .Net's Web services platform saves customers money is misleading. Sure, the initial investment is enticing, but how much will it cost when the hard work begins? A recent Gartner report said companies planning to move their old programs to .Net can expect to pay 40 percent to 60 percent of the cost of developing the programs in the first place.

A recent discussion with my 9 year old niece has shown that moving “old programs” from anywhere to anywhere isn’t free and that anyone who’d make that claim shouldn’t be working in this industry.

Building your company's Web services platform on .Net is fine if you don't mind throwing away decades of investment in existing applications. For instance, on any given day, businesses use CICS systems to process about 30 billion transactions, to the tune of $1 trillion. They can't afford to rip out that kind of processing power. Instead, they're looking for ways to exploit it within other applications. But if they were to buy into .Net, they'd better be prepared to stack it on the shelf because Microsoft's Host Integration Server provides limited access to CICS on mainframes.

Ok … here we have it. CICS is a lock-in, proprietary IBM product, right? So, what’s better than Host Integration Server? I suspect it’s an IBM product, correct? So if you were to replace that all so powerful IBM mainframe with any other technology (including Linux), of course using a different approach to architecture (which is entirely possible), how would you have not to throw away that investment?

What seems to be promoted here is “stay with IBM , use their stack”. I have all respect for the power of the IBM mainframe platforms, but using “openness” as an argument in this context and for the conclusions the author is making, is nothing less than perverse.