| download source codeAbstract Chris Peiris investigates the capabilities of Microsoft Indigo in this article series. Indigo is an
integral part of Microsoft Longhorn, the next version of Windows. He will examine the basics of SOA,
the problems that Indigo solves - unified programming model and a step by step technical implementation
of Indigo web service with Microsoft .Net Framework 2.0. This is the first of three articles.
What is Service Oriented Architecture? We have seen many distributed architecture models over the years. Object Request Brokers (ORBs) in CORBA, RMI and DCOM are some of the dominant ones.
These architectures flourished within an enterprise utilizing object oriented programming concepts. These
architectures facilitate direct method invocations between tightly coupled objects. However we could only
perform these direct calls within an enterprise. It was very difficult to invoke methods on a distributed
object on a separate enterprise. (In most cases the source system and the target system resides on different
software platforms). Simply the source and the target objects could not communicate efficiently with each
other. This is due to the tight coupling of the objects to the specific platform. Here are some of the issues we faced: The modifications to the source object will break the interface with the target object. We have to modify both the source and the target objects together to prevent any issues. In most cases this may not be a viable practical scenario. (Example: In a Business to Business scenario where the source and target objects are in multiple platforms on different enterprises.) CORBA, RMI and DCOM all rely on platform specific object models and implementation of objects and proxies using the same programming language. Unfortunately this is an unrealistic expectation in the modern days of business mergers and joint ventures. It is very common to see multiple platforms 'working together' to add business value on a single enterprise.
Service Oriented Architecture (SOA) is an approach that tries to address these issues. Previously we modeled
our solutions using 'objects' as our building blocks according to Object Oriented (OO) concepts. These 'objects'
are capable of handling business functionality and communicated with 'fellow' objects directly. SOA defines a
'services' as a 'loosely coupled autonomous entity' that can easily communicate to other services. SOA comprises
of the following very important concepts. (Source: Microsoft) - Service - A service is a program that other programs can interact with using messages.
- Client - A client is a program that makes the service available to users to consume.
- Connected System - A collection of inter connected services and clients.
Please note that we do not use the words "web services" or "XML web service" in the definition
of SOA. The objective is to build 'connected systems' that can seamlessly communicate with each other.
These connected systems reside in their service domain and sends messages to loosely coupled objects on
target service domains. This definition also supports the 'Federated Services model'.
(The source and target service domains exists in different platforms and communicate with WS.* standards.) What about Enterprise Service Bus? Is it the same as SOA? Let us begin by clarifying the difference between
SOA and Enterprise Service Bus (ESB). ESB can be defined loosely as an
'EAI enable web services'.
ESB relies on a central module to 'manage' the interactions between systems.
(This is similar to an EAI manager / IBM Message Broker hub that controls
the MQ messages between the applications).
This is a fundamental difference in SOA. There is no 'managing' module in SOA. All the services are treated equally
and they need to be registered to be dynamically discovered. This notion also decouples SOA services from
technology. (Since they do not need to talk to a central authority, they do not have to understand the same
programming language. Therefore the SOA services can be written in multiple programming languages as long they
can be dynamically discovered) We expose 'services' to communicate with other programs in service oriented programming. These services use
open protocols (SOAP, HTTP, and WSDL) to transfer information. These open protocols add an integral level
of interoperability to our application. The developers and system integrators no longer needs to understand
the underlying native object models and type systems of each platform. The services can reside on multiple
platforms and expose their logic through these open protocols to achieve interoperability. The services can
also be 'dynamically discovered' to other programs using WSDL. The WSDL document represent the 'service contract'
that the service wishes to establish with its client. We can also define 'policy' documents to set the
rules to engage in this contract. All these factors make SOA 'loosely coupled' from its implementation
platform. Therefore we end up with a collection of connected systems that are more flexible to maintain,
more reliable and which evolves over time. This is a basic introduction to SOA. Here are some important
SOA links to expand your knowledge. There are several key SOA implementations currently. WebMethod's Fabric, SUN's JXTA and
Microsoft's Indigo are the front runners. Let's examine Microsoft Implementation of SOA - Indigo in detail now.
Evolution of ASMX to Indigo Firstly, a bit of history to explain the evolution of Indigo. Microsoft's first service orientated programming offering was the "XML Web Services". It was shipped with .NET Framework 1.0. They were also referred to as ASMX. (The web services files had the ASMX extension.) They were a great extension to MS tools to introduce SOA concepts. However robust version of ASMX did not appear till the next version of .NET framework (1.1). The framework guys did some excellent work to optimize the XML serialization code to optimize ASMX 'very close to' .NET Remoting. However the objective of ASMX was to add another 'XML layer' on top of the .Net assemblies. The necessities like Security, Routing, Licensing, Transactions and Addressing was missing from ASMX architecture. These were packaged as 'Web Services Enhancements (WSE)' later. These concepts were paramount to implement connected systems between multiple enterprises. Here are the key features of WSE offerings. (Source: MSDN): Web Services Enhancements (WSE) 1.0 Service Pack 1 provides support for security features such as digital signature
and encryption, message routing capabilities, and the ability to include message attachments that are not serialized
into XML. Functionality is based on the WS-Security, WS-Routing, WS-Attachments and DIME specifications. WSE 2.0 supports encryption using Kerberos tickets, X.509 certificates, username/password credentials, and
other custom binary and XML-based security tokens. WSE provides a foundation for building applications based
on Web services specifications published by Microsoft and industry partners including WS-Security (OASIS 2004 standard), WS-Policy,
WS-SecurityPolicy, WS-Trust, WS-SecureConversation and WS-Addressing.
The modern day web services tackle complex business issues. Therefore the web services standards and their infrastructure
support needs to evolve to facilitate these needs. The next step of MS service oriented programming approach is code
named - Indigo. (MS also released WSE 3.0 as a bridge from WSE 2.0 to indigo. This release is simply targeted at
WSE 2.0 consumers to make the code 'Indigo - ready' for Longhorn) All these software modules can be downloaded from MSDN Web Services Downloads.
What is Indigo? Indigo is the latest Microsoft implementation of service oriented architecture. Indigo provides a rich set of technologies for "creating, consuming, processing and transmitting messages". It offers a unified programming model (discussed later) and infrastructure for developing connected systems. Indigo is planed to be released with the long awaited next version of Windows, Longhorn. At the time of writing Longhorn is scheduled to be released in 2006. The goal of Indigo is to enable service oriented programming. Indigo delivers reliability, guaranteed delivery, secure communications and transactions that are interoperable to other connected systems. These features are achieved by implementing WS-* specifications. Indigo reduces the 'plumbing code' to achieve interoperability between heterogeneous systems. The end product will be businesses interacting with customers, suppliers and employees both internally and externally (regardless of their IT platforms) to create a web of 'connected systems'
What are the Problems that Indigo Solves? What does Indigo mean to a developer? What issues does in address? Let's dive into this topic now. Currently there are several distributed application technologies offered by Microsoft. We will use ASMX technology to build simple interoperable web service. We will use .NET Remtoting to exchange information between two .Net based applications. We have to use Enterprise Services to implement distributed transactions on a Microsoft enterprise. (Enterprise Services is the .Net implementation of COM+). We need to use MSMQ to implement queue management. The advance web services features (security, routing, addressing) are achieved by implementing WSE 1.0 or WSE 2.0. The best feature of Indigo is the 'unification' of all these technologies under one code base. This is commonly referred to as a "Unified Programming Model". Therefore a developer can utilize Indigo to implement web services, queuing, transactions and advance web services features through one technology. This is the greatest benefit of Indigo from my perspective. The following image (Figure 1) illustrates the unified programming model in Indigo. Figure 1: Unified Programming Model in Indigo
 The figure illustrates the unification of ASMX, .NET Remoting, WSE, Enterprise Services and MSMQ to indigo. It will consume all the requests and enable developers to produce information using built in formatters (SOAP, HTTP) and channels (Bindings such as WSProfile etc). This model will eradicate the confusion when it comes to choices of MS technology. It also makes the maintenance of code much simpler. (Example: We do not need to make changes to ASMX and MSMQ components to implement a new message interface) I believe Microsoft will still support the older technologies. However, the new developments are encouraged to follow indigo to reap the benefits of unified programming model. Indigo is based on service oriented concepts. The WS-* standard by OASIS are implemented in Indigo to have seamless integration to J2EE, Solaris, IBM and Linux systems. I believe this is the closet Microsoft has gone to implement true web of 'connected systems' - a federated network of services that resides on heterogeneous platforms. Now let's look at the 'nuts and bolts' of Indigo programming:
Indigo Programming Model There are several concepts we need to understand before we build a Indigo web services. They are Service Contract: This is a collection of messages that are organized to implement a Message Exchange Patterns (MEPs) such as one-way or request/reply. The service contract defines the "structure" of the web service to the external entities. Data Contracts: The data contracts define the data infrastructure of the Indigo web service. Endpoint: This is the 'gateway' to the external entities from the Indigo web service. An endpoint will consist of an address (this will usually be a port number), a contract and a binding. Binding: The binding specifies the communication attributes of the endpoint to the external entities. The binding explains that the web service will use specific protocol (TCP, HTTP) with a specific encoding (binary or text) and the security requirements (SOAP security or SSL) to interact with the web service.
These items are illustrated in the following figure 2. Figure 2: Indigo building blocks
 The service contracts define the structure of the web services. The data contract defines the data structures of the web service. Indigo has built in 'bindings' that we can utilize to transport messages. Indigo web service can have multiple data contracts. It can also have multiple bindings. (We have got a BasicProfileBinding and a WSProfile binding for this web service. We can change the binding by using a configuration file or modifying the code explicitly. (These topics are discussed later). The web service messages get exposed via an end point to the users. These users are usually behind firewalls. The endpoint exposes the web service logic over the bindings to the user. We can define an endpoint as a 'gateway' to the user to access the web service logic. We can also have multiple endpoints for a single binding. (Example: - You may want to use the same WSProfileBinding to get information on an E-Commerce shopping site. The 'standard users' can use 'End Point2' that comes through port 8001. - Please refer to Figure 2. The 'Platinum card' users can use 'End Point3' through port 8002.) The SOAP message headers are used to define the endpoints when multiple end points are present.
Building a Sample Indigo Web Service We are going to build a small application to illustrate Indigo web services. This web service will mimic a stock quote from the capital markets. We will invoke an Indigo web service call with the appropriate stock code. The web service will return the stock price. My objective is to explain the new Indigo concepts. Therefore the code will be 'bit lean' when it comes to business logic. We will use this scenario through the next set of articles also. The complete example will consists of three sections, - Creating the web service (In the next section)
- Hosting the web service (In the 2nd article of this series)
- Creating clients to consume the web service (In the 3rd article of this series)
Figure 3 illustrates the scope for the first article. There are four basic tasks we need to implement to get an Indigo web service running. They are in order, - Define the service contract and data contract using an interface.
- Implement the contracts
- Create a single or multiple end points.
- Host the service. (On IIS or using a self-hosted application.)
Figure 3: Application architecture and the scope of the first article.
 We will build a 'StockQuote' web service with a data contract. We will expose the web service through two sets of bindings. These bindings will assist us to host the web service on IIS or as a 'self hosted' application. We will also build two clients that will consume the web service through different endpoints. (We will build an IIS hosted client and a self hosted application using .NET framework 2.0). The clients will utilize the 'automated proxies' generated by Indigo. The scope of the first article is explained by the 'grey area' of Figure 3. We will examine service contracts, data contracts, bindings and endpoints in article one. Here is the development environment we are using:
Development Environment for the Sample Web Service - Windows XP with Services Pack 2
- Indigo and Avalon Beta 1 Release Candidate (I used the Indigo and Avalon March CTP version. Unfortunately this only for MSDN subscribers. I have tested the code with public beta RC1 and it works like a charm. The RC1 will also install the correct .Net Framework 2.0 version)
Now let's get our hands dirty with some code. Let's get started!
Step 1 - Define Service Contract There are two ways you can cerate a service contract. They are to create an interface and apply the ServiceContractAttribute or to create a class and apply the ServiceContractAttribute to it. We will choose the interface approach. (The class approach is used in instances where we need to expose existing classes as Indigo services). Here are the steps: Open your favorite text editor. (I will use Notepad. I have not intentionally use VS 2005 beta 2 or C# express to create this web service. Indigo is an integral part of .NET framework 2.0 and can be used with out any IDE tools. I believe the final version of VS 2005 will accompany rich set of tools to create and manipulate Indigo web services.) We will first enter standard compiler directives and gain access to Indigo namespaces: <%@Service class="StockQuoteService" Debug="true" language="cs"%>
using System;
using System.ServiceModel;
using System.Runtime.Serialization;
Let's create an interface called IStockQuote and apply the ServiceContractAttribute to the interface. This attribute identifies that the class as a 'service contract' to the external entities. The code should look similar to this. [ServiceContract()]
public interface IStockQuote
{
}
Indigo uses XmlFormatter by default to serialize parameters and return values. Unfortunately the XmlFormatter only handles a subset of XSD types. It is good practice to use the XmlSerializer explicitly. Therefore our code should like, [ServiceContract (FormatMode = ContractFormatMode.XmlSerializer)]
public interface IStockQuote
{
}
Let's create the interface methods now and apply the OperationContractAttribute to the methods. This attribute is similar to the "WebMethod" attribute in Framework 1.0
and 1.1. This attribute will control the access to the methods by the external entities.
(i.e. If a method is not defined as OperationContractAttribute,
then it is not exposed to external entities by the web service). Here is the code: [ServiceContract (FormatMode = ContractFormatMode.XmlSerializer)]
public interface IStockQuote
{
[OperationContract]
int GetCurrentPrice(string stockCode);
[OperationContract]
string GetCompanyName(string stockCode);
int GetCompanyLastClosingPrice(string stockCode);
}
The GetCurrentPrice and GetCompanyName methods are exposed in the web service. However, GetCompanyLastClosingPrice method is not available for consumption by the web services clients. The OperationContractAttribute can also define the 'direction' of the message flow. This option is very valuable for optimization purposes.
If the client is expecting a response form the web service we can extend this property to have "IsOneWay=false" syntax (Synchronous model). However, the client needs to wait for an empty response from the web service
to continue to the next task. If the client chooses to 'fire the request and forget' then use the "IsOneWay=true".
(Asynchronous model) The client does not need to wait for any response form the web service under this
design implementation. We will add a method called SetCompanyName to illustrate this. [OperationContract (IsOneWay=true)]
void SetCompanyName(string companyName);
Please note that GetCurrentPrice and GetCompanyName methods do not have IsOneWay=false explicitly defined. However the default communication mechanism in Indigo is bidirectional.
Therefore, both those methods will have the default settings of IsOneWay=false. We can also have 'duplex messaging' between the service and clients using call backs mechanisms in Indigo. We will not be implementing duplex communication in the scope of this article. Let's look at the process to define data contracts.
Step 2 - Define Data Contracts Data contracts are optional. We do not need to use data contracts to expose basic type information.
The data contract defines the 'structure' of the data that the web service exposes.
We will create a class called StockInfo to manipulate company information. We will store the company name, address and the stock price in this data
structure. The class needs to have the [DataContract] directive at the top. We will have a property called CompanyName and two private variables for price and address.
The class will look similar to this, [DataContract]
public class StockInfo
{
private string companyName;
[DataMember]
public string CompanyName
{
get {return companyName; }
set {companyName = value; }
}
[DataMember]
private string price;
private string address;
}
Here are some interesting comments about this data structure. - The private
companyName data element will not be serialized. (Because it not marked with the [DataMember] element. Only the [DataMember] elements get serialized at the runtime.) - The
CompanyName property will get serialized. - The
'price' private variable will be serialized at runtime. (Regardless of being defined as private) - The
'address' private variable will not be serialized at runtime. (Because it is not defined as [DataMember])
We will also add another method - GetCompanyDetails to our IStockQuote interface to use this data structure in the web service call. (This modification is to highlight the data contract serialization in Indigo web services and clients) [OperationContract]
StockInfo GetCompanyDetails();
We have now defined the 'foundation' for our Indigo service. Your code listing should be similar to the following, <%@Service class="StockQuoteService" Debug="true" language="cs"%>
using System;
using System.ServiceModel;
using System.Runtime.Serialization;
[ServiceContract (FormatMode = ContractFormatMode.XmlSerializer)]
public interface IStockQuote
{
[OperationContract]
int GetCurrentPrice(string stockCode);
[OperationContract]
string GetCompanyName(string stockCode);
int GetCompanyLastClosingPrice(string stockCode);
[OperationContract (IsOneWay=true)]
void SetCompanyName(string companyName);
[OperationContract]
StockInfo GetCompanyDetails();
}
[DataContract]
public class StockInfo
{
private string companyName;
[DataMember]
public string CompanyName
{
get {return companyName; }
set {companyName = value; }
}
[DataMember]
private string price;
private string address;
}
Now the interfaces are ready to be implemented.
Implement the Service and Data Contracts We will create a StockQuoteService class to implement our IStockQuote interface. Please note that I have not spent much effort on the business logic of the functions.
My main objective is to expose the new Indigo concepts and syntax. Here is the implementation.
(All the code is self-explanatory) public class StockQuoteService : IStockQuote
{
private StockInfo stock;
public int GetCurrentPrice(string stockCode)
{
return 10; // remember price is not a [DataMember].
}
public string GetCompanyName(string stockCode)
{
return stock.CompanyName;
}
public int GetCompanyLastClosingPrice(string stockCode)
{
// This code will not be called by the web service consumers
// Becuase [OperationContract] is not defined in the interface.
return 0;
}
public void SetCompanyName(string companyName)
{
stock.CompanyName = companyName;
}
public StockInfo GetCompanyDetails()
{
return stock;
}
}
We have done the code for the web service now. Let's learn how to 'expose' the web service to
the external entities using end points.
Step 3 - Create End Points An end point acts as a 'gateway' to the outside world. Simply, an endpoint defines where we can find the web
service. The end points can be implicitly coded in the application or driven by configuration files.
I have found the configuration option more efficient in this case. It is a bad software engineering
concept to modify code each time we migrate from one environment to another. We also need to recompile
the code each time we change the end point information. Therefore, I prefer the configuration file approach. The Indigo endpoints are implemented using the WS-Addressing standard. They are Uniform Resource Identifier
(URI) that specifies the location of a web service. Let's create the web.config file that has the end points for our Stock Quote web service. The configuration file looks similar to the following: <?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.serviceModel>
<services>
<service behaviorConfiguration="helpPageBehavior" serviceType="StockQuoteService" >
<endpoint address="/" bindingSectionName="wsProfileBinding" contractType="IStockQuote"/>
</service>
</services>
<behaviors>
<behavior configurationName="helpPageBehavior">
<metadataPublishing enableGetWsdl="True" enableMetadataExchange="False" enableHelpPage="True"/>
</behavior>
</behaviors>
</system.serviceModel>
</configuration>
Let's investigate the 'behind the scenes' of Indigo code execution. The Indigo runtime looks at the serviceType element when it is invoked. This element identifies the class to be instantiated. Our sample web
service implements a behavior pattern called "helpPageBehavior".
This is defined later in the configuration file. Let's have a look at this line. <endpoint address="/" bindingSectionName="wsProfileBinding" contractType="IStockQuote"/>
This line specifies the 'binding' to the endpoint. This concept of 'bindings' are very important in Indigo.
The bindings explain 'how to communicate" to the web service. (Remember 'where' the web service is
defined by end point). The Binding explains transport protocol stack (TCP, HTTP etc), encoding of the
message (Text, Binary etc) and the protocol stack (Do we need security? reliable messaging? etc). We
are using the "wsProfileBinding" for our stock quote web services. There are several options we can use as bindings. Here are some of
the important ones: BasicProfileBinding - The web service is exposed as the standard Basic Profile (SOAP 1.1, WSDL 1.1, UDDI 2.0) web service. This is similar to the traditional ASMX pages. The transport can be either HTTP or HTTPS. The encoding is text. WsProfileBinding - This binding implements "cross machine reliable messaging". It can use either transport protocols or WS-Security features for secure messaging. The encoding is text or MTOM. NetProfileTcpBinding - This is an optimized TCP binding for cross machine communication. This binding uses WS-Security for secure messaging and uses binary for encoding. NetProfileMsmqBinding - This binding is optimized to handle MSMQ / queue messages. This is cross machine binding with binary encoding.
Now we have coded our web service and configured the endpoints and bindings. The next step is to host the web service. This topic will be discussed in the next article.
Code Download the code and investigate the concepts. You will not be able to run the web service till you host it. (It can be hosted on IIS or as a self hosted application). These steps will be discussed in the next article.)
You can download the code here.
Reference
About the Author Chris Peiris (.NET MVP 2003, MIT, BComp, BBus) currently works for Avanade as a Principal Development Consultant. Chris has co-authored many books on Web Services, UDDI, C#, IIS, Java and Security topics. He has written many articles, reviews and columns for various online publications. He is also a frequent speaker at professional developer conference on Microsoft technologies. Chris's current passions include Indigo, WinFX, IBM Message Broker and EAI. He lives with his family in Conder, ACT, in Australia. He can be reached at www.chrispeiris.com.
| 
