In-Depth

Connect Systems With Indigo

TechEd''s Connected Systems track presentations propose the forthcoming Indigo messaging bus as the service-oriented successor to ASMX Web services, Web Services Enhancements (WSE), .NET Remoting, MSMQ, COM+, and, lest we forget, Global XML Architecture.

• By Roger Jennings
• 06/08/2005

Windows Web service developers have their work cut out for the next month or two. For starters, Microsoft launched on May 25, 2005 an RC for the Beta 1 version of an Avalon/Indigo runtime for Windows XP SP-2 or Windows Server 2003 and an accompanying WinFX SDK that's compatible with VS 2005 Beta 2. About a week later, MSDN posted the June Community Technical Preview (CTP) of Web Services Enhancements (WSE) 3.0 for Visual Studio 2005 Beta 2 and related hands-on labs. The WinFX Beta 1 SDK includes a set of C# and VB Indigo console projects in \Program Files\Microsoft SDKs\WinFX\samples\AllSamples.zip. WSE 3.0 CTP includes C# QuickStart samples only, VB versions of the WSE 3.0 hands-on labs for messaging and security features also are missing, as expected.

Microsoft designed WSE 3.0 and Indigo to support its Connected Systems vision that Paul Flessner addressed in his Tuesday keynote session. (Also see the Microsoft Web Services DevChannel and FTP's extensive video coverage of Indigo Day at VSLive! San Francisco in February.) A quick search of Tech•Ed 2005 sessions returned 18 hits for WSE as the keyword and 10 for Indigo in the Connected Systems Infrastructure track. According to Microsoft's "Connected Systems for Developers" PowerPoint presentation, Connected Systems share these five objectives:

1. Connect information workers with computing infrastructure
2. Evolve distributed systems to reflect the real world
3. Span boundaries without a single owner of the entire system
4. Provide Web services fabric and contracts
5. Leverage existing investments; use service orientation for future systems

WSE 3.0/VS 2005 and ASP.NET 2.0/IIS 6.0 (ASMX) provide the infrastructure for today's Web services and Windows 9x, 2000, and XP clients. As Indigo for Windows Server 2003 and Windows XP SP-2 nears RTM, developers should consider upgrading their Web services fabric and contracts to Indigo, even at the expense of discontinuing support for clients running Windows 9x and 2000. Why the Connected Systems objectives suggest using "service orientation for future systems" is a mystery. Microsoft has been touting service orientation (SO) and service-oriented architecture (SOA) almost as long as XML Web services.

Microsoft's four tenets of service orientation and, by inference, SOA are:

1. Boundaries are explicit
2. Services are autonomous
3. Share schema and contract, not class
4. Service compatibility is based on policy

Paul Flessner and Pat Helland discussed explicit boundaries and autonomous services at Tech•Ed 2002 in conjunction with Microsoft's ill-fated Global XML Architecture (GXA, see Resources). Don Box's promise that a GXA toolkit would arrive "within our lifetime" hasn't been—and clearly won't be—fulfilled. GXA has been subsumed by today's WSE, document/literal messaging, WSDL, and Indigo's future data contracts to enable sharing schema and contracts.

Data contracts, which correspond to WSDL's XML schema, let you annotate classes to expose specific members and hide implementation details. Indigo automatically generates policy based on Web service code or declarative configuration files. Clients retrieve the policy and configure themselves to meet the service's requirements.

Microsoft describes WSE as "an engine for applying advanced Web service protocols to SOAP messages," which writes "headers to outbound SOAP messages and read[s] headers from inbound SOAP messages" by applying a chain of output and input filters. WSE also modifies the SOAP message body by, for instances, encryption or description. WSE 3.0 is a fully supported add-in for VS 2005 that Microsoft's Mark Fussell promises to release within two to four weeks of .NET Framework/VS 2005 RTM. In the meantime, the WSE 3.0 team plans monthly CTP drops.

WSE 3.0 relies on the WS-Security, WS-SecurityPolicy, WS-SecureConversation, WS-Trust, WS-Addressing, and WS-Policy specifications, plus the W3C's SOAP Message Transmission Optimization Mechanism (MTOM) recommendation for attachments. WS-Security provides message integrity and confidentiality. Integrity requires XML Signatures (xmldsig) to ensure that the message originated from a known source and hasn't been tampered with. Confidentiality uses XML Encryption (xmlenc) to ensure that only the intended recipient can read the message.

Pre-WSE services used SSL to provide integrity and confidentiality at the transport level, but SSL is effective only for point-to-point communication with the HTTP protocol and doesn't enable securing specific parts of the SOAP message. WS-Security is the only WS-* specification that's defined by a recognized standards body (OASIS WS-Security 1.0 Specification, April 2004) and it's supported by major industry players, such as BEA, IBM, Microsoft, Oracle, Sun Microsystems, Systinet, and webMethods. The Web Services Interoperability Organization (WS-I.org) has prepared a "Basic Security Profile 1.0 Working Group Draft" that's based on the OASIS specification and W3C recommendations. WSE 2.0 for .NET 1.1 and WSE 3.0's tight integration with the VS 2005 IDE and .NET 2.0 release date means that developers can implement interoperable secure Web services today.

Microsoft claims that Indigo "will radically simplify how the next generation of connected systems is built." Indigo supports the same set of WS-* specs as WSE 3.0 and adds WS-ReliableMessaging (WS-RM), WS-AtomicTransactions (WS-AT), WS-Coordination, WS-MetadataExchange (WS-MEX), and WS-Discovery plus Web Single Sign-On Interoperability Profile and Web Single Sign-On Metadata Exchange Profile. The two Web Single Sign-On (WebSSO) specifications let either Liberty Identity Federation or WS-Federation-based Identity Providers interact with a Web service.

Indigo services are constructed from a service class, a host environment, and one or more end points from which clients access the service. The service class defines a service contract, operation contracts, and, optionally data contracts. The service's host environment can be IIS or, for later Indigo CTPs, Windows Activation Service (WAS). An end point specifies an address, which is a URL that identifies a machine and endpoint, a binding to specify a protocol combination, such as SOAP over HTTP (BasicProfileHttpBinding) or binary-encoded SOAP over TCP (NetTcpBinding), and a contract name, which is an alias for the service contract.

Interoperable Indigo services—that is, conventional SOAP over HTTP Web services—rely on hosting by IIS 5.1 or 6.0+ and are similar to ASP.NET ASMX Web services. A ServiceName.svc file substitutes for ServiceName.asmx and displays a variation on the familiar ASMX Web service help document (see Figure 1). You'll find the code for simple Indigo Web services to be similar to that of their ASMX counterparts. Most Indigo sample service clients, such as that for the GettingStarted project, are console applications (see Figure 2). Indigo service client proxies differ greatly from partial classes generated by VS 2005's Add Web Reference Wizard.

Whether Indigo really simplifies building connected systems remains to be seen and undoubtedly will depend on future VS 2005 templates and UI wizardry for Indigo services and clients. In the meantime, download the current WSE 3.0 and Avalon/Indigo CTPs and test-drive at least a few of the sample services and hands-on labs. Just be sure to heed this advice: Follow the Indigo samples' Setup Instructions topics to the letter and check the Troubleshooting Topics if simple service/client projects won't compile and run without modifying the code.