Longhorn

The rest of this XAML file contains a placeholder for any application-level resources that we might want to load into this file at design time.

namespace Demo
{
	/// <summary>
	/// Interaction logic for MyApp.xaml
	/// </summary>

	public partial class MyApp : Application
	{
		void AppStartingUp(object sender, StartingUpCancelEventArgs e)
		{
			Window1 mainWindow = new Window1();
			mainWindow.Show();
		}

	}
}

We have skipped the references in the listing above, since they are essentially the same as in the previous listing and add no value here. The namespace and the class within in it, in this case, provide the application-level events that get the application running. .NET calls the AppStartingUp method as per the instructions of the XAML file shown in the previous code snippet. This method says to create a new instance of the Window1 class (which is partially defined using XAML and partially defined using C# code). Once an instance of Window1 has been created, this method displays its user interface, then the method end, and the application proceeds in an event-driven Windows fashion.

Indigo
I was a little disappointed right after I installed the Visual Studio Extensions for WinFX Beta 1. I immediately saw the Avalon support, of course - but what about Indigo? As I began to read about Indigo, I began to understand its close connection to IIS and, therefore, hoped to find a similar set of projects for Indigo in the "New Web Site" portion of ASP.NET 2.0.

I was not disappointed, but I was a little confused. As shown in Figure 2, there are two projects for Indigo - both of which are named identically.

I chose to go with the first option and was rewarded with a Web Project containing three files: Service.cs, Service.svc, and web.config.

using System;
using System.ServiceModel;

[ServiceContract()]
public interface IMyService
{
    [OperationContract]
    string MyOperation1(string myValue1);
}

public class MyService : IMyService
{
    public string MyOperation1(string myValue1)
    {
        return "Hello: " + myValue1;
    }
}

The snippet above shows the code in the Service.cs file. Like most C# files, it begins with a couple of namespace declarations. In this case, the System.ServiceModel reference is of the most interest to us. This namespace contains a great number of the new Indigo classes. In the code above, for example, all of the new Indigo attributes are contained in this namespace.

The first of these attributes seen above is the ServiceContract attribute. This attribute is applied to an interface to let .NET know that this interface will serve as a contract in a service-oriented system. A contract lets a caller know what operations it can count upon our service to implement, as well as the way in which those operations will operate.

Although the snippet above takes all of the default options, a number of additional pieces of information can be specified as a part of the ServiceContract attribute. For one thing, the name and namespace that are exposed in this service's WSDL can be specified. Another thing that can be specified is whether or not this service should maintain session state when fielding multiple requests from the same client.

The CallbackContract is a particular noteworthy piece of information that can be provided as a part of this attribute. By setting this attribute's CallbackContract to point to another contract that you have defined, you can tell potential clients what kind of an interface they must implement in order to receive call-back notifications from your service.

Additionally, the FormatMode property here will allow you to stipulate whether you want your service to use the XmlSerializer or XmlFormatter for turning your service's communications into messages. The Style and Use properties work in combination with each other to determine the specifics of the XML that is used for transmitting and receiving these messages - for example, whether document or literal encoding is to be used.

Within each interface that is declared as a contract, there will be one or more operations tagged with OperationContract attributes. This would allow you - if you wanted to do so - to combine methods in a class that were intended to be exposed as services with those that are simply for use by other code operating within the same Application Domain of the CLR.

A variety of interesting behaviors can be implemented by tweaking the properties of the OperationContract attribute, also. The IsInitiating and IsTerminating properties, for example, can be applied to indicate that a given operation is the first and/or last operation in a single state-maintaining conversation. The AsyncPattern and IsOneWay properties can be used to announce whether a given operation will respond immediately, at some indeterminate point in the future, or never. Finally, the Action and ReplyAction properties can be used to customize the SOAP actions associated with a given operation as a part of its WSDL definition.

Once you have defined a contract, all that really needs to be done - at the C# level - is to define a class that implements this contract. Since a contract is essentially just an interface, this simply means creating a C# class that implements the desired interface. This is exactly what you can see in the MyService class in the previous code snippet. In this case, its single method - MyOperation1 - is going to accept a string and return that string to the caller, with a "hello" message pre-pended to it.

Add Your Feedback

In order to post a comment you need to be registered and logged in.

Register | Log in

Please wait while we process your request...