Beyond WSE 2.0: Looking Ahead to Indigo in Visual C#

Draw PDF-417 2d barcode in Visual C# Beyond WSE 2.0: Looking Ahead to Indigo

and service components independently of the intended hosting environment. Indigo will relay messages across to your services equally well in all of the supported environments.

Today, MSMQ-based applications support message queues for reliable message delivery, and they also support a trigger-based event model that fires up the application code when an incoming message is received. Today, messaging applications that are built around MSMQ are almost considered to be a nonstandard type of application. If they were standard, then all of us would be incorporating message queues into every application that we built. Of course this is not the case, largely because it creates a level of overhead that is considered unnecessary for many applications. But in service-oriented applications, reliable message delivery is not an abstract concept; instead, it represents a quality of service expectation on the part of your clients. Message delivery and the potential for message loss are critically important to service-oriented applications. Indigo provides built-in messaging support, including message queues and events, and makes it easier for you to implement reliable messaging in your service applications. Indigo will provide a set of classes for interfacing with the messaging infrastructure. Today s WSE 2.0 does not natively integrate with MSMQ, which is essentially just an alternate transport channel for messages. With some effort, you could custom integrate MSMQ with WSE today as a transport channel, although this is an advanced programming task. Alternatively, you could take a simpler approach and have your service simply interact with an MSMQ queue that you configure separately. The .NET Framework provides a namespace called System.Messaging, which allows you to interact with an MSMQ queue. You can expect that a future version of WSE will support MSMQ as a new integrated transport channel. It is very likely that this will happen because of the fact that reliable message delivery is so important to service-oriented applications.

This category represents a catch-all of features, many of which provide infrastructure-level support that may be fully out of direct sight, but which is working on your behalf nonetheless. The System services includes infrastructurelevel support for transactions (via a distributed transaction coordinator) and security. The security portion of the System services are expected to support the WS-Federation specification, which allows you to set up and manage trusted communications across application and domain boundaries. This is not the same

10

thing as the WS-Secure Conversation specification, which I discussed in 8. However, there are shared concepts between the two specifications.

One of my first thoughts when I heard about Indigo was whether Indigo Web services would be different compared to ASP .NET Web services. And if so, how would they differ The good news is that while Indigo Web services are different, they still retain the core characteristics of a traditional ASP .NET Web service, but with even more functionality and flexibility. Indigo Web services support the standard WSDL and SOAP specifications, in addition to the extended WS-specifications.

Traditional .ASMX pages can still be used within Indigo, which will interoperate with them in addition to supporting a newer form of Web service. ASP.NET-style Web services will continue to be limited within Indigo to simple HTTP-based Request/Response message patterns. However, Indigo Web services will provide all of the extended communication capabilities that WSE 2.0 provides (and more) including alternate transport protocols and true asynchronous and oneway communications. The characteristics of an Indigo Web service are documented in the Longhorn SDK as follows: Secure communication across any number of intermediaries, including firewalls. Participate in widely distributed transactions. Encapsulate two way conversations that allow clients and servers to send messages in both directions. Provide guarantees about the reliability of message delivery. Support situations requiring scalability, such as Web service farms. Support advanced features even with participants that are not built on Microsoft platforms. Enable developers familiar with the .NET Framework to build messaging applications without knowing anything about XML or SOAP.