With the impending release of the Microsoft BizTalk Server Adapter Pack (Beta 2 available here), there are some confusions as to the differences between the BizTalk Adapter Pack, Microsoft's WCF Line of Business (LOB) Adapter SDK, and of course, the (older) BizTalk Adapter Framework.

In a nutshell, the BizTalk Adapter Pack is written and developed on top of the WCF LOB Adapter SDK (which is free and freely downloadable). The value-add is that the LOBs that it can integrate with ootb are SAP (mySAP Business Suite), ORACLE (Oracle Database) and SIEBEL (Siebel eBusiness Applications). Of course, a lot of grunt work is taken away from you, as explained here.

One of the confusing part is the play of the words "BizTalk" in the product name. As I have explained above, built on the WCF LOB Adapter SDK, these adapters are host agnostic i.e. they are not tied to a specific product like BizTalk. You can use it with BizTalk 2006 R2 specifically (The WCF LOB adapters cannot be used in BizTalk Server versions prior to BizTalk Server 2006 R2) but you can use it outside of BizTalk as well (some configuration work required, such as the Add Adapter Reference plug-in, etc) but this also means you do not have to buy BizTalk for it, if you dont have to.

This SDK is based on Windows Communication Foundation (WCF, previously - Indigo), and it surfaces an adapter to an LOB system as a WCF binding. For an adapter consumer, the adapter can be accessed like a typical WCF service; the consumer does not have to learn a new programming model. The same adapter developed can be reused in multiple .NET applications including custom .NET applications, Microsoft® BizTalk® Server 2006 R2, Microsoft Office SharePoint® Server 2007 SP1, and Microsoft SQL Server™ Integration Services (SSIS) through adapter development provided. In addition, the adapter provides metadata browse, search, and retrieval functionality for the adapter consumer to selectively generate WCF contracts that reflect live type modeling of the LOB system.

Confusions from customers and partners alike usually stem from the the primary differences between WCF LOB Adapter SDK and the BizTalk Adapter Framework. I will hereby summarized it in the following table:

Feature	WCF LOB Adapter SDK	BizTalk Server Adapter Framework
API	.NET 3.0 Assembly, provides help classes for metadata processing, connection management, and messaging	COM, provides basic support for adapter operations.
Adapter exposure	Exposed as WCF binding; available to any application that can consume a WCF binding including BizTalk Server 2006 R2 (using the WCF adapter)	Exposed only to BizTalk Server; not reusable by other applications.
Tools	Adapter Code Generation Wizard, metadata browser for Visual Studio 2005	n/a
Extensibility	Yes (as WCF channel extension)	No

If you are knee-deep into writing, shipping and selling adapters for BizTalk, I strongly urge you to visit the Adapters' Team Blog here.

I know I havent been posting deep technical stuff that I used to do. Contrary to what people think my current role entails, keeping abreast of the technology landscape is what I am supposed to do and what I enjoy and so when colleagues joked with me when was the last time I booted up Visual Studio, for example, I enjoyed seeing their shocked faces when I told them: "oh - just last night. why you asked ?" .

I dont dwell deep like I used to but I still code up decent projects which I implement within my own developmental testing environment (yes, I have one running latest versions of Active Directory, SharePoint, Exchange and all the other goodies), driving the houshold crazy when I think of new and different ways to document expenses, publish a Book or CD library, home automation projects using all sorts of different technologies (yes, that includes Ruby-on-Rails) or in my new Windows Mobile 6 Device. Of course, I admit I dont post topics deep like I used to. It is not so much the content but more so, the limiting factor of time.

Recently, I was involved in some internal technical discussions with regards to the issue of scale comparisions between Windows Communication Foundation (WCF, previously - Indigo) and ASMX. Below are some discussions:

If you have a web service that is going to be IO bound, you would definitely want it to be scalable and almost every resource in the world tells you to implement ASP.NET asynchronous pattern (BeginSomething/EndSomething, etc) on it so to go easy on the thread pool. ASP.NET uses an IAsyncHttpHandler to handle the request, which means the worker threads are not blocked while the IO-bound operation executes somewhere else. Sounds good so far.

If you make a WCF version of it with webHttpBinding (which actually means you can invoked it AJAX-style) following the same async pattern for the methods, you may find that each invocation of the WCF service eats up two threads – one for its ASP.NET HttpModule.ProcessRequest and the other for the actual IO. Ouch! You may think that this means your WCF implementation may end up eating all threads reserved for ASP.NET, which would indeed scale down the server

Is this true OR are we missing the complete picture ?

While the scenarios explained above are reasonable observations, it doesnt paint the complete picture. WCF does perform better scalability than ASMX.

• Threading:
  For ASMX, when a request comes in, it would be queued up immediately for async ASMX. So the thread is released for that request and a new thread will pick up the work item later.

For WCF, when a request comes in, we queue it up in WCF and let an IO thread handle the request. At the same time, the request thread-pool thread is held to wait for the request to complete.

Yes, WCF uses more threads than async ASMX. But there is a reason for this. Using asynchronous ASMX is dangerous and not really a good practice (and I have hinted at this many times in the many Web Service/ASMX presentations I have done over the past few years). While it does well at what it is supposed to do, it does trick the developer into a "false sense of security". Essentially, if you dont know how the ASP.NET blackbox works, you may find yourself thrown against the car wall when you take a hidden, unsuspecting corner at high speeds. It does not provide enough throttling for client loads. Basically the server takes all items and queue them up for later processing. The server does not have a good throttling mechanism to control the number of work items. To everyone else, it seems that the server is quite friendly to all clients. However, if the number of clients is unbounded, this is really bad. First of all, the server working set would grow unlimited due to unlimited requests queued up. Secondly, many client requests would become obsolete when it’s picked up by the server from the queue. The latter accounts for a a good set of problematic scenarios I have come across in my past consulting gigs with regards to high-load and high-transactional ASMX asynchronous implementations before I joined the borg.

Think of it as a side of the brain (that tells you that you are about to be full) not functioning properly when you sit down at a buffet table. You eat and eat and eat without knowning when to stop and then your ingestion/digestion system starts kicking in, you actually hit the wall. Hard. Literally.

• Server Throughput
  When you measure scalability, the most important measurement is the server throughput. That is, how many requests the server can handle per time unit? For async ASMX, it would be pretty fast at the initial phase. However, like the ingestion/digestion analogy I was referring to above - Once the server is in a steady phase (as when CPU is fully loaded), the throughput will go down because the server capacity has reached. You can compare the data between async ASMX and sync ASMX over the long run to see what I mean.

Also you would see higher memory usage of the async approach.

• ASP.NET Throttling
  That said, ASP.NET does have a throttling mechanism that is used for sync ASMX, which is the threadpool thread limit. The number of threads used to handle requests are bounded (http://support.microsoft.com/kb/821268). WCF uses this fact to throttle incoming requests. You can always change the configuration settings to increase number of threads to be used to allow more work items to be queued up.

The max number of threads follows the following formula:
MaxWorkerThreads x #CPU – MinFreeThreads
This is 12 by default on a single-proc machine.

• Two-level Throttling for WCF
  WCF leverages the ASP.NET threadpool throttling to throttle client requests. At the same time, WCF has its own item queue throttling. The former is throttled by the setting mentioned in the immediate above point, while the latter is controlled by WCF throttling settings (maxConcurrentCalls etc). ASP.NET can automatically adjust threads based on CPU loads so that you would always get full load of the server.

In this way, you may experience client failures because the requests are rejected at ASP.NET layer beforehand. So you can increase the ASP.NET throttling to get better experience. But eventually you would still be bounded by the physical server capacity, no matter whether you use async ASMX, sync ASMX, or WCF as mentioned above.

There is improvement work done in .NET 3.0 SP1 and of course, .NET 3.5 (beta 2 here), with the use of prioritized item queues. Do expect even-better WCF performance even in some of the common scenarios. Fine tuning minWorkerThreads will even give us even better results.

Thanks to Wenlong for helping out with the guidance and explanation. The complete scenario and the design principles for it will be published in greater detail in a MSDN whitepaper later. Do watch out for it.

It was not so long ago when I made my intentions known that the .svc extension in Windows Communication Foundation (WCF, previously - Indigo) is really a clutz. It is obstrusive and really unnatural, especially when it comes to RESTful Web Services.

In a closed door meeting with the product group folks back in 2005, before WCF rolled out and way before I joined the borg, I was told that this is a issue not with WCF itself, but by its web host - Microsoft Internet Information Server (IIS)

There are some attempts to hack around it but one of the best I have seen is to do URL Re-Writing: Off Jon Flandershere. You can see from the bottom of his post via Christian Weyer that this still will not work with IIS6 (damned legacies) but this will give you a good excuse to move to a Better, Leaner and MeanerIIS7, which is a complete rewrite of its predecessor. About time, I say.

While I was still an Microsoft MVP and a Microsoft Regional Director, one of the things I have always requested is to have Windows Communication Foundation (WCF, previously - Indigo) run in the Compact Framework to enable ease of use of WS-Security Specifications in distributed (W3C) SOAP communications.

I mean, really - even Web Services Enhancements (WSE) did not work at the Compact Framework level. One of my friends and a really technically-brillant guy, Casey Chesnut cooked something up to enable us to use secured communications on the compact framework (which I used).

Now, I guess the CF in WCF means it can work in the Compact Framework now, finally. This is a good read to show whats coming up. For more, you would have to attend MEDC 2007 in Vegas later this month.

This is a continuation of my previous post: WS-ReliableMessaging Simplified - WHY

While this blog sits in my draft folder while I am busy solving and fire-fighting other real-world problems, I just found out that my fellow distributed and connected systems enthusiast, Matevz has penned down the WHATs and HOWs of WS-ReliableMessaging faster than me, AND with even greater details !!!

So, instead of replicating that effort, it would be better for me to do a high level post about the HOWs of WS-ReliableMessaing. The below diagram of WS-ReliableMessaging explains the sequencing really well.

Let me explain the concepts of WS-ReliableMessaging in terms of a conversation between Alice and Bob:

Alice: Let me call Bob on his mobile telephone.(CreateSequence)
(Ring Ring ... Bob Picks up the phone)
Bob: Hello ? (CreateSequenceResponse)
Alice: Hi Bob, this is Alice(CreateSequenceResponse)
Bob: Hi Alice (CreateSequenceResponse, Identifier)
Alice: I would like to have a meeting with you tomorrow at 1000 hours (MessageNumber=1)
Bob: Cool. Roger. I got that. Sure, let meet tomorrow at 1000 hours.
Alice: Can we meet at my office in North Ryde ? (MessageNumber=2)
(Bob walks into a GSM blind spot ...)
Alice: Oh yeah, and Bob, please bring those M&A files for clearance for our senior VP (MessageNumber=3)
Alice: Hello Bob, did you get that ? Please repeat. (AckRequested)
Bob: Yes, I got that you are saying that we should meet up at 1000 hours at your office. Period (SequenceAcknowledgement)
Alice: No, you are not getting the full picture. You need to bring those M&A files for clearance for our senior VP (Resend MessageNumber=3). Kindly repeat what I just said (AckRequested)
Bob: Yeah. Got it. We should meet up at 1000 hours at your office and I will bring those M&A files for clearance for our senior VP. (SequenceAcknowledgement)
Alice: Bingo. Good. Please make a reservation for 1200 hours for lunch at "Steaks by the Bay" as well. (MessageNumber=4)
(Bob's phone went dead ...)
Alice: Hello ? Bob, did you get that ? (AckRequested)
Alice: Hello ? Bob, did you get that ? (AckRequested)
Alice: Hello ? Bob, did you get that ? (AckRequested)
Alice: Hmmm. Something is wrong. Let me call Bob again. (AcknowledgementInterval is up)
(Ring Ring ... Bob Picks up the phone)
Alice: Hi Bob, this is Alice. Sorry, I think I got cut-off from the earlier call. (CreateSequence)
Bob: Hi Alice. Sorry, yeah, my fault. I pressed the wrong button (CreateSequenceResponse with prev Identifier establised)
Alice: I was wondering if you can make a reservation for 1200 hours for lunch at "Steaks by the Bay" after that 1000 meeting tomorrow. (MessageNumber=1) Please acknowledge. (AckRequested)
Bob: Sure, of course. I will make a reservation for 1200 hours for lunch at "Steaks by the Bay" (SequenceAcknowledgement)
Alice: Alright then. Lets end this phone call. See you tomorrow. Thanks and Bye. (TerminateSequence of this Identifier)
Bob: See you tomorrow, Alice. (TerminateSequenceResponse)

Of course, the above is a simplistic view and there is a lot more to WS-ReliableMessaging than what I have just illustrated above with buffers, inactivitytimeouts due to infrastructure faults, in-order deliveries, maxRetryCount, maxTransferWindowSize, etc. But you get the jizz of this picture of why InOrder, idempotent-aware ReliableMessaging is needed in complex real-world enterprise-scale distributed communications.

If you want to know the WHATS and all in better detail, do visit Matevz's post here and a continuation here.

These are just some of the tabs that can be found if you expose a Microsoft BizTalk Server 2006 R2 process via a Windows Communication Foundation (WCF, previously - Indigo) Service.

The interesting part of the Messaging Tab of BizTalk 2006 R2 is that you are able to dictate the source of the inbound message body that you would like BizTalk to handle.

You can specify it to be the entire <soap:Envelope> or just the <soap:Body>, which essentially strips out the <soap:Header> element from the entire envelope. The flexibility comes in when you can dictate and customize the message content via an XPath expression that you would like BizTalk to process such as: /bookstore/book[0] ...

It is amazing to note the reach to the masses of a single MSDN Webcast. I had conducted a MSDN Webcast titled: "Acks and NAcks: Why We Need the Principles of TCP/IP Reliability in SOAP" in mid-2006 and till this day, I am still receiving questions and feedback about that topic I presented in the webcast. (Incidentally, you can view the on-demand webcast here.)

For those of you who do not want to go through this webcast again, I am going to break that presentation into the WHYs, WHATs and HOWs on this blog. This will make for easy-reading and straight-to-the-point as well.

WHY ?

This is rather straightforward. Why is it important? Why does it matter whether messages can be sent and received reliably? Web services is based on XML messages being sent and received. The most useful Web services will often be those that are the most complex and that rely on many messages being sent and received in a very specific order. That's the way that complex transactions can be built, after all.

Let us look at this problem in context before figuring out where the pain-points are. Most complex transactions in enterprises require far more messages to be sent and received. The messages will be much more intricate and may have very complex dependencies on one another, so that certain processes can't be kicked off until certain previous messages have been sent and acknowledged. Entire complex transactions can fail because a simple message didn't get through. And while it may sound simple to guarantee reliability, it's much more difficult than you might expect.

To add to the complexity, the main characteristics of Web services is communication over unreliable communication channels such as the Internet employing unreliable data transfer protocols such as HTTP, SMTP and FTP. These are considered unreliable, as they do not offer the reliable messaging services such as guaranteed delivery. Accordingly reliable messaging becomes one of the first problems that need to be addressed for Web services to become truly enterprise-capable technologies.

...there is nothing in SOAP or even HTTP that guarantees anyone that a message is delivered, or that allows a someone to tell the sender he/she has received the message...

Making reliable messaging more difficult is that messages are sent not just over the notoriously unreliable Internet, but also between partners that use entirely different networking infrastructures.

What many companies did in the past was to rely on proprietary messaging infrastructures to connect applications with one another. In these days of "open-standards", the industry would much prefer what Web services promises -- a messaging paradigm NOT based on any proprietary implementations."

To put it simply - If that reliability can't be guaranteed, Web services simply won't be used in the enterprise. The benefits of Web Services cannot be realized if it is not being used for complex scenarios in the enterprise.

Let us look at some of the inherent problems in which cross-boundaries communication happen today, especially over the cloud:

1. Re-ordering of Messages in Multi-Path Routing Scenario
   
   This is one problem that not many people realize because not many people would know the entire infrastructure physical topology of a end-to-end communication network channel. If you have 2 or more intermediaries that act as routers over a load-balanced network for example, messages being sent out may be routed differently over the network. In other words - The first Message ONE may be routed via Router 2 while the second Message TWO routed over Router 1. The complexity arises when the routers have their own routing table and paths and due to congestion of Router 2 over Router 1, the second Message TWO may arrive first, faster than Message ONE, at the final destination.
   
   
2. Intermediary Reliability
   
   What is not so self-explanatory is this - What happens if/when the intermediary drops my message ? How do I know if the other party has received it ? If I should send the same message again (just to be sure), how do I know if the serivce is designed to be "idempotent" ? This point has very explicit relations with the Quality-of-Service (QoS) assertions of a service. Each message sent must be received exactly once (once and only once). Failure to deliver a message be made known to both the sender and receiver.
   
   
3. Connection Management
   
   
   • “… my connection with the service drops frequently within this Wi-Fi network, but I don’t want to lose messages or the underlying session …”
   • “Bursty Connections - I may go idle for long periods of time and I don’t want to hold transport connections open …”
   • “… my service is using resources for each session and I want to release those resources if the client is not there anymore …”
     
     
4. Need for Transport Independence
   
   As I have mentioned earlier, different partners have different networking infrastructures and the need to rely on "open-standards" means that there is a need to decouple that reliablity element away from the transport. This ensures that different parties can choose to use whichever transport that suits them best but yet have a common accepted understanding on the reliability protocol that is independent of the chosen mode of transport.
   
   

To sum it up simply, we live in the real world. One that is not so perfect. The one where

• Servers fail
• Systems get out of synch
• Messages get lost
• Messages get re-ordered
• Messages cannot be safely re-tried

and the same one that explains why we need reliable messaging in Web Services.

NEXT UP: WS-ReliableMessaging Simplified - WHAT and HOW ?

The trouble with being part of the early adopters curve is that most of the time, your time is spend very unproductively trying to figure out, if samples dont work well, the reason why.

Is it a bad installation? bad configuration? corrupted downloads? or just simply the fact that the product team, while in a rush to get things out, forgot to update or remove the "deprecated" samples ?

While working very deeply with Microsoft Cardspace for a few months now and I mean doing "real" work for "real" clients, I would be one of the first to keep up to date on the new and upcoming Cardspace technicals.

While downloading and installing the July CTP SDK Cardspace samples, I found out that both the Cardspace SDK samples could not work at all - out of the box. I installed the CTP and the SDK twice to make sure that I didnt screw up the first time around (that means an hour of unproductive time wasted).

I was rather shocked when I found out that the Cardspace SDK samples have been deprecated BUT have not been removed by the team in time and my frustrations grew when the new working samples have not been uploaded in time as promised.

Who can I blame ? - No one forced me to be part of the Early Adopter's curve and no one asked me to download the July CTP SDK and its samples. Afterall, it is supposed to be an eagerly-anticipated drop. That said, the previous samples, in some way or another, have not been working too well at all. Some works perfectly on the local machine but have some troubles going out to the wild, while others like the June CTP, had its own host of problems.

So, what better way to do this than to roll-up-your sleeves and do-it-yourself ? While doing some reflecting, I found out some of the Cardspace July CTP SDK samples had not had its config and script files updated.

• The setup scripts had some errors. > set InfoCardServiceName="idsvc". Therefore, it is "net start idsvc". I answered my own post here.
• For the Simple Infocard sample under Basic\Bindings\WS\Infocard\Simple. Service config should have their behavior element changed as such. The issuedTokenAuthentication element is a key change/update.

    <behaviors>
      <serviceBehaviors>
        <behavior name="ServiceCredentials">
          <serviceCredentials>
            <serviceCertificate findValue="Whatever_you_are_using" x509FindType="FindBySubjectName" storeLocation="LocalMachine" storeName="My" />
     <issuedTokenAuthentication allowUntrustedRsaIssuers="true"/>
          </serviceCredentials>
          <serviceDebug includeExceptionDetailInFaults="False" />
    <serviceMetadata httpGetEnabled="true" />
  </behavior>
      </serviceBehaviors>
    </behaviors>

      <service name="Microsoft.ServiceModel.Samples.CalculatorService"
    behaviorConfiguration="ServiceCredentials">
        <endpoint address="" binding="wsHttpBinding" bindingConfiguration="requireInfoCard"
       contract="Microsoft.ServiceModel.Samples.ISecureCalculator" >
          <identity>
            <certificateReference findValue="Whatever_you_are_using" x509FindType="FindBySubjectName"
       storeLocation="LocalMachine"
       storeName="My" />
          </identity>
        </endpoint>
  <endpoint contract="IMetadataExchange" binding="mexHttpBinding" address="mex" />
      </service>

   <bindings>
  <wsHttpBinding>
   <binding name="requireInfoCard">
          <security mode="Message">
            <message clientCredentialType="IssuedToken" establishSecurityContext="true" negotiateServiceCredential="true" />
          </security>
        </binding>
      </wsHttpBinding>
    </bindings>

• For the app config. Take note:

  <system.serviceModel>
    <client>
      <endpoint address="http://swmvm2k3/ServiceModelSamples/service.svc/"
                bindingConfiguration="requireInfoCard"
                binding="wsHttpBinding"
                contract="ISecureCalculator"
                behaviorConfiguration="ClientCredentials">
    <identity>
     <certificateReference
        findValue="Whatever_you_are_using" x509FindType="FindBySubjectName"
        storeLocation="CurrentUser" storeName="TrustedPeople" />
    </identity>
   </endpoint>
    </client>

    <bindings>
      <wsHttpBinding>
        <binding name="requireInfoCard">
          <security mode="Message">
            <message clientCredentialType="IssuedToken" establishSecurityContext="true"/>
          </security>
        </binding>
   </wsHttpBinding>
    </bindings>

    <behaviors>
      <endpointBehaviors>
        <behavior name="ClientCredentials" includeExceptionDetailInFaults="true">
          <clientCredentials>
            <serviceCertificate>
              <defaultCertificate findValue="Fabrikam" x509FindType="FindBySubjectName" storeLocation="CurrentUser" storeName="TrustedPeople" />
              <authentication revocationMode="NoCheck" certificateValidationMode="PeerOrChainTrust" trustedStoreLocation="CurrentUser" />
            </serviceCertificate>
          </clientCredentials>
        </behavior>
      </endpointBehaviors>
    </behaviors>
  </system.serviceModel>

• For the \UsingWSFederation sample. Here are the changes to the service config. Take note of the issuedTokenAuthentication element:

    <services>
      <service name="Microsoft.ServiceModel.Samples.CalculatorService" behaviorConfiguration="ServiceCredentials">
        <endpoint address="" binding="wsFederationHttpBinding" bindingConfiguration="requireInfoCard"
 contract="Microsoft.ServiceModel.Samples.ISecureCalculator" >
        </endpoint>
 <endpoint contract="IMetadataExchange" binding="mexHttpBinding" address="mex" />
   </service>
    </services>

    <bindings>
      <wsFederationHttpBinding>
        <binding name="requireInfoCard">
          <security mode="Message">
            <message issuedTokenType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1" issuedKeyType="AsymmetricKey">
              <claimTypeRequirements>
      <clear />
                <add claimType  ="http://schemas.microsoft.com/ws/2005/05/identity/claims/emailaddress"/>
  <add claimType  ="http://schemas.microsoft.com/ws/2005/05/identity/claims/privatepersonalidentifier"/>
              </claimTypeRequirements>
              <issuer address="http://schemas.microsoft.com/ws/2005/05/identity/issuer/self"/>
            </message>
          </security>
        </binding>
      </wsFederationHttpBinding>
    </bindings>

    <behaviors>
      <serviceBehaviors>
        <behavior name="ServiceCredentials">
          <serviceCredentials>
            <serviceCertificate findValue="Fabrikam" x509FindType="FindBySubjectName" storeLocation="LocalMachine" storeName="My" />
    <issuedTokenAuthentication allowUntrustedRsaIssuers="true"/>
          </serviceCredentials>
   <serviceDebug includeExceptionDetailInFaults="False" />
   <serviceMetadata httpGetEnabled="true" />
        </behavior>
      </serviceBehaviors>
    </behaviors>

• Client config as follows:

  <system.serviceModel>
    <client>
      <endpoint address="http://swmvm2k3/servicemodelsamples/service.svc"
       bindingConfiguration="WSFederationHttpBinding_ISecureCalculator" binding="wsFederationHttpBinding"
                contract="ISecureCalculator" behaviorConfiguration="ClientCredentials">
    <identity>
     <certificate encodedValue="Do a svcutil and you will see the light ..." />
    </identity>   
      </endpoint>
    </client>

    <bindings>
      <wsFederationHttpBinding>
      <binding name="WSFederationHttpBinding_ISecureCalculator" closeTimeout="00:01:00"
 openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00"
 bypassProxyOnLocal="false" transactionFlow="false" hostNameComparisonMode="StrongWildcard"
 maxBufferPoolSize="524288" maxReceivedMessageSize="65536"
 messageEncoding="Text" textEncoding="utf-8" useDefaultWebProxy="true">
 <readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384"
 maxBytesPerRead="4096" maxNameTableCharCount="16384" />
 <reliableSession ordered="true" inactivityTimeout="00:10:00"
 enabled="false" />
 <security mode="Message">
 <message algorithmSuite="Default" issuedKeyType="AsymmetricKey" isuedTokenType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1"
       negotiateServiceCredential="true">
       <claimTypeRequirements>
        <add claimType="http://schemas.microsoft.com/ws/2005/05/identity/claims/emailaddress"
         isOptional="false" />
        <add claimType="http://schemas.microsoft.com/ws/2005/05/identity/claims/privatepersonalidentifier"
         isOptional="false" />
       </claimTypeRequirements>
       <issuer address="http://schemas.microsoft.com/ws/2005/05/identity/issuer/self" />
      </message>
     </security>
    </binding>
      </wsFederationHttpBinding>
    </bindings>

    <behaviors>
      <endpointBehaviors>
        <behavior name="ClientCredentials" includeExceptionDetailInFaults="true">
          <clientCredentials>
            <serviceCertificate>
              <defaultCertificate findValue="Whatever_you_are_using" x509FindType="FindBySubjectName" storeLocation="CurrentUser" storeName="TrustedPeople" />
              <authentication revocationMode="NoCheck" certificateValidationMode="PeerOrChainTrust" />
            </serviceCertificate>
          </clientCredentials>
        </behavior>
      </endpointBehaviors>
    </behaviors></system.serviceModel>

With that all done, you should be able to get both Cardspace samples in the July CTP SDK running, which will give you some relief that, at least, the installation is fine.

Hope this helps someone out there. Now, moving on to fix the sts.labs.live.com and the relay.labs.live.com issues ... <sigh />

While running the setup scripts for the Message Security (Certificate) samples for the July CTP of WCF, I came across an error that barks an "not finding file/folder" exception:

Upon further investigation into the setup batch scripts reveal this:

for /F "delims=" %%i in ('"%MSSDK%\bin\FindPrivateKey.exe" My LocalMachine -n ...

where I discovered the variable %MSSDK% was not defined in file.

So add this line to the variable settings on the top of the batch script:

set MSSDK=C:\Program Files\Microsoft SDKs\Windows\v6.0

This should help solve the puzzule of the missing directory name ...

During my webcast on "Why we need Reliablility in SOAP: Web Services", there were a couple of hiccups which hindered a better listening experience.

1. I cannot see the animation on the slides I am presenting, even though I am assured by the producer that the floor is seeing it. Therefore, I am "guessing" what the audience is actually seeing in my click-animation and gauging my content from there. It was neither easy nor pleasant.
2. There was a disconnect incident in my demos that also marred the listener's experience. I had to re-login again. Not Good.

Isnt it ironic? My network connection showed lack of reliability when I am talking about Reliability as a topic. . Now the least I can do is to answer a couple of questions that popped up after the session:

Q: Is RM available for all the bindings in Windows Communication Foundation (WCF, previously - Indigo) ? 
A: Yes, it is available for MOST of the standard bindings in WCF. In some bindings such as the netTcpBinding I showed, it is On-by-Default. In bindings such as wsDualHttpBinding where you need correlation of different channels and such, it is Always-On. It doesnt make sense to stick <reliableSession /> in a netMsmqBinding, for example.

Q: Is this the same WS-RM spec that is authored by IBM, Microsoft and TIBCO ? 
A: Yes. In my slide, I mentioned - I.B.M and TIBCO. I.B.M is actually the acronym I used for IBM, BEA and Microsoft.

Q: Can I get the demo you showed? 
A: No, I am sorry. In any case, my demos will not work with the lastest WinFX B2 bits today. I will need time to port them over. I recommend you go bug Shy when you see him and ask him for his WS-RM demo which consists of a WPF stack in there and a "awesomely" cool Rubik's Cube demo and is 100x better than mine.

All in all, it is quite a different experience than doing an on-stage presentation, especially when you spent an hour talking to yourself and you cannot see the audience faces and cannot manipulate your content and presentation based on their moods.

But then again, no one can see that I am wearing my Mickey-Mouse boxers while I am presenting, so I guess that is a good trade-off.

Here I am - proud to announce that I will be doing a MSDN Redmond-hosted Webcast right from the other side of the hemisphere in Singapore.

I will be speaking on concepts of Reliability in Soap:Web Services, why its needed, as well as the context of it in Windows Communication Foundation (WCF, previously - Indigo).

More importantly, a 40GB Creative (another homegrown Singaporean product) ZEN MP3 player is at stake here waiting to be won. So, do sign up quickly for a chance to win this. Rules here.

If you are one of those insomniacs in Asia-Pacific, do try to tune-in. I hope this blazes a trail for the other community leaders in Asia-Pacific to follow suit and show that we are right on par there with the best in technology.

Click here for more details on this webcast.

Fellow Microsoft Regional Director and well-known distributed systems expert Matevz Gacnik has a great blog to add on top of mine called: Windows Workflow Foundation: Exposing Workflows as Services. Trust me, Matevz is a lot more than Request-Response or what his blog suggested .

In it, he explains some of the ways you can do so and the pitfalls to watch out for. Of course, you can get around the "workflow runtime can only get loaded once per appdomain" issues by having it static to the service implementation class OR if you want only one instance of each - Windows Communication Foundation (WCF, previously - Indigo) also gives you a singleton-like instancing mode as well - InstanceContextMode:=InstanceContextMode.Single.

(I would be interested to find out the naming convention to call it Single in the latest CTP instead of Singleton)

My tip highlighted here is not really about exposing workflows as services. It is more about how you can hook a workflow into a already-hosted WCF service as part of its configured behavior, if need be. For example, you may want to have a non-intrusive workflow for you to raise an event that calls into your defined HandleExternalMethod (called EventSink before) and then you may just terminate that activity. The reason is because the workflow thread doesnt return unless you called a WaitHandle.Set, which you can call when a workflow is completed or terminated.

Having said all that - Remember that most of the current implementations of Web Services today work on a Request-Response model and many more are betting on that it will remain like that for a long time. Isnt this one of the reasons we have long arguments of POX/REST ? Workflows, on the other hand, are made to handle long running work and therefore, you need to design and handle both properly as its design principles and most-used implementations do conflict.

Now, if you forsake the Request-Response model and think about the wonderful partnership and the options abound once you hit <OperationContract(IsOneWay:=True)> on top of the MSMQ transport, Windows Workflow Foundation (WF) + Windows Communication Foundation (WCF, previously - Indigo) does look very delicious and promising indeed.

One of the common questions I came across my Windows Workflow Foundation (WF) and Windows Communication Foundation (WCF, previously - Indigo) consultancy tour is how do we logically use WF inside a WCF-hosted service.

I had spent some time talking about how we can host a WF in a WCF:ServiceHost and how we can create a channel to invoke a workflow inside a WCF Service.

Of course, we can always bring up a Workflow runtime and create a new workflow instance within the ServiceHost. However, some of us may prefer a more non-intrusive mode of a workflow invocation style.

There are actually many extensible points at the Service Dispatcher which you can hook into that is part of a service behavior. There is the IServiceBehavior, IOperationBehavior and one of my favourite extensible behavior points I like to hook into is at the IEndpointBehavior.

For instance, you may want to inspect a message in its raw glory and depending on its headers or the request properties, you may choose to invoke an appropriate action or workflow. You would need to implement the ApplyDispatchBehavior routine which gives you acccess to an EndpointDispatcher, which in turn, gives you a chance to implement a IDispatchMessageInspector. The IDispatchMessageInspector exposes some very useful routines which allows you to hook into the request message just after it has been received as well as before sending the reply message back.

I would probably inspect the messages at this point and invoke the appropriate workflow and send the appropriate values into the ExternalDataEventArgs of the workflow based on the message values.

Of course, this is not a hard and fast rule. How and when you do it is totally up to you. You may want to do it at the IOperationBehaviour and have the message dispatched to another entirely different operation if you want to (or if you dont agree with how WCF dispatches its messages).

Below are some snippets that will help you along. I will be going more in-depth into these details in TechED Asia 2006 in Malaysia where I will show some really cool never-seen-before demos that is a mixture of WF and WCF. If you havent planned to be be there at TechED Asia 2006, do so now !

Namespace Softwaremaker.NET.Wcf.Demos
PublicClass WcfMessageInspectorWorkflowInvoker : Implements IDispatchMessageInspector

PublicSubNew()
MyBase.New()
EndSub

PublicFunction AfterReceiveRequest(ByRef request As Message, ByVal channel As IClientChannel, ByVal instanceContext As InstanceContext) AsObjectImplements IDispatchMessageInspector.AfterReceiveRequest
Try
'Inspecting Message Request ...
'Invoking appropriate Workflows based on values found in request message
Catch e As Exception
ThrowNew FaultException(e.Message)
EndTry
ReturnNothing
EndFunction

PublicSub BeforeSendReply(ByRef reply As Message, ByVal correlationState AsObject) Implements IDispatchMessageInspector.BeforeSendReply
Try
'Inspecting Message Reply ...
'Invoking appropriate Workflows based on values found in reply message
Catch e As Exception
ThrowNew FaultException(e.Message)
EndTry
EndSub
EndClass

What I have described above is a good way to abstract how and when you invoke a workflow away from your WCF-Hosting or business code. How do I add this behavior into my serviceHost ? Easy. Just call the below before your serviceHost.Open

serviceHost.Description.Endpoints(0).Behaviors.Add(New Softwaremaker.NET.Wcf.Demos.WcfMessageInspectorWorkflowInvokerBehavior)

Now, if you decide that the above code sentence intrudes into your hosting code and you would like it to be configured in your config file for flexibility as well, I will show in a later blog post how to add your own custom-defined behaviorExtension into your configuration file. Think: BehaviorExtensionSection.

... OR you can always go to TechED Asia 2006 in Malaysia where you sure would derive more value than a single non-interactive blog post.

Enjoy.

I remembered talking to someone on the Windows Communication Foundation (WCF, previously - Indigo) team before and the reason they chose [MesssageEncoding].MTOM instead of MessageTransmissionOptimizationMechanism is so that it could *at least* fit on a slide.

Well, that someone obviously didnt educate the developer who build the [MessageSecurityVersion]. WSSecurity11WSTrustFebruary2005WSSecureConversationFebruary2005WSSecurityPolicy11BasicSecurityProfile10 property. [Talk about a mouthful]

Not only is it hard to fit on a slide, it would be hard to mouth those words as well.

Besides "bug jail", "secure-programming courses",  "geography lessons", I would highly recommend Microsoft engineers and developers go for "Power-Point Presentation Etiquette 101" lessons as well .

Speaking of which, I just got handled an exception with a message like this:

The CLR has been unable to transition from COM context 0x1a0d28 to COM context 0x1a0e98 for 60 seconds. The thread that owns the destination context/apartment is most likely either doing a non pumping wait or processing a very long running operation without pumping Windows messages. This situation generally has a negative performance impact and may even lead to the application becoming non responsive or memory usage accumulating continually over time. To avoid this problem, all single threaded apartment (STA) threads should use pumping wait primitives (such as CoWaitForMultipleHandles) and routinely pump messages during long running operations.

Talk about being explicit. Exceptions should give a friendly message that enables one to have an idea where to start debugging and troubleshooting. The one just made me want to shut my machine down. .

Microsoft announced Go Live licenses this morning for Windows Communication Foundation (WCF, previously - Indigo) and Windows Workflow Foundation (WF) , which lets customers use the January Go Live releases of WCF and WWF in their deployment environments. Do note that these are unsupported Go Lives.) 

More information about the Go Live program is at http://msdn.microsoft.com/winfx/getthebeta/golive/default.aspx.

There are also a couple of community sites for WCF and WWF here:
http://windowscommunication.net
http://windowsworkflow.net

The community sites give users everything they need to start using WWF and WF today.  If you have some great samples, do post them to the sites;  The WCF sample gallery and WF activity gallery allow you to host the samples/activities on your own site and create links to your own site from the galleries.

As mentioned, I will be introducing more WWF Blogging to this site. Do stay tuned.

I was approached to write about Windows Communication Foundation (WCF, previously - Indigo) a while back for SearchVB.com, a member of TechTarget.com.

Between a few new transitional CTP drops and major Microsoft events, I managed to hack out a simple piece here targetted at entry WCF-VB developers. There is another intermediate one (that deals with security) which will appear slightly later on TechTarget.com. Stay tuned to this space for further updates.

Do take note that this piece is currently one of the very few out there that is written against one of the latest WCF versions (The Sept-CTP WinFX drop).

Enjoy and send those comments over.

I was told that there appears to be a couple of non-working samples in the Windows Communication Foundation (WCF, previously - Indigo) Sept-CTP drop. I found out (the hard way) that one of them was the BasicSecurityProfile sample.

There is a workaround to it. There are basically 2 bugs in that sample. It may help solve the other bugs in the samples. This will only affect the security samples that uses the WS-Security Specifications in the [basicHttpBinding] bindings.

BUG 1. The affected sample will only work with X.509 Digital Certificates that has the Subject Key Identifier (SKI) installed. Unfortunately, the cert samples, which are used, are being issued by makecert.exe which doesnt generate X.509 certs with the SKI.

1. You can create test certificates from Verisign. Those test certs will come with SKI
2. You can set up a Certificate Authority (CA) on Windows 2003 Server. This is not installed by default and you need to add that component into your server setup. This will issue you a cert with SKI.

On a separate note, X.509 Digital Certificates that come with SKI offer the best approach in interoperability, so it is best recommended that you work with certs that comes installed with it.

BUG 2. Once you fix the workaround to BUG 1, and you run the BasicSecurityProfile sample and the client barfs this exception at you:

1. On the client proxy, change the replyAction = "*"

Once you have these 2 workarounds done up, the BasicSecurityProfile sample should work.

Both these bugs will be fixed in the subsequent WCF drop. I hope this at least helps someone.

In Web Services Enhancements (WSE) 2.0, one could exercise some control over what one xml element/fragments wants to encrypt within a soap:Body. Therefore, if I wanted to encrypt the account string in my credit card type, I could do something like this:

[At your Service Side]

Public Class SecuredString
  'Set the Oasis Id that our security reference will point to
  <XmlAttributeAttribute("Id", _
Namespace:=".../2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd")> _
  Public ID As String
  <XmlText()> _
  Public Data As String
End Class

[At your Calling side]

Dim c As SoapContext = a.RequestSoapContext

b.CreditCardType = "VISA"
z.Id = "uri:demoId.softwaremaker.net" 'or some guid
z.Value = "123-456-789"
b.CreditCardAccount = z

c.Security.Elements.Add(New EncryptedData(tok, "#uri:demoId.softwaremaker.net"))

Note: To reduce headache-inducing typo bugs, you may want to use some WSE Constants such as
WSUtility.Prefix
WSUtility.AttributeNames.Id
WSUtility.NamespaceURI

The end result of this is a soap:Body on the wire looks like this:

While I dont know how much of performance benefits this has over one that has the entire SecureCreditCard encrypted (since it is an symmetric-key encryption at its core), I think in terms of latency and throughput, it does offer some benefits especially with a sizable payload (>20-30 kb, for instance ?)

Windows Communication Foundation (WCF, previously - Indigo) does not currently have that feature build in at the moment (Sept05-CTP or known as the PDC-bits). In other words, in WCF today, you encrypt the entire contents of the soap:Body, lock-stock-barrel. I would still love that WSE feature in there: To be able to exercise finer grain control over what I want to or not to encrypt within a soap:Body.

Would really like to find out if I am the only odd one out there. Any users using that existing WSE feature out there that would love to see the same in WCF or do you have other better ideas ? Leave a comment or email me via the contact link on the side. Thank you.

BTW: Whether you encrypt certain elements of the contents or encrypt the entire contents of the soap:Body, both are WS-Security Specifications compliant .
 

Even though it is a mini-TechED scale-wise, I have a feeling it is going to be BIG nonetheless.

I will be presenting in this event on, what-else but Windows Communication Foundation (WCF, previously - Indigo).

I hope to see you there as it will be a good time there.

[Update:] Some comments on the event:-
http://www.geekswithblogs.net/tariq/archive/2005/10/12/56777.aspx
http://mahasen.blogspot.com/2005/10/first-day-of-teched-2005-sri-lanka.html
http://mahasen.blogspot.com/2005/10/second-day-of-teched-2005-sri-lanka.html
http://jinath.weblogs.us/archives/032674.html
http://lkdeveloper.blogspot.com/2005/10/tech-ed-srilanka.html

Mike Taulty is throwing up some very good Windows Communication Foundation (WCF, previously - Indigo) notes via his blog here.

In one of his post, he asked about what is the ListenerFactory that is analogous to the client-side ChannelFactory. This is a good question and I believe the answer is the System.ServiceModel.ServiceHost.

There are, however, a few ways to implement a server-side pipe that can process and understand his client-side implementation of his generic ChannelFactory here.

One of the ways to listen and process the incoming message is actually something he has already cooked up in an earlier post of his. However, to answer his question:- ServiceHost is the answer to the ListenerFactory.

I took the liberty of writing up some code to wire up some ListenerFactory stacks via the Service.ServiceModel.ServiceHost.

Back to more Windows Communication Foundation (WCF, previously - Indigo), or previously known as Indigo, postings...

I dont think a lot of people know about one of the aspects of WCF, which pertains to how WCF serializes incoming messages before it sends it to the dispatcher and onto your .NET typed code.

In .NET 1.*, ASMX disregards the ordering of the data elements in the received messages. This means that for a XML Schema such as this:

[s:complexType name="CreditCard"]
[s:sequence]
[s:element name="AccountName" type="s:string" /]
[s:element name="CreditCardType" type="s:string" /]
[s:element name="CreditCardNo" type="s:string" /]
[s:element name="CreditCardExpiryDate" type="s:string" /]
[/s:sequence]
[/s:complexType]

If you send a (W3C) SOAP Message such as this (Take note that the ordering of [AccountName] is not in-line with the above schema):

  [soap:Envelope]
    [soap:Header /]
    [soap:Body]
      [SubmitCreditCard]
        [crdcard]
          [CreditCardType]AMEX[/CreditCardType]
          [CreditCardNo]1234567890[/CreditCardNo]
          [CreditCardExpiryDate]08082088[/CreditCardExpiryDate]
          [AccountName]William Tay[/AccountName]
        [/crdcard]
      [/SubmitCreditCard]
    [/soap:Body]
  [/soap:Envelope]

ASMX will allow the message to go through.

In WCF, there is strict enforcing of the ordering of the data elements. Lets take a quick look:

WCF Code:
[DataContract()] _
Public Class CreditCard
  [DataMember(Name:="CreditCardExpiryDate")] Private _CreditCardExpiryDate As String
  [DataMember(Name:="CreditCardType")] Private _CreditCardType As String
  [DataMember(Name:="CreditCardNo")] Private _CreditCardNo As String
  [DataMember(Name:="AccountName")] Private _AccountName As String

  Public Property CreditCardType() As String
    Get
      Return _CreditCardType
    End Get
    Set(ByVal value As String)
      _CreditCardType = value
    End Set
  End Property

  Public Property CreditCardNo() As String
    Get
      Return _CreditCardNo
    End Get
    Set(ByVal value As String)
      _CreditCardNo = value
    End Set
  End Property

  Public Property CreditCardExpiryDate() As String
    Get
      Return _CreditCardExpiryDate
    End Get
    Set(ByVal value As String)
      _CreditCardExpiryDate = value
    End Set
  End Property

  Public Property AccountName() As String
    Get
      Return _AccountName
    End Get
    Set(ByVal value As String)
      _AccountName = value
    End Set
  End Property
End Class

This will generate the schema :
[xs:complexType name="CreditCard"]
[xs:sequence]
[xs:element name="AccountName" nillable="true" type="ser:string" /]
[xs:element name="CreditCardExpiryDate" nillable="true" type="ser:string" /]
[xs:element name="CreditCardNo" nillable="true" type="ser:string" /]
[xs:element name="CreditCardType" nillable="true" type="ser:string" /]
[!-- I omitted some WCF-specific elements here for simplicity.--]
[!--I will blog more about this on a later date. See Below **--]
[/xs:complexType]

There is a reason I put the Public Property AccountName last in my .NET 2.0/Indigo code above. I wanted to show that how you place the property/field in code has no effect on the schema. If you keep a strong observant eye on the resultant schema, you will notice that it is Alphabetical-Ordering dependent and if I send the below message to it:

[s:Envelope]
[s:Header /]
[s:Body]
[SubmitCreditCard xmlns="http://demos.softwaremaker.net/SchemaDataOrdering"]
[crdcard]
[CreditCardExpiryDate]08082088[/CreditCardExpiryDate]
[CreditCardNo]1234567890[/CreditCardNo]
[CreditCardType]AMEX[/CreditCardType]
[AccountName]William Tay[/AccountName]
[/crdcard]
[/SubmitCreditCard]
[/s:Body]
[/s:Envelope]

It will result in a HTTP Error Code: 500 (Internal Server Error). What this means is that you have to keep the ordering of the dispatched message to the published schema or else WCF will reject it.

The consensus from the field (I felt) is that while most of the projects doesnt even feel the lack of schema-ordering enforcements in .NET 1.*, there may be certain advanced validation scenarios that may need order checking at the schema level. While I welcomed this extra checking, I hope it doesnt come with a performance penalty.

The good news is that the Service.Runtime.Serialization.XMLFormatter, which is used in WCF, is a lot better performer than its predecessor: the XMLSerializer. It does, however, give the developer less control of the XML Schema though. **WCF will add in its own special elements into the schema**. This will aid in better message versioning and control that comes with the evolutionary nature of distributed loosely-coupled messaging systems such as WCF. I will explain more in a later blog post.

From what I understand, the WCF team is considering of adding an Order property to the DataMemberAttribute to allow for added customization of this order. Again, I feel that this is a good move as Alphabetical-Ordering dependency will mean that developers may have to consider their naming conventions in code should they require a validation check at the schema level.

What I would like is an attribute for me to turn-off schema data elements ordering validation and checking should I choose to. In this case, the developers on the field will be comfortable of the options they have at hand if validation / performance tradeoffs becomes an issue.

P/S: I used my own Manual SOAP Post tool to create some of the scenarios here. You may want to download it here.

Microsoft intends to offer an "adapter" under its shared source license for linking its BizTalk integration broker with Windows Communication Foundation (WCF, previously - Indigo), formerly known as Indigo.

As you can see from the comments I left there and I am re-producing it here:

One of the things I noticed is that the .svc extension is strange if you look at it from a endpoint angle. Having

http://abc.com/def.svc/mex
http://abc.com/def.svc/ep1
http://abc.com/def.svc/ep2

is rather unnatural. I had a couple of attendees who actually thought it was a typo in the HOL (the HOLs are full of typos, btw) and changed it to

http://abc.com/ep1/def.svc
http://abc.com/ep2/def.svc

Of course that didnt work as well. They had a hard time grappling with the unnatural look and feel of it.

I would think that receiving client applications would do a double-take on this as well once they look at the actual endpoint address

Getting rid of the physical file extensions would be a great and welcomed idea! Afterall, it is good convergence with the servlets of J2, Remoting and httpHandlers of .NET, Content Management Servers and others as well.

If I am not wrong, isnt that how REST Web Service works as well ? Something like http://abc.com/ep1 or http://abc.com/getSomething. It is a verb thingy. There is really no physical file on the other end.

To me, its simpler as well as now if I have to change any type information, it will be in the .config file only and nothing more. God forbid customers to deploy multiple physical files as well ... and to some of us who are used to doing inline scripting in these asmx or svc files (for debugging and testing purposes, not for production use), .NET 2.0 already gives us dynamic compilation in App_Code

To me, the solution is clear: Dump the svc file extensions

If you have other ideas, opinions or just want to echo my same thoughts, do feel free to drop by Steve's post and let him know !

To those whom have attended Indigo Ascend and have asked me via emails: What acutally happens in the plumbings of the IsOneWay part of a Indigo Duplex Contract ?

HTTP/1.1 202 Accepted is the answer. This is the explicit return.

HTTP/1.1 100 Continue

HTTP/1.1 202 Accepted
Date: Fri, 15 Jul 2005 08:56:07 GMT
Server: Microsoft-IIS/6.0
MicrosoftOfficeWebServer: 5.0_Pub
X-Powered-By: ASP.NET
X-AspNet-Version: 2.0.50215
Cache-Control: private
Content-Length: 0

This, of course, only applies to the HTTP Bindings.

"The request has been accepted for processing, but the processing has not been completed. The request might or might not eventually be acted upon, as it might be disallowed when processing actually takes place. There is no facility for re-sending a status code from an asynchronous operation such as this.

The 202 response is intentionally non-committal. Its purpose is to allow a server to accept a request for some other process (perhaps a batch-oriented process that is only run once per day) without requiring that the user agent's connection to the server persist until the process is completed. The entity returned with this response SHOULD include an indication of the request's current status and either a pointer to a status monitor or some estimate of when the user can expect the request to be fulfilled."

According to Don's blog here: Indigo has support for REST since Day 1. In the same breadth, he disclosed that it will explicitly support HTTP PUT/POST/DELETE/GET to please the REST purists out there.

Like Steve mentioned here, I, too, am not a fan of technology stacks that complete with their own ideologies. To me, technology is there just to get a job done efficiently and effectively. My post here attracted quite a fair bit of hits and same-echo-sentiment emails. It even made to ZiffDavis blog list here.

As Steve has echoed as well, I am also even more convinced now that Indigo is going to be the platform to beat when it comes to distributed communications. No doubt about it.

I am really glad that the Indigo team, whom I think comprises some of the brightest minds in the software field, is all united to work towards a common goal of creating a religion and ideology-agnostic product. If this is not innovation, I dont know what is.

Show me the money, Beta1

I had the recent pleasure of meeting up with active blogger Mitch Denny who is one of the Microsoft Indigo Ascend attendees which I conducted last week in Sydney, Australia.

He spent some time blogging about what was learnt during the 3-day session. A very good read here, here and here for all who is interested in knowing the color of Indigo.

What a cool dude. You rock, Mitch !

WS-MetadataExchange is used and enabled by default in Indigo and it comes with WS-Policy as well.

This is one specification that I find really useful because the current convention of using http-get to get the metadata from asmx?WSDL is still a very .NET sort of convention. For my projects, I usually like to put the metadata in a physical file and deploy it as *.wsdl. Other people and toolkits will also have their own naming conventions.

While using http-get is a very useful convention of retrieving metadata, we cannot assume that all services will support HTTP. In Indigo, it’s common to expose an endpoint that only listens over IPC or SOAP-over-TCP.

At its current Beta 1 drop, only http / https will be supported. I do forsee that tcp will be supported in the next major drop.

In Indigo, the WS-MetadataExchange endpoints are added to the (http) service by default at the container-baseAddress/containee-endpointAddress as a mex suffix. You can also choose to define your own custom mex endpoints. Another wonderful thing it supports is that it allows the specifying of a custom metadata file (which I know I will be definitely be using). In other words, instead of getting Indigo to automatically generate the metadata, it will send the requestor to the uri location of the metadata file I specify.

If you have done some UDDI work before, you would be accustomed to the convention of sending standardized (W3C) SOAP Request messages for querying purposes. WS-MetadataExchange uses the same sort of principles, albeit with different querying implementations.

Here is how it works. There is no better way to illustrate this than to get really friendly with the wire-layer plumbings. I have a tool here that will give you a good view of the exchange.

Getting an mcdba certification is not a problem if you have done cisco training as well as other security training programs like mcp but there is no replacement of microsoft training.

You need to send a standard SOAP request to the listening mex endpoint that goes like this (Replace the square brackets with angle ones)

  [s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://schemas.xmlsoap.org/ws/2004/08/addressing"]
    [s:Header]
      [a:Action s:mustUnderstand="1"]http://schemas.xmlsoap.org/ws/2004/09/mex/GetMetadata/Request[/a:Action]
      [a:MessageID]uuid:f22ee227-3eeb-460d-9352-1a34e97bf911;id=0[/a:MessageID]
      [a:To s:mustUnderstand="1"]http://localhost/servicemodelsamples/service.svc/mex[/a:To]
      [a:ReplyTo]
        [a:Address]http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous[/a:Address]
      [/a:ReplyTo]
    [/s:Header]
    [s:Body]
      [GetMetadata xmlns="http://schemas.xmlsoap.org/ws/2004/09/mex" /]
    [/s:Body]
    [!-- OR an Empty SOAP Body will do just as fine --]
    [!-- s:Body /--]
  [/s:Envelope]

In the tool I had build, you need to put the a:Action value (in bold above) into the SOAPAction textbox as this has to be propagated up to the HTTP-Headers as a SOAPAction header. This is one of the sticklers of using http to query for any SOAP Web Service. Once you clicked post, you will see a good-looking response with all the metadata of WSDL and WS-Policy in the SOAP body. I took out a lot of details in the constraints of space. You should be able to get the point.

  [s:Envelope xmlns:a="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:s="http://www.w3.org/2003/05/soap-envelope"]
    [s:Header]
      [a:Action s:mustUnderstand="1"]http://schemas.xmlsoap.org/ws/2004/09/mex/GetMetadata/Response[/a:Action]
      [a:RelatesTo]uuid:f22ee227-3eeb-460d-9352-1a34e97bf911;id=0[/a:RelatesTo]
      [a:To s:mustUnderstand="1"]http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous[/a:To]
      [ActivityId xmlns="http://schemas.microsoft.com/2004/09/ServiceModel/Diagnostics"]uuid:a55fa135-e1b9-4557-a7c3-39cbf042f85d[/ActivityId]
    [/s:Header]
    [s:Body]
      [wsx:Metadata xmlns:wsx="http://schemas.xmlsoap.org/ws/2004/09/mex"]
        [wsx:MetadataSection Dialect="http://schemas.xmlsoap.org/wsdl/" Identifier="http://tempuri.org/"]
          [wsdl:definitions]
            [!--WSDL and XSD GUNK--]
            [!--XSD GUNK--]
            [!--WS-Policy GUNK--]
          [/wsdl:definitions]
        [/wsx:MetadataSection]
      [/wsx:Metadata]
    [/s:Body]
  [/s:Envelope]

You will be able to load endpoints, bindings and types dynamically at runtime with such information.

Do take note that Indigo is extremely strict about the mediaTypes headers and you need to set the contentType of the Http-Headers to application/soap+xml. This can be done in the configuration file.

Do download it and try it.

If you think this is a cool new feature in the Microsoft technology space, it is not.

Web Services Enhancements (WSE) 2.0 also had it. All you need is to send in a "http://schemas.microsoft.com/wse/2003/06/RequestDescription" in the Action of a SOAP Message request to a listening WSE 2.0 service and you will be presented with the WSDL as well. This is what WseWsdl2.exe does you switch in a TCP address.

I will be delivering Indigo Ascend in Asia Pacific in the coming months on behalf of the Indigo and Ascend team in MSFT Corp, Redmond, US.

It will start in Sydney, Australia later this month, then move upwards (northwards) to my own local backyard, Singapore. There are a few more countries Microsoft and I are interested to look at bringing this event as well.

This will be a good time for me to meet up with real customers from the enterprises who are using Microsoft distributed technologies or are planning to look into using it in the future. Drop me an email here if you would like to engage me for a discussion.

If you are reading this blog post and you work for an ISV or an enterprise that does a fair bit of distributed computing technology and you are interested in attending this Indigo Ascend in Singapore (I think we are a little bit late in nominations for Australia), do drop me a mail here and I will see what I can do to hook you up for this 3 day event.

If you are from anywhere else besides Australia or Singapore (in APAC) and would love to attend an event like this, do drop me an email as well and I will see what I can do to bring Indigo Ascend to your country.

I have been invited to deliver a few Ascends before such as Visual Studio 2005 and such. However, I have always turned it down because I dont consider myself to be a "professional" trainer since I have always been on the field working on real projects with real problems in distributed technologies for some time (and not some simulated fanciful classroom labs scenarios) ...

... BUT...

Indigo is an Ascend which I am proud and excited to deliver because it is a future facet of Windows Server 2003 that I have spent quite some time on and I believe it is something that real customers need in the field to solve real-world problems today.

There is really nothing quite like it out there at the moment or in the immediate future outside of Microsoft. It is really one of Microsoft's innovation at its best.

This will be interesting ...

I think I will reserve my comments on this for now.

I know it is supposed to be here. However, I think it is taking some time to propagate to the server farms. So, just stay tuned.

If it still doesnt work after some time, may want to try this: http://www.microsoft.com/downloads/info.aspx?na=90&p=&SrcDisplayLang=en&SrcCategoryId=&SrcFamilyId=b789bc8d-4f25-4823-b6aa-c5edf432d0c1&genscs=0&u=http%3a%2f%2fdownload.microsoft.com%2fdownload%2ff%2fa%2f3%2ffa3b19ba-6129-41e8-93d8-498cc6b52b14%2fwinfxsetup.exe

Something that is rather useful that is gathered from the usergroups:

... found a logfile (dd_indigo_retMSI60A6.txt) with the following entry:

MSI (s) (B0:1C) [12:29:27:752]: MainEngineThread is returning 1638
Another version of this product is already installed.  Installation of this
version cannot continue.  To configure or remove the existing version of
this product, use Add/Remove Programs on the Control Panel.
{C350D87C-7B67-43E2-B717-E9ADABE2F631}

So I ran this command:

msiexec /x {C350D87C-7B67-43E2-B717-E9ADABE2F631}

and now the Indigo setup worked! It will probably work for you as well!

With reference to my earlier post here, more details on the conference (SDA.NET 2005) are now publicly available here. This is a paid event and it is rarity in Singapore as technological conferences are usually presented free. BUT I am sure attendees can find a lot of value here as top notch speakers from all over the world will be flying over here to share their industry experience and knowledge.

Who are these speakers, you ask ? There is the famous Ingo Rammer and Clemens Vasters and of course, moi .

I will be making 2 presentations in the VIP Tracks, namely

Lets take a look at the meaning and symbolism of the color Indigo. I will attempt to slot in my own views on how the color maps into the technology.

Indigo symbolizes: intuition, deep contemplation, meditation

Indigo is the color of the deep midnight sky. It can have a negative effect when used during a depressed state, because it will deepen the mood. Indigo symbolizes a mystical borderland of wisdom, self-mastery and spiritual realization. While blue is the color of communication with others, indigo turns the blue inward, to increase personal thought, profound insights, and instant understandings. While blue can be fast, Indigo is almost instantaneous. Inventors use indigo skills for inspirations that seem to 'come out of the blue'.

[WilliamT] As aptly put, Blue is the color of communication. But Blue is not enough. One also needs to know the innards of network programming and all the System.Net namespaces and Windows Sockets implementation details. Simply put, there is definitely a lot of complexity involved other than putting a message on the wire and sending it across. You need to know network programming and know the wide-array of protocols (TCP/IP, HTTP, IPC, UDP, ...) and all the serialization and encoding format specifications. Indigo turns it inwards by offering to perform these very low-level network programming tasks, such as opening up a communication channel, reading and de-ciphering metadata, serializing, formatting and encoding the messages from the object representation instances, writing them into streams and sending these message packets through agreed-upon bindings to the other endpoint directly or through intermediaries through text or binary encoding. Besides using Indigo as a "platformization", instantaneous understanding or interoperabilty can be achieved with other services and platforms (as soon as they catch up) as well. Because not all business analysts and developers are plumbers or aspire to be like one, Indigo offers that realm of spiritual realization by allowing them to concentrate and innovate on the business-side of things which will inspire them to stand out and 'come out of the blue'. I dont know if there are better ways to add more value and bring more to the business table.

Indigo turns it inwards and eases the use of communication
[WilliamT] Enough said...

Put some indigo in your life when you want:

• to focus on personal issues
  ---------------------------
  [WilliamT] Allows the developer to focus on the business domain functionalities and problems and not grok away at the technological plumbings of things which is counter-productive in the business environments. In other words, you can go home earlier and have more time for your own personal pursuits. Do more with Less ?

• to develop intuition
  --------------------
  [WilliamT] Allows the developer to 'look' smart when he seemingly solves business integration and technological interoperability problems.

• to step outside of everyday life for a new and interesting way of viewing a problem
  -------------------------------------------------------------------------------------
  [WilliamT] Allows the developer and businesses to approach services from a different perspective. Services should be business-centric and in terms of software development, should be viewed as an explicit layer that sits on top of your software objects. You shouldn't have to solve business and integration problems from a technological angle anymore.

• solitude and inner communication
  -----------------------------------
  [WilliamT] Emphasizes some of the the core pillars on Service-Orientation. Services are autonomous units of deployment (some would argue versioning as well) where it does NOT assume a controlling presence over all parts of any running systems. Services are based on explicit message passing (some people still view it as implicit method invocation). Compared to previous object-based distribution based technologies (see above), the service-oriented model views cross-service method invocation as a private implementation technique and not as a primitive construct. Therefore, the fact that a given invocation may just be a method call is an implementation detail that is not visible outside the explicit service boundary and is abstracted from all calling code and systems.

• Indigo gemstones open the door to the subconscious, symbolizing the bridge between the finite and infinite
  -------------------------------------------------------------------------------------------------------------
  [WilliamT] Service-oriented development departs from object-orientation by assuming that atomic deployment of an application is the exception, not the rule. While individual services are almost always deployed atomically, the aggregate deployment state of the overall system or application rarely stands still (infinite). In other words, it is common for an individual service to be deployed long before any consuming applications are even developed; then consuming applications can be developed on a per-demand basis. In the service-oriented world, the creators of the service know nothing of the applications that consume the service whereas developers of an object-oriented application create both sides of the relationship. In other words, I would map the finite-and-infinite deployments to that of a silos-and-services approach.
  

Now, I wonder if MSFT Corp Marketing would offer me a job based on the written above...

There was Viper (I am sure there is a play somewhere here with COBRA or izzit CORBA ?), Falcon, Wolfpack, COM+ (I dont think it has a codename), .NET Remoting and now Indigo, which happens to be Green at first.

Of course, the Development and Database tools were codenamed after places (Everett, Orcas, Yukon, Whidbey, ...) Incidentally, the belief was that the further the codenamed "place" was from Redmond, the later the shipping dates will be. I dont really know the accuracy of that though.

Of course, my interest has always been in the domains of distributed computing and I have been on Viper since Day 1 and moving along with each new evolution of distributed computing technology. I am deeply entrenched in Indigo today, which some people have argued it is more of a revolution of distributed systems in terms of its perception. I dont disagree. However, I always chose to believe that Information Technology should be deployed for the sake of Business Innovation and not just for the sake of technology. This hasnt happen before BUT I strongly believe it is set to change with the coming of age of technological (horizontal) and business (vertical) standards and Indigo is set to deliver that set of technological standards while enabling vertical standards to be built on top of it. Put it all together and you get real Service-Orientation which preaches to the idea that Business drives IT and not the other way around.

As usual, I find the documentation of the Indigo CTP bits rather lacking. This is to-be-expected for any CTP Releases.

Besides the declaration of attributes, Indigo makes heavy use of configuration to enable an Aspected-Oriented style of programming (AOP). This is really good as it really separates the technical goo from the functional business gunk. This is all good BUT the documentation for the configuration section (plus the schematic view) is rather lacking from the CTP documentation.

However, thanks to the good people and program managers of the Indigo team, the off-line and community support is great for the CTP release. Mr. Maine (who is Steve to most ... ) has posted a list of the Indigo standard bindings and all their associated configuration options here. Great information. Thanks, Steve.

Mike Vernal, another great PM, has also responded to my distress calls on the public Indigo newsgroup by posting an even more detailed set of documentation (plus explanation !!! --- you rock, Mike !) from the OM documentation for NetProfileTcpBinding and WsProfileBinding. WsProfileDualHttpBinding is very similar to WsProfileBinding, and BasicProfileBinding is, in some senses, a small subset of WsProfileBinding.

I will post all the snippets here, in a note of reference to myself and hopefully to the others as well.

System.ServiceModel.NetProfileTcpBinding

The NetProfileTcpBinding is a secure, reliable, optimized binding suitable
for cross-machine communication.  By default it will generate a runtime
communication stack which will use WS-ReliableMessaging for reliability,
Windows Security for message security and authentication, TCP for message
delivery, and a Binary message encoding.  The security behavior is
configurable via the optional securityMode parameter.  The use of
WS-ReliableMessaging is configurable via the optional enableReliableSession
parameter.

// code
public class NetProfileTcpBinding : Binding
{
    public NetProfileTcpBinding() { }
    public NetProfileTcpBinding(NetProfileTcpSecurityMode securityMode) { }
    public NetProfileTcpBinding(NetProfileTcpSecurityMode securityMode,
bool enableReliableSession) { }

    public ContextFlowOption FlowLocale { get; set; }
    public ContextFlowOption FlowLogicalThreadId { get; set; }
    public ContextFlowOption FlowTransactions { get; set; }
    public HostnameComparisonMode HostnameComparisonMode { get; set; }
    public int MaxBufferSize { get; set; }
    public int MaxConnections { get; set; }
    public long MaxMessageSize { get; set; }
    public SocketProtectionLevel IPv6SocketProtectionLevel { get; set; }
    public bool KeepAliveEnabled { get; set; }
    public bool OrderedSession { get; set; }
    public bool ReliableSessionEnabled { get; set; }
    public NetProfileTcpSecurityMode SecurityMode { get; set; }
    public TransferAssurances SessionAssurances { get; set; }
    public TimeSpan SessionConnectTimeout { get; set; }
    public TimeSpan SessionInactivityTimeout { get; set; }
    public EnvelopeVersion SoapVersion { get; }
    public bool TcpPortSharingEnabled { get; set; }
    public ProtectionLevel TcpProtectionLevel { get; set; }
    public TimeSpan TransferTimeout { get; set; }
    public TransferMode TransferMode { get; set; }
    public WSSecurityOverTcp WSSecurity { get; }
}

public NetProfileTcpBinding()

Instantiates a new instance of the NetProfileTcpBinding.  By default,
Windows Security will be used to secure communication (i.e., SecurityMode
will be TcpWithWindowsSe-curity) and reliable sessions will be disabled
(EnableReliableSession will be false).

public NetProfileTcpBinding(NetProfileTcpSecurityMode securityMode)

Instantiates a new instance of the NetProfileTcpBinding with the specified
securityMode value.  By default, reliable sessions will be disabled
(EnableReliableSession will be false).

public NetProfileTcpBinding(NetProfileTcpSecurityMode securityMode, bool
enableReliableSession)

Instantiates a new instance of the NetProfileTcpBinding with the specified
securityMode and enableReliableSession values.

public ContextFlowOption FlowLocale

The FlowLocale property allows you to get or set whether the client's
locale should be flowed to the server, and whether the server should
accept, ignore or reject it.  The de-fault value is
ContextFlowOption.NotAllowed, indicating that clients will not flow
lo-cale, and services will reject messages with a flowed locale.

public ContextFlowOption FlowLogicalThreadId

The FlowLogicalThreadId property allows you to get or set whether the
client's logical Thread Id should be flowed to the server, and whether the
server should accept, ignore or reject it.  The default value is
ContextFlowOption.NotAllowed, indicating that clients will not flow locale,
and services will reject messages with a flowed logical Thread ID.  This
value is useful in the context of ConcurrencyMode.Reentrant, as reentrancy
uses the logical Thread ID to determine which calls may "re-enter" the
synchronized context and which calls must wait.

public ContextFlowOption FlowTransactions

The FlowTransactions property allows you to get or set whether this binding
should sup-port flowing WS-Transactions.  The default value is
ContextFlowOption.NotAllowed, indicating that clients will not flow
transactions, and services will reject messages with a flowed transaction
message header.

public HostnameComparisonMode HostnameComparisonMode

The HostnameComparisonMode property allows you to get or set whether a
binding instance should be reachable via any valid machine name, or only
the endpoint's configured hostname.  The default value is StrongWildcard.

public SocketProtectionLevel IPv6SocketProtectionLevel

The IPv6SocketProtectionLevel propery allows you to configure the value of
the IPV6_PROTECTION_LEVEL socket option that is used to construct the
underlying socket.  This is useful for configuring firewall traversal
technologies such as Teredo.  The default value is
SocketProtectionLevel.Default.

public bool KeepAliveEnabled

The KeepAliveEnabled property allows you to get or set whether or not
TCP-level KeepAlive should be used.  This is useful if your TCP connection
is traversing an IP in-termediary that will timeout idle connections (e.g.,
certain firewalls, NATs, proxies, etc.).   The default value is false.

public int MaxBufferSize

The MaxBufferSize property allows you to get or set the maximum number of
bytes that will be used to buffer incoming messages in memory.  If you
receive more data than you can buffer, that data will remain on the
underlying socket until your buffer again has room.  This value cannot be
less than MaxMessageSize.  The default value is 65,536 (64k).

public int MaxConnections

The MaxConnection property allows you to get or set the maximum number of
TCP connections. The default value is 10.

public long MaxMessageSize

The MaxMessageSize property allows you to get or set the maximum size for
messages processed by a binding instance.  The default value is 64k
(65,536).

public bool OrderedSession

The OrderedSession property allows you to get or set whether this binding
should guarantee in-order delivery of messages.  This value is only
relevant if sessions are enabled (via the ReliableSessionEnabled property).
 The default value is true.

public bool ReliableSessionEnabled

The ReliableSessionEnabled property allows you get or set whether
WS-ReliableMessaging should be used to create sessionful channels.  The
default value is false, indicating that this binding will not support
sessionful channels.

public NetProfileTcpSecurityMode SecurityMode

The SecurityMode property allows you to get or set the type of security to
be used with this binding.  The default value is
NetProfileTcpSecurityMode.TcpWithWindowsSecurity. 

public TransferAssurances SessionAssurances

The SessionAssurances property allows you to get or set the message
delivery guarantees (None, AtLeastOnce, AtMostOnce, ExactlyOnce) for this
binding.  This value is only relevant if sessions are enabled (via the
ReliableSessionEnabled bool).  The default value is
TransferAssurances.ExactlyOnce.

public TimeSpan SessionConnectTimeout

The SessionConnectTimeout property allows you to get or set the maximum
amount of time that a session connect operation may take.  The default
value is 30 seconds.

public TimeSpan SessionInactivityTimeout

The SessionInactivityTimeout property allows you to get or set the maximum
amount of time a session may be idle before it is terminated.  The default
value is 5 minutes.

public EnvelopeVersion SoapVersion

The SoapVersion property allows you to get othe SOAP version to be used for
messages processed by this binding.  The NetProfileTcpBinding only supports
SOAP 1.2.

public bool TcpPortSharingEnabled

The TcpPortSharingEnabled property allows you to get or set with the Tcp
Ports should be shared using the Indigo Listener.  The default value is
false, implying that each binding will exclusively use the TCP port.  Note
that this value is only relevant to services (and not to clients).

public ProtectionLevel TcpProtectionLevel

The TcpProtectionLevel property allows you to get or set the message
protection level to be used with TCP-based security.  This property is only
used if the SecurityModeProp-erty is set to either TcpWithSsl or
TcpWithWindowsSecurity.  The default value is
Pro-tectionLevel.EncryptAndSign.

public TransferMode TransferMode

The TransferMode property allows you to configure the type of message
transfer (Buff-ered or Streaming) that is used.  The default value is
Buffered.  If Streaming is selected, ReliableSessionEnabled must be false
and SecurityMode must either be None, TcpWithSSl, or TcpWithWindowSecurity.

public TimeSpan TransferTimeout

The TransferTimeout property allows you to get or set the maximum amount of
time a message transfer may take.  The default value is 10 minutes.

public WSSecurityOverTcp WSSecurity

The WSSecurity property allows you to get a WSSecurityOverTcp object, which
allows configuration of the security behavior of the binding.  This
property is only used if the SecurityMode property is set to
NetProfileSecurityMode.WSSecurityOverTcp.

------------------------------------------------------------------

System.ServiceModel.NetProfileTcpSecurityMode

The NetProfileTcpSecurityMode enum allows you to configure the type of
security that should be used with the NetProfileTcpBinding.

public enum NetProfileTcpSecurityMode
{
    None,
    TcpWithWindowsSecurity,
    TcpWithSsl,
    WSSecurityOverTcp
}

None

The None value indicates that security should be disabled.

TcpWithWindowSecurity

The TcpWithWindowsSecurity value indicates that Windows Security should be
used.  This provides message integrity, confidentiality, and mutual
authentication.

TcpWithSsl

The TcpWithSsl value indicates that TCP with SSL-based security should be
used.  This provides message integrity, confidentiality, and server
authentication.  This does not provide client authentication.

WSSecurityOverTcp

The WSSecurityOverTcp value indicates that WS-Security should be used over
TCP.  WS-Security will be used for message integrity, confidentiality, and
authentication.  The WSSecurity mechanism can be refined via the
WSSecurityOverTcp type.

------------------------------------------------------------------

System.ServiceModel.WSProfileBinding

The WSProfileBinding is a secure, reliable, interoperable binding suitable
for non-duplex ServiceContracts.  By default it will generate a runtime
stack which uses WS-ReliableMessaging for reliability, WS-Security for
message security and authentication, HTTP for message delivery, and a
Text/XML message encoding.  The security behavior is configurable via the
optional securityMode parameter.  The use of WS-ReliableMessaging is
configurable via the optional enableReliableSession parameter.

public class WSProfileBinding : Binding
{
    public WSProfileBinding() { }
    public WSProfileBinding(WSProfileSecurityMode securityMode) { }
    public WSProfileBinding(WSProfileSecurityMode securityMode, bool
enableReliableSession) { }

    public ContextFlowOption FlowTransactions { get; set; }
    public HostnameComparisonMode HostnameComparisonMode { get; set; }
    public HttpAuthentication HttpAuthentication { get; }
    public long MaxMessageSize { get; set; }
    public WSMessageEncoding MessageEncoding { get; set; }
    public bool OrderedSession { get; set; }
    public Uri ProxyAddress { get; set; }
    public bool ReliableSessionEnabled { get; set; }
    public WSProfileSecurityMode SecurityMode { get; set; }
    public TransferAssurances SessionAssurances { get; set; }
    public TimeSpan SessionConnectTimeout { get; set; }
    public TimeSpan SessionInactivityTimeout { get; set; }
    public EnvelopeVersion SoapVersion { get; set; }
    public System.Text.Encoding TextEncoding { get; set; }
    public TimeSpan TransferTimeout { get; set; }
    public bool UseSystemWebProxy { get; set; }
    public WSSecurityOverHttp WSSecurity { get; }
}

public WSProfileBinding()

Instantiates a new instance of the WSProfileBinding.  By default,
WS-Security will be used (SecurityMode will be WSSecurityOverHttp) and
reliable sessions will be disabled (EnableReliableSession will be false).

public WSProfileBinding(WSProfileSecurityMode securityMode)

Instantiates a new instance of the WSProfileBinding with the specified
securityMode.  By default, reliable sessions will be disabled
(EnableReliableSession will be false).

public WSProfileBinding(WSProfileSecurityMode securityMode, bool
enableReliableSession)

Instantiates a new instance of the WSProfileBinding with the specified
securityMode and enableReliableSession values.

public ContextFlowOption FlowTransactions

The FlowTransactions property allows you to get or set whether this binding
should sup-port flowing WS-Transactions.  The default value is
ContextFlowOption.NotAllowed, indicating that clients will not flow
transactions, and services will reject messages with a flowed transaction
message header.

public HostnameComparisonMode HostnameComparisonMode

The HostnameComparisonMode property allows you to get or set whether a
binding in-stance should be reachable via any valid machine name, or only
the endpoint's config-ured hostname.  The default value is StrongWildcard.

public HttpAuthentication HttpAuthentication

The HttpAuthentication property allows you to get or set an object that
allows configura-tion of HTTP Authenticaiton options.  This property is
used only if you use WSProfile-SecurityMode.HttpAuthenticationOverHttps,
otherwise its value is ignored.

public long MaxMessageSize

The MaxMessageSize property allows you to get or set the maximum size for
messages processed by a binding instance.  The default value is 65,536
bytes (64k).

public WSMessageEncoding MessageEncoding

The MessageEncoding property allows you to get or set the message encoding
to be used for messages processed by this binding.  The default value is
WSMessageEncoding.Text.

public bool OrderedSession

The OrderedSession property allows you to get or set whether this binding
should guar-antee in-order delivery of messages.  This value is only
relevant if sessions are enabled (via the ReliableSessionEnabled property).
 The default value is true.

public Uri ProxyAddress

The ProxyAddress property allows you to get or set the address of your HTTP
Proxy.  The default value is null.  It is an error for this to be non-null
and UseSystemWebProxy to be true.

public bool ReliableSessionEnabled

The ReliableSessionEnabled property allows you get or set whether
WS-ReliableMessaging should be used to create sessionful channels.  The
default value is false, indicating that this binding will not support
sessionful channels.

public WSProfileSecurityMode SecurityMode

The SecurityMode property allows you to get or set the type of security to
be used with this binding.  The default value is
WSProfileSecurityMode.WSSecurityOverHttp. 

public TransferAssurances SessionAssurances

The SessionAssurances property allows you to get or set the message
delivery guarantees (None, AtLeastOnce, AtMostOnce, ExactlyOnce) for this
binding.  This value is only relevant if sessions are enabled (via the
ReliableSessionEnabled bool).  The default value is
TransferAssurances.ExactlyOnce.

public TimeSpan SessionConnectTimeout

The SessionConnectTimeout property allows you to get or set the maximum
amount of time that a session connect operation may take.  The default
value is 30 seconds.

public TimeSpan SessionInactivityTimeout

The SessionInactivityTimeout property allows you to get or set the maximum
amount of time a session may be idle before it is terminated.  The default
value is 5 minutes.

public EnvelopeVersion SoapVersion

The SoapVersion property allows you to get or set the SOAP version (either
SOAP 1.1 or SOAP 1.2) to be used for messages processed by this binding. 
The default value is SOAP 1.2.

public System.Text.Encoding TextEncoding

The TextEncoding property allows you to get or set the Character Set
Encoding to be used for messages emitted from this binding.  The default
value is an instance of the Sys-tem.Text.UTF8Encoding class.

public TimeSpan TransferTimeout

The TransferTimeout property allows you to get or set the maximum amount of
time a message transfer may take.  The default value is 10 minutes.

public bool UseSystemWebProxy

The UseSystemWebProxy property allows you to get or set whether the
system's auto-configured HTTP proxy should be used, if available.  The
default value is true.  It is an error for this to be true and ProxyAddress
to be non-null.

public WSSecurityOverHttp WSSecurity

The WSSecurity property allows you to get a WSSecurityOverHttp object,
which allows configuration of the security behavior of the binding.  This
property is only used if the SecurityMode property is set to
WSProfileSecurityMode.WSSecurityOverHttp.

------------------------------------------------------------------

System.ServiceModel.WSProfileSecurityMode

The WSProfileSecurityMode enum allows you to configure the type of security
that should be used with the WSProfileBinding.

public enum WSProfileSecurityMode
{
    None,
    Https,
    HttpsWithClientCertificate,
    HttpAuthenticationOverHttps,
    WSSecurityOverHttp
}

None

The None value indicates that security should be disabled.

Https

The Https value indicates that HTTPS security should be used.  This
provides message integrity, confidentiality, and server authentication. 
This does not provide client authen-tication.

HttpsWithClientCertificate

The HttpsWithClientCertificate value indicates that HTTPS security should
be used with a client X.509 certificate.  This provides message integrity,
confidentiality, and mutual authentication.

HttpAuthenticationOverHttps

The HttpAuthenticationOverHttps value indicates that HTTPS security should
be used with HTTP authentication.  This provides message integrity,
confidentiality, and server authentication.  The HTTP authentication
mechanism can be refined via the HttpAuthen-tication type.

WSSecurityOverHttp

The WSSecurityOverHttp value indicates that WS-Security should be used over
HTTP.  WS-Security will be used for message integrity, confidentiality, and
authentication.  The WSSecurity mechanism can be refined via the
WSSecurityOverHttp type.

[bindings]
 [customBinding]

  [!-- The BasicProfileBinding, which is an HTTP-based
       binding compatible with the WS-I Basic Profile --]

   [binding configurationName="BasicProfileBinding"]
     [httpTransport hostnameComparisonMode="StrongWildcard"
                    manualAddressing="False"
                    maxMessageSize="65536"
                    authenticationScheme="Anonymous"
                    bypassProxyOnLocal="False"
                    mapAddressingHeadersToHttpHeaders="True"
                    realm=""
                    transferTimeout="00:10:00"
                    useSystemWebProxy="True" /]
     [textMessageEncoding maxReadPoolSize="64"
                          maxWritePoolSize="16"
                          messageVersion="Soap11Addressing1"
                          encoding="utf-8" /]
   [/binding]

[!-- The WsProfileBinding, which can interop with
     anyone who speaks the WS-* protocols. It uses
     WS-Security at the SOAP layer to provide
     end-to-end security across intermediaries --]

   [binding configurationName="WsProfileBinding"]
    [security algorithmSuite="Default"
              authenticationMode="SspiNegotiated"
              contextMode="Session"
              defaultProtectionLevel="EncryptAndSign"
              enableKeyDerivation="True"
              includeTimestamp="True"
              messageProtectionOrder="SignBeforeEncrypt"
              securityVersion="WSSecurityXXX2005" /]
    [httpTransport hostnameComparisonMode="StrongWildcard"
                   manualAddressing="False"
                   maxMessageSize="65536"
                   authenticationScheme="Anonymous"
                   bypassProxyOnLocal="False"
                   mapAddressingHeadersToHttpHeaders="False"
                   realm=""
                   transferTimeout="00:10:00"
                   useSystemWebProxy="True" /]
   [textMessageEncoding maxReadPoolSize="64"
                        maxWritePoolSize="16"
                        messageVersion="Default"
                        encoding="utf-8" /]
   [/binding]
 

[!-- The WsProfileDualHttpBinding, which layers a Reliable Messaging
     session on top of two HTTP channels, which lets you do duplex
     communication over HTTP. It's also secure by default. --]

   [binding configurationName="WsProfileDualHttpBinding"]
    [reliableSession acknowledgementInterval="00:00:00.2000000"
                    advancedFlowControl="True"
                    bufferedMessagesQuota="32"
                    inactivityTimeout="00:10:00"
                    maxPendingChannels="128"
                    maxRetryCount="8"
                    ordered="True" /]
    [security algorithmSuite="Default"
             authenticationMode="SspiNegotiated"
             contextMode="Session"
             defaultProtectionLevel="EncryptAndSign"
             enableKeyDerivation="True"
             includeTimestamp="True"
             messageProtectionOrder="SignBeforeEncrypt"
             securityVersion="WSSecurityXXX2005" /]
    [compositeDuplex /]
    [httpTransport hostnameComparisonMode="StrongWildcard"
                  manualAddressing="False"
                  maxMessageSize="65536"
                  authenticationScheme="Anonymous"
                  bypassProxyOnLocal="False"
                  mapAddressingHeadersToHttpHeaders="False"
                  realm=""
                  transferTimeout="00:10:00"
                  useSystemWebProxy="True" /]
    [textMessageEncoding maxReadPoolSize="64"
                        maxWritePoolSize="16"
                        messageVersion="Default"
                        encoding="utf-8" /]
   [/binding]
 

[!-- The NetProfileTcpBinding, which is an Indigo/Indigo binding. --]

   [binding configurationName="NetProfileTcpBinding"]
     [tcpTransport hostnameComparisonMode="StrongWildcard"
                 manualAddressing="False"
                 maxMessageSize="65536"
                 closeTimeout="00:00:01"
                 connectionBufferSize="65536"
                 connectionPoolGroupName="default"
                 maxBufferSize="65536"
                 maxInboundConnections="10"
                 maxOutputDelay="00:00:00.2000000"
                 maxPendingAccepts="1"
                 protectionLevel="EncryptAndSign"
                 transferMode="Buffered"
                 transferTimeout="00:10:00"
                 useIndigoListener="False"
                 IPv6ProtectionLevel="Default"
                 isKeepAliveEnabled="False"
                 listenBacklog="10"
                 securityMode="None" /]
     [binaryMessageEncoding maxReadPoolSize="64" maxWritePoolSize="16" /]
   [/binding]

   [!-- The NetProfileDualTcpBinding, which is another Indigo/Indigo binding. --]

   [binding configurationName="NetProfileDualTcpBinding"]
     [reliableSession acknowledgementInterval="00:00:00.2000000"
                    advancedFlowControl="True"
                    bufferedMessagesQuota="32"
                    inactivityTimeout="00:10:00"
                    maxPendingChannels="128"
                    maxRetryCount="8" ordered="True" /]
     [security algorithmSuite="Default"
             authenticationMode="SspiNegotiated"
             contextMode="Session"
             defaultProtectionLevel="EncryptAndSign"
             enableKeyDerivation="True"
             includeTimestamp="True"
             messageProtectionOrder="SignBeforeEncrypt"
             securityVersion="WSSecurityXXX2005" /]
     [compositeDuplex /]
     [tcpTransport hostnameComparisonMode="StrongWildcard"
                 manualAddressing="False"
                 maxMessageSize="65536"
                 closeTimeout="00:00:01"
                 connectionBufferSize="65536"
                 connectionPoolGroupName="default"
                 maxBufferSize="65536"
                 maxInboundConnections="10"
                 maxOutputDelay="00:00:00.2000000"
                 maxPendingAccepts="1"
                 protectionLevel="EncryptAndSign"
                 transferMode="Buffered"
                 transferTimeout="00:10:00"
                 useIndigoListener="False"
                 IPv6ProtectionLevel="Default"
                 isKeepAliveEnabled="False"
                 listenBacklog="10"
                 securityMode="None" /]
    [binaryMessageEncoding maxReadPoolSize="64" maxWritePoolSize="16" /]
   [/binding]

   [!-- The NetProfileNamedPipesBinding, which is an Indigo/Indigo binding
        for on-machine communication. --]

   [binding configurationName="NetProfileNamedPipesBinding"]
     [namedPipeTransport hostnameComparisonMode="StrongWildcard"
                      manualAddressing="False"
                      maxMessageSize="65536"
                      closeTimeout="00:00:01"
                      connectionBufferSize="65536"
                      connectionPoolGroupName="default"
                      maxBufferSize="65536"
                      maxInboundConnections="10"
                      maxOutputDelay="00:00:00.2000000"
                      maxPendingAccepts="1"
                      protectionLevel="EncryptAndSign"
                      transferMode="Buffered"
                      transferTimeout="00:10:00"
                      useIndigoListener="False"
                      connectTimeout="00:00:02"
                      securityMode="Windows" /]
     [binaryMessageEncoding maxReadPoolSize="64" maxWritePoolSize="16" /]
  [/binding]
[/customBinding]

While still playing around with the Indigo March-CTP bits and having lots of fun exploring Addresses, Bindings and Contracts (ABC), I was configuring and playing around with the Instancing behavior of an Indigo Service (which I will talk more about later), I created 4 different services of the same interface type and contract, each implementing a different instance behaviour. I am hosting this svc in IIS and therefore, my endpoint address is provided by the host IIS. Therefore, in my config file, I have this:

    <services>
      <service
          serviceType="IndigoBehaviourInstance.PrivateDischargePatientService"
          behaviorConfiguration="SomeDischargePatientBehavior">
        <endpoint address=""
                  bindingSectionName="wsProfileDualHttpBinding"
                  bindingConfiguration="BindingOne"
                  contractType="IndigoBehaviourInstance.IDischargeProcess,IndigoBehaviourInstance" />
      </service>
      <service
          serviceType="IndigoBehaviourInstance.SingletonDischargePatientService"
          behaviorConfiguration="SomeDischargePatientBehavior">
        <endpoint address=""
                  bindingSectionName="wsProfileDualHttpBinding"
                  bindingConfiguration="BindingOne"
                  contractType="IndigoBehaviourInstance.IDischargeProcess,IndigoBehaviourInstance" />
      </service>
      <service
          serviceType="IndigoBehaviourInstance.SharedDischargePatientService"
          behaviorConfiguration="SomeDischargePatientBehavior">
        <endpoint address=""
                  bindingSectionName="wsProfileDualHttpBinding"
                  bindingConfiguration="BindingOne"
                  contractType="IndigoBehaviourInstance.IDischargeProcess,IndigoBehaviourInstance" />
      </service>
      <service
          serviceType="IndigoBehaviourInstance.PerCallDischargePatientService"
          behaviorConfiguration="SomeDischargePatientBehavior">
        <endpoint address=""
                  bindingSectionName="wsProfileDualHttpBinding"
                  bindingConfiguration="BindingOne"
                  contractType="IndigoBehaviourInstance.IDischargeProcess,IndigoBehaviourInstance" />
      </service>     
    </services>

As we can see from here, all bindings and contract types are the same related to these 4 different endpoint services...and since the endpoint address is provided by the host, the only thing different is the serviceType, bearing in mind that each service is implemented in by its own class. This does make the above configuration less intuitive as it should be. Flexibility should be given to all different serviceTypes to be configured much more intuitively. In this case, if the serviceType attribute is an element, it allows for that flexibility.

    <services>
      <service behaviorConfiguration="SomeDischargePatientBehavior">
        <serviceType type="IndigoBehaviourInstance.PrivateDischargePatientService" />
        <serviceType type="IndigoBehaviourInstance.SingletonDischargePatientService" />
        <serviceType type="IndigoBehaviourInstance.SharedDischargePatientService" />
        <serviceType type="IndigoBehaviourInstance.PerCallDischargePatientService" />  
        <endpoint address=""
                  bindingSectionName="wsProfileDualHttpBinding"
                  bindingConfiguration="BindingOne"
                  contractType="IndigoBehaviourInstance.IDischargeProcess,IndigoBehaviourInstance" />
      </service>
    </services>

...or something to that effect...Now if the (multiple) endpoint elements can be done this way, why not the serviceType ?

Am I missing something here ?

As blogged earlier, I have been crossing more and more into the Indigo realm and ripping the bits apart to see what it is made of. Some of my immediate work assigments will primarily revolve around Indigo-WSE-SOAP and as someone who works in an SI environment, interoperability is something I am very concerned about and I am therefore very particular on what goes out on the wire.

I had a chance to try out the message tracing, logging and activity management enchancements in WinFX and I must say I am impressed...and we are still at CTP-bits !

Now, I have been using external (SOAP and Tcp) tools to trace the messages on the wire. BUT those are external tools and those of you who have done real project work will know that in a real production environment in a client's site, these tools cannot be so easily installed at our own luxury. Sure, we can write our own SOAP Extensions and catch them in the pipeline but it takes a fair bit of grokking at the plumbings. So having a configuration-based message tracing and activity management as first class .NET features and tools is something that I have always wanted.

The below is taken from the WinFX SDK > Indigo Tools Documentation

The icons to the left of the Activity names tell you what kind of activity each is. The following table describes these icons.

Icon	Activity
	This Activity is a call out to a proxy.
	This Activity is a Helper message, meaning that it is not associated with sending or receiving a message.
	This Activity is a message from http.sys.
	This Activity is an Operation (method invocation).
	This Activity is an Operation Return (processing a response from an operation).
	The Activity type is unknown.

To view the traces in an activity, select that activity—or select multiple activities using the CTRL or Shift keys.

With the right configuration at the Indigo Service Endpoint, we could specify where we want to output our message traces. In the below case, we are telling it to spit it out into the c:\logs\messages\ folder

      [source name="IndigoMessageLogTraceSource" switchValue="Verbose"]
        [listeners]
          [add name="multifile"
               type="System.ServiceModel.Diagnostics.MessageWriterTraceListener, system.servicemodel, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
               initializeData="c:\logs\messages\"
               maxDiskSpace="1000" /]
        [/listeners]
      [/source]

If a trace source named "IndigoMessageLogTraceSource" is not configured, the message logging feature will create a MessageWriterTraceListener by default and output the message logs to %windir%\system32\logfiles\messages as shown by the configuration below:

   [!-- MessageLogging configuration --]
   [system.serviceModel]
      [diagnostics]
         [!-- log all messages received or sent at the transport level --]
         [messageLogging logEntireMessage="true"
                         maxMessagesToLog="300"
                         logMessagesAtServiceLevel="false"
                         logMalformedMessages="true"
                         logMessagesAtTransportLevel="true" /]
      [/diagnostics]
   [/system.serviceModel]

The saved output message is prefix-ed with the processID (1648(IndigoConsole1.exe)_632469155560884432_1.xml) which is great for file-parsing purposes. Since I am using the BasicProfileBinding of Indigo's ServiceModel.Binding, what goes on the wire is of SOAP 1.1 message format

  [s:Envelope xmlns:s=" http://schemas.xmlsoap.org/soap/envelope/ "]
    [s:Header /]
    [s:Body]
      [ReturnSimpleGreetings xmlns=" http://xmlns.softwaremaker.net/ "]
        [yourname]Softwaremaker[/yourname]
      [/ReturnSimpleGreetings]
    [/s:Body]
  [/s:Envelope]

If time permits, I will be blogging more on the other formats with the other bindings as we move along. Besides tracing on what's on the wire, Indigo allows you to configure an end-to-end trace source using a XmlWriterTraceListener. The output is an xml-type file with an e2e extension that is consumed and readily parsed by the WinFX's TraceViewer Tool. The configuration looks something like this:

         [source name="E2e" switchValue="Verbose"]
            [listeners]
               [add name="xml" type="System.Diagnostics.XmlWriterTraceListener" initializeData="c:\logs\System.ServiceModel.e2e" /]
            [/listeners]
         [/source]

You can further configure the service to track related System.Net trace sources using a XmlWriterTraceListener as well with this configuration

         [source name="System.Net" switchValue="Verbose"]
            [listeners]
               [add name="xml" type="System.Diagnostics.XmlWriterTraceListener" initializeData="c:\logs\System.Net.e2e" /]
            [/listeners]
         [/source]
         [source name="System.Net.HttpListener" switchValue="Verbose"]
            [listeners]
               [add name="xml" type="System.Diagnostics.XmlWriterTraceListener" initializeData="c:\logs\System.Net.HttpListener.e2e" /]
            [/listeners]
         [/source]
         [source name="System.Net.Sockets" switchValue="Verbose"]
            [listeners]
               [add name="xml" type="System.Diagnostics.XmlWriterTraceListener" initializeData="c:\logs\System.Net.Sockets.e2e" /]
            [/listeners]
         [/source]
         [source name="System.Net.Cache" switchValue="Verbose"]
            [listeners]
               [add name="xml" type="System.Diagnostics.XmlWriterTraceListener" initializeData="c:\logs\System.Net.Cache.e2e" /]
            [/listeners]
         [/source]

This may be a lot to digest at one go. I will strive to write about what each means in my future posts and try to breakdown and dissect each of those items in the e2e file that is captured and displayed in the TraceViewer Tool.

The fact that these message tracing, logging and activity management are first-class features is great and places emphasis on the need to know what goes onto the wire so it interoperates well with the others.

...or is it purple I am seeing...?

New exciting work assignments come with the dawn of this impending day in the very near horizon. I will update as we go along.

My previous blogs on Indigo