What is Microsoft Dynamics?

Microsoft Dynamics is a line of easy-to-use business management solutions that enable your people to make important business decisions with greater confidence. These solutions automate and streamline financial, customer relationship, and supply chain processes in a way that helps you drive business success.

 

 

Learn more about Microsoft Dynamics

 

Financial Management

Customer Relationship Management

Supply Chain Management

 

Financial Management. Mastered.

Microsoft Dynamics gives you everything you need to make financial decisions with confidence. Like real-time access to the numbers you need and powerful tools that help you analyze the data from any angle. Plus, it helps streamline tasks, speed month-end closings, and make sure your numbers are rock-solid.

 

More...

 

Customer Relationship Management. Mastered.

Microsoft Dynamics connects your team to insights and data that will help them add value to every relationship. They can find records quickly, track preferences accurately, answer questions thoroughly, and resolve issues instantly. All of which keeps current customers happy. And brings new customers on board.

 

More..

 

Supply Chain Management. Mastered.

Microsoft Dynamics gives your people the tools they need to master every link in your supply chain. It delivers real-time information that helps them maintain optimal inventory levels, streamline order processing, automate production planning, expedite shipping, and manage your expansion into new markets.

 

More..

 

 

Courtesy : Microsoft MSDN (http://msdn.microsoft.com/biztalk/learning/dev/orch/)

Coexistence and Migration

Indigo represents a modern approach to creating distributed applications in the era of reliable, secure, and transactional services. A key point to understand, however, is that installing Indigo will not break any existing applications. Current code running on ASMX, .NET Remoting, and the other technologies whose functionality is subsumed by Indigo will continue to run, and so there's no requirement to move to Indigo. But for organizations with investments in current Microsoft technologies, an obvious question remains: what happens to existing code written using the technologies that preceded Indigo?

For each of the current technologies whose future is deeply affected by the advent of Indigo, developers need to understand two things: whether applications built on this technology will interoperate with applications built on Indigo, and how much work it will be to port applications from this technology to the Indigo environment. Here's a short description of how each technology addresses these issues:

• ASP.NET Web services (ASMX): Web services built with ASMX will interoperate with Indigo applications. Since ASP.NET Web services and Indigo both support standard SOAP, this shouldn't be surprising. Moving existing ASP.NET Web services code to Indigo will require some mechanical work, but should still be straightforward. The basic structure of the two technologies is quite similar, so for the most part only attributes and configuration files will need to be changed. More advanced features, however, such as SOAP Extensions, will not be directly portable to Indigo. Instead, they'll need to be re-written using the extensibility options that Indigo provides.
• .NET Remoting: applications built on .NET Remoting will not interoperate with applications built on Indigo—their wire protocols aren't compatible. Moving existing .NET Remoting code to Indigo will require some effort, but it will be possible. Anyone who's built custom .NET Remoting extensions, however, such as channels and sinks, will find that this code won't port to the new world. Similar extensions are possible in Indigo, but the interfaces for doing it don't match those in .NET Remoting.
• Enterprise Services: to allow an existing Enterprise Services application to interoperate with Indigo clients (or other web services-based software), a developer can identify exactly which interfaces in that application should be exposed. Using an Indigo-supplied tool, service contracts can then be automatically created for those interfaces and exposed via Indigo. For existing clients of Enterprise Services applications that aren't built on the .NET Framework (and for other purely COM-based clients), an Indigo moniker is provided to allow straightforward access to web services. The effort required to port existing Enterprise Services applications to run directly on Indigo will be similar to what's required to port ASMX applications. Much of the work, although not all of it, will be straightforward mechanical changes to attributes and namespaces.
• Web services Enhancements (WSE): WSE is Microsoft's tactical solution for implementing Web services applications that require some or all of the functions provided by the WS-* specs. Applications built using WSE 1.0 and WSE 2.0 won't interoperate with applications built on Indigo. Applications built on WSE 3.0, which will be shipped before Indigo is released, will interoperate with Indigo applications, however. For portability, the story is similar to the technologies already described: some amount of effort will be required to move existing code from WSE to Indigo, although this effort will be minimized for applications that use the final WSE version.
• MSMQ: because Indigo's queuing functions are built on MSMQ, queued applications built on Indigo can interoperate with queued applications built directly on MSMQ. Porting applications from the System.Messaging namespace provided with the original .NET Framework will require some work, since this earlier interface is different from what Indigo provides. Once Indigo ships, developers should use it rather than System.Messaging to create most MSMQ-based queuing applications.

Before Indigo is available, the best technology choice for distributed .NET applications that don't need queuing is probably ASMX. It's simple to use, and it also provides the smoothest migration path to Indigo. Enterprise Services can also make sense for applications that need the things it provides, such as distributed transactions, while MSMQ remains the right choice for queued applications. .NET Remoting, however, should be used primarily for communication between two application domains in the same process. ASMX is a better choice for direct application-to-application communication in most other cases.

Introducing new software always has an impact on what already exists. By providing a common foundation for building service-oriented applications, Indigo offers a simpler, more consistent platform for developers. While this change incurs some pain, the goal of Indigo's creators is to make the transition as smooth and as simple as possible.

Conclusions

Indigo represents an important evolution in how developers create software. As service-oriented applications become the norm, Indigo will be a mainstream technology for Windows software developers. Other Microsoft products will also change to take advantage of what Indigo offers. BizTalk Server, for example, will add support for Indigo as a communication option sometime following the release of BizTalk Server 2006. Because Indigo provides a standard foundation for service-oriented software, it will be the basis for a large fraction of Windows communication.

The impact of this technology will not be small. Anyone who builds distributed applications on Windows, especially applications that must interoperate with those on other platforms, should pay close attention. Indigo will significantly change their world.

 

About the Author

David Chappell is Principal of Chappell & Associates (www.davidchappell.com) in San Francisco, California. This article is drawn from his forthcoming book on Indigo, to be published by Addison-Wesley.

 

Other Aspects of Indigo

The basics of services and clients are fundamental to every Indigo application. Yet most of those applications will also use other aspects of this technology. This section takes a look at some of the additional features that Indigo provides for applications built on it.

Controlling Local Behavior

Many aspects of Indigo, such as contracts, bindings, and more, are related to communication between a service and its clients. Yet there are also parts of a service's behavior that are essentially local. How is a service instance's lifetime controlled, for example, and how is concurrent access to that instance managed? To allow developers to control behaviors like these, Indigo defines two primary attributes, both of which have a number of properties. One of these attributes, ServiceBehavior, can be applied to classes that are also marked with the ServiceContract attribute. The other, OperationBehavior, can be applied to methods in a service class that are also marked with the OperationContract attribute.

The ServiceBehavior attribute has various properties that affect the behavior of the service as a whole. For example, a property called ConcurrencyMode can be used to control concurrent access to the service. If set to Single, Indigo will deliver only one client request at a time to this service, i.e., the service will be single-threaded. If this property is set to Multiple, Indigo will deliver more than one client request at a time to the service, each running on a different thread. Similarly, ServiceBehavior's InstanceMode property can be used to control how instances of a service are created and destroyed. If InstanceMode is set to PerCall, a new instance of the service will be created to handle each client request, then destroyed when the request is completed. If it's set to PrivateSession, however, the same instance of the service will be used to handle all requests from a particular client.

Suppose, for example, that its creator decided that the Calculator class should be multi-threaded and use the same instance for each call from a particular client. The class's definition would then look like this:

using System.ServiceModel;

 

[ServiceContract]

[ServiceBehavior(

  ConcurrencyMode=Multiple,

  InstanceMode=PrivateSession)]

class Calculator { ... }

Similarly, properties on the OperationBehavior attribute allow controlling the impersonation behavior of the method that implements this operation, its transactional requirements (described later), and other things.

Messaging Options

The simple examples shown in this article assume a synchronous remote procedure call (RPC) approach to client/service interaction. Indigo supports this option, but it's not the only choice. SOAP is a message-oriented protocol, which means that it can support a variety of programming models. In fact, Indigo supports several possibilities, including the following:

• Traditional RPC, with blocking calls carrying lists of typed parameters;
• Asynchronous RPC, with non-blocking calls carrying lists of typed parameters;
• Traditional messaging, with non-blocking calls carrying a single message parameter;
• Message-based RPC, with blocking calls carrying a single message parameter.

And even though the great majority of distributed applications require it, the SOAP specification says nothing about reliability. One common way to ensure reliability is to use SOAP only in point-to-point scenarios, relying on TCP to guarantee delivery of requests and responses. This is sufficient in some cases, and it's what's done when the BasicProfileHttpBinding is used.

Yet there are plenty of cases for which this isn't enough. What if a service is accessed through multiple SOAP intermediaries, for example? The reliability guarantees provided by TCP aren't enough in this case to ensure end-to-end reliability. To address this problem, Indigo implements the WS-ReliableMessaging specification. By choosing a binding such as WsHttpBinding, which uses WS-ReliableMessaging, a service and its client can guarantee reliable end-to-end communication even through multiple SOAP intermediaries.

Security

Exposing services on a network, even an internal network, usually requires some kind of security. How can the service be certain of its client's identity? How can messages sent to and from a service be kept safe from malicious changes and prying eyes? And how can access to a service be limited to only those authorized to use it? Without some solution to these problems, it's too dangerous to expose many kinds of services. Yet building secure applications can get complicated. Ideally, there should be straightforward ways to address common security scenarios, along with more fine-grained control for applications that need it.

To achieve this, Indigo provides the core security functions of authentication, message integrity, message confidentiality, and authorization. Indigo's approach to the first three of these relies primarily on bindings, and a developer's choices include the following:

• Choose a standard binding that supports security. Applications that need only transport-based security, for example, can use a binding such as BasicProfileHttpsBinding. This approach is sufficient for requests that go directly from a client to a service without traversing any intermediaries, such as HTTP proxies or other SOAP nodes. Applications that require end-to-end security for messages that go through multiple SOAP intermediaries can instead use a binding that supports WS-Security, such as WsHttpBinding.
• Choose a standard binding that supports security, then customize it by changing one or more of its default values. For example, the authentication mechanism used by a binding such as WsHttpBinding can be changed if desired.
• Create a custom binding that provides exactly the security features a developer needs. Doing this isn't for the faint of heart, but it can be the right solution for some advanced scenarios.
• Choose a standard binding that provides no support for security, such as BasicProfileHttpBinding. While using no security is generally a risky thing to do, it can still be the best option in some situations.

An Indigo service can also control which clients are authorized to use its services. For the most part, Indigo just supports existing authorization mechanisms in the .NET Framework. A service can use the standard PrincipalPermission attribute, for example, to define who is allowed to access it.

Letting developers build secure applications without exposing them to overwhelming complexity has proven to be challenging in the past. By providing both a straightforward approach for the most common cases and fine-grained control for more complex situations, Indigo aims at hitting this target in a usable and effective way.

Transactions

Handling transactions is an important aspect of building many kinds of business logic. Yet using transactions in a service-oriented world can be problematic. Distributed transactions assume a high level of trust among the participants, and so it often isn't appropriate for a transaction to span a service boundary. Still, there are situations where combining transactions and services makes good sense, and so Indigo includes support for this important aspect of application design.

Transactions in the .NET Framework 2.0

The transaction support in Indigo builds on enhancements provided in version 2.0 of the .NET Framework. This forthcoming release includes System.Transactions, a new namespace focused solely on controlling transactional behaviors. Developers will most often use the services of System.Transactions in concert with an execution context, a construct that's new in version 2.0 of the .NET Framework. An execution context allows specifying common information, such as a transaction, that applies to all code contained within a defined scope. Here's an example of how an application can use this approach to group a set of operations into a single transaction:

using System.Transactions;

 

using (TransactionScope ts = new TransactionScope(TransactionScopeOption.Required)) {

   // Do work, e.g., update different DBMSs

   ts.Complete();

}

All of the operations within the using block will become part of a single transaction, since they share the transactional execution context it defines. The last line in this example, calling the TransactionScope's Complete method, will result in a request to commit the transaction when the block is exited. This approach also provides built-in error handling, aborting the transaction if an exception is raised.

Specifying Required for the new TransactionScope, as this example does, means that this code will always run as part of a transaction: joining its caller's transaction if one exists, creating a new one if it doesn't. As in Enterprise Services, other options can also be specified, including RequiresNew, Supported, and NotSupported.

Unlike Enterprise Services and its predecessors MTS and COM+, Systems.Transactions is focused entirely on controlling transactional behavior. There's no required connection between a transaction and the internal state of an object, for example. While Enterprise Services requires an object to be deactivated when it ends a transaction, Systems.Transactions makes no such demand. Since Indigo builds on Systems.Transaction, Indigo applications are also free to manage transactions and object state independently.

Transactions in Indigo

Indigo applications can use System.Transactions explicitly, or they can control transactions using attributes that rely on System.Transactions under the covers. One option is for a method inside a class marked with the ServiceContract attribute to wrap its work in a transaction using TransactionScope, as just described. For example, this method might include a using statement that establishes a transaction scope, then update two independent databases within that transaction.

A service's methods can also control transactional behavior using an attribute. Rather than explicitly using System.Transactions, a service can use the OperationBehavior attribute described earlier. Here's an example:

using System.ServiceModel;

 

[ServiceContract]

class XactOperations

{

 [OperationContract]

    public int Add(int value1, int value2)

    {

       return value1 + value2;

    }

 

 [OperationContract]

 [OperationBehavior(RequireTransaction=true,

                    AutoCompleteTransaction=true)]

 int Update(int value1, int value2)

 {

       // Insert value1 and value2 into

    // two different databases

 }

}

The first method in this example, Add, doesn't use a transaction, and so its simple operation will happen just as before. But the second method, Update, is preceded by the OperationBehavior attribute with the RequireTransaction property set to true. Because of this, all work done within this method will happen inside a transaction, just as if it were inside the transaction scope of the using block shown earlier. And because the AutoCompleteTransaction property is also specified, the transaction will automatically vote to commit if no exception is raised.

If the client invoking this method is not running inside a transaction, the Update method will run in its own transaction—there's no other choice. But suppose the client is already part of an existing transaction when it calls Update. Will the work done by the Update method join the client's transaction, or will it still run inside its own independent transaction? The answer depends on whether this service can accept a transaction context passed by the client, an option controlled using the TransactionFlowAllowed property of the OperationContract attribute. If TransactionFlowAllowed is not attached to a method in the service, as in the example shown above, work done within this method can never join an existing transaction. If this attribute is present, however, a method is able to join the transaction of its client.

It's also worth emphasizing that applications built on Indigo can participate in transactions that include applications running on non-Indigo platforms. For example, an Indigo application might start a transaction, update a record in a local SQL Server database, then invoke a web service implemented on a J2EE application server that updates a record in another database. If this service is transactional and the platform it's running on supports the WS-AtomicTransaction specification, both database updates can be part of the same transaction. Like security and reliable messaging, Indigo transactions work in the heterogeneous world that Web services make possible.

Queuing

Using a binding such as WsHttpBinding, an Indigo application can communicate reliably with another application built on Indigo or any other Web services platform that implements WS-ReliableMessaging. But while the technology this specification defines guarantees reliable end-to-end delivery of a SOAP message, it doesn't address message queuing. With queuing, an application sends a message to a queue rather than directly to another application. When the receiving application is ready, it can read the message from the queue and process it. Allowing this kind of interaction is useful, for example, when the sender of a message and its receiver might not be running at the same time.

Accordingly, Indigo provides support for message queuing. This support is built on top of MSMQ, which means that unlike most other aspects of Indigo, such as reliable messaging, security, and transactions, Indigo queuing doesn't interoperate directly across vendor boundaries (although an MSMQ-MQSeries bridge is available).

To use Indigo queuing, a developer creates a standard Indigo service class, marked as usual with ServiceContract. The operations in this class's service contract have some limitations, however. In particular, they must all be marked as one-way, which means that no response is returned. This isn't surprising, since invoking a queued operation sends a message into a queue rather than to its ultimate receiver, and so waiting for an immediate response wouldn't make much sense. And like any other service class, queued Indigo applications expose endpoints. These endpoints use bindings such as NetMsmqBinding, which allows communication with other queued Indigo applications, or MsmqIntegrationBinding, which allows a queued Indigo application to interoperate with a standard MSMQ application that doesn't use Indigo. Indigo queuing also supports other traditional features of queued environments, such as dead letter queues and handling of poison messages.

Queuing is the right approach for a significant set of distributed applications. Indigo's support for this communication style allows developers to build queued applications without learning an entirely separate queuing technology.

Defining Data Contracts

An Indigo service class specifies a service contract that defines which of its methods are exposed to service clients. Each of those operations will typically convey some data, which means that a service contract also implies some kind of data contract describing the information that will be exchanged. In some cases, this data contract is defined implicitly as part of the service contract. For example, in the Calculator classes shown above, each method takes two input parameters, both integers, and returns a single integer. These parameters define all of the data exchanged by this service, and so they comprise the service's data contract. For services like this one, where every operation uses only simple types, it makes sense to define the data aspects of its contract implicitly within the service contract. There's no need for anything else.

But services can also have parameters of more complex types, such as structures. In cases like this, an explicit data contract is required. Data contracts define how in-memory types are converted to a form suitable for transmission across the wire, a process known as serialization. In effect, data contracts are a mechanism for controlling how data is serialized.

In an Indigo service class, a data contract is defined using the DataContract attribute. A class, structure, or other type marked with DataContract can have one or more of its members preceded by the DataMember attribute, indicating that this member should be included in a serialized value of this type. Here's a simple example:

[DataContract]

struct Customer {

 [DataMember] public string Name;

 int public age;

 [DataMember] private int CreditRating;

}                                                                   

When an instance of this Customer type is passed as a parameter in a method marked with OperationContract, only the fields marked with the DataMember attribute—Name and CreditRating—will be passed.

Whether a field is labeled as public or private has no effect on whether that field is serialized. Just as with methods, the public and private keywords are part of the contract defining how this type can be accessed by other objects in the same application. DataMember, like OperationContract, defines how the type can be accessed by clients of the service this class implements. Once again, the two are completely distinct.

One final point worth emphasizing about Indigo contracts is that nothing becomes part of either a service contract or a data contract by default. Instead, a developer must explicitly use the ServiceContract and DataContract attributes to indicate which types have Indigo-defined contracts, then explicitly specify which parts of those types are exposed to clients of this service using the OperationContract and DataMember attributes. One of the tenets of its designers was that services should have explicit boundaries, and so Indigo is an opt-in technology. Everything a service makes available to its clients is expressly specified in the code.

Contracts and the attributes that define them are a major aspect of Indigo, and this short description covers only the highlights. The OperationContract attribute can be used to define one-way operations, for example, where a call to a service has no reply. It's also possible to define interactions where both sides can act as client and service, each invoking operations and exposing operations that the other invokes, by creating what are called duplex contracts. The DataContract attribute has several more options as well, and it's even possible to work directly with SOAP messages natively using an attribute called MessageContract. Contracts are used to express much of what Indigo provides, and so they're one of its most fundamental concepts.

Selecting a Host

A class implementing an Indigo service is typically compiled into a library. By definition, all libraries need a host application domain and Windows process to run in. Indigo provides two options for hosting libraries that implement services. One is to use a host app domain and process provided by the Windows Activation Service (WAS), while the other allows a service to be hosted in any app domain running in an arbitrary process. This section describes both, beginning with WAS.

Hosting a Service Using the Windows Activation Service

The simplest way to host an Indigo service is to rely on WAS. (Note that WAS isn't supported in Indigo's first Community Technology Preview. Instead, Indigo services can be hosted in Internet Information Server on Windows Server 2003 and Windows XP, although only SOAP over HTTP is supported in this configuration.) Using WAS is much like using the hosting mechanism provided by IIS for ASMX. Among other things, both rely on the notion of a virtual directory, which is just a shorter alias for an actual directory path in the Windows file system.

To see how WAS hosting works, suppose either of the Calculator classes shown earlier was compiled into a library called calc.dll, then placed in the virtual directory calculator on a system running Windows Server 2003. To indicate that the Indigo service implemented in calc.dll should be hosted by WAS, a developer creates a file in the calculator virtual directory with the extension .svc (which stands, of course, for "service"). For our simple example, this file might be called calc.svc, and its entire contents could be:

%@Service language=c# class="Calculator" %

Once this has been done and an endpoint has been defined as shown in the next section, a request from a client to one of the Calculator service's methods will automatically create an instance of this class to execute the specified operation. That instance will run in an application domain created within the standard process that WAS provides.

Hosting a Service in an Arbitrary Process

Relying on WAS to provide a process for hosting an Indigo service is certainly the simplest choice. Yet applications often need to expose services from their own process rather than relying on one provided by Windows. Fortunately, this isn't hard to do. The following example shows how to create a process that hosts either of the Calculator classes defined earlier:

using System.ServiceModel;

 

public class CalculatorHost

{

  public static void Main()

  {

    ServiceHost<Calculator> s1 =

      new ServiceHost<Calculator>();

    s1.Open();

    Console.Writeline("Press ENTER to end service");

    Console.Readline();   

  }

}

Since the class CalculatorHost includes a Main method, it will run as a distinct process. To host the example Calculator service, this method must create a new instance of the class ServiceHost<T>, passing in the Calculator class. (Note that this standard Indigo class is a generic, indicated by the < and > that enclose its parameter. Generics are a new language feature in version 2.0 of C#, Visual Basic .NET, and other languages based on version 2.0 of the .NET Framework.) Once an instance of this class is created, the only thing required to make the service available is to call the Open method on that instance. Indigo will now automatically direct requests from clients to the appropriate methods in the Calculator class.

To allow an Indigo service to process requests from its clients, the process that hosts it must remain running. This isn't an issue with WAS-hosted services, since the standard process WAS provides ensures this. A hosting application must solve this problem on its own, however. In this simple example, the process is kept running through the straightforward mechanism of waiting for input from a console user.

Defining Endpoints

Along with defining operations in an Indigo service class and specifying a host process to run those operations, an Indigo service must also expose one or more endpoints. Every endpoint specifies the following three things:

• A contract name indicating which service contract this Indigo service class exposes via this endpoint. A class marked with ServiceContract that implements no explicit interfaces, such as Calculator in the first example shown earlier, can expose only one service contract. In this case, all of its endpoints will expose the same contract. If a class explicitly implements two or more interfaces marked with ServiceContract, however, different endpoints can expose different contracts.
• An address indicating where this endpoint can be found. Addresses are URLs that identify a machine and a particular endpoint on that machine.
• A binding determining how this endpoint can be accessed. The binding determines what protocol combination can be used to access this endpoint along with other things, such as whether the communication is reliable and what security mechanisms can be used. Suppose, for instance, that a service's creator wishes to allow clients to access that service using either SOAP over HTTP or SOAP over TCP. Each of these is a distinct binding, and so the service would need to expose two endpoints, one with a SOAP-over-HTTP binding and the other with a SOAP-over-TCP binding.

Bindings are a critical part of how communication is accomplished. To make them easier to use, Indigo includes a set of predefined bindings, each of which specifies a particular group of options. This set includes:

• BasicProfileHttpBinding: conforms to the Web services Interoperability Organization (WS-I) Basic Profile 1.0, which specifies SOAP over HTTP. This is an endpoint's default binding if none is explicitly specified.
• BasicProfileHttpsBinding: conforms to the WS-I Basic Security Profile 1.0, which specifies SOAP over HTTPS.
• WsHttpBinding: supports reliable message transfer with WS-ReliableMessaging, security with WS-Security, and transactions with WS-AtomicTransaction. This binding allows interoperability with other Web services implementations that also support these specifications.
• WsDualHttpBinding: like WsHttpBinding, but also supports interaction using duplex contracts. Using this binding, both services and clients can receive and send messages.
• NetTcpBinding: sends binary-encoded SOAP, including support for reliable message transfer, security, and transactions, directly over TCP. This binding can only be used for Indigo-to-Indigo communication.
• NetNamedPipeBinding: sends binary-encoded SOAP over named pipes. This binding is only usable for Indigo-to-Indigo communication between processes on the same Windows machine.
• NetMsmqBinding: sends binary-encoded SOAP over MSMQ, as described later. This binding can only be used for Indigo-to-Indigo communication.

The figure above shows example values for each of the three elements in an endpoint for the first Calculator service shown earlier. The name of the service's contract is Calculator, which is the name of the class that implements this service, and the binding is BasicProfileHttpBinding. Assuming this service is hosted using WAS, installed in the virtual directory calculator as described earlier, and running on a machine named qwickbank.com, its address might be http://www.qwickbank.com/calculator/calc.svc.

Unlike contracts, endpoints aren't defined using attributes. While it is possible to create endpoints programmatically, the most common approach will probably be to use a configuration file associated with the service. WAS-hosted services use the web.config file, while those hosted independently using the configuration file associated with the application they're running in (commonly referred to as app.config, although the actual filename varies). If used solely for the first Calculator service class shown earlier, this configuration file might look like this:

<configuration>

  <system.serviceModel>

    <services>

      <service serviceType="Calculator">

           <endpoint

          contractType="Calculator"

          bindingType="basicProfileHttpBinding />

      </service>

    </services>

  </system.serviceModel>

</configuration>

The configuration information for all services an Indigo application implements is contained within the system.serviceModel element. This element contains a services element that can contain one or more service elements. This simple example has only a single service, so there's just one occurrence of service. The serviceType attribute of the service element identifies the service class that implements the service this configuration applies to, which in this case is Calculator. Each service element can contain one or more endpoint elements, each of which specifies a particular endpoint through which this Indigo service can be accessed. In this example, the service exposes only a single endpoint, and so only one endpoint element appears. The name of the endpoint's contract is Calculator, which is the name of the class that implements it. If this configuration file were for the second Calculator service class shown earlier, which defined its service contract using an explicit interface, the value of the serviceType attribute would remain the same, but the value of contractType would instead be ICalculator, the name of this explicit interface. The binding specified here is basicProfileHttpBinding, although since this is the default, it could have been omitted. And assuming Calculator is a WAS-hosted service, an address is created automatically, so there's no need to specify one in this config file.

Creating an Indigo Client

Creating a basic Indigo service isn't especially complicated. Creating an Indigo client is even simpler. All that's required is to create a local stand-in for the service, called a proxy, that's connected to a particular endpoint on the target service, then invoke the service's operations via this proxy. The figure below shows how this looks.

Creating a proxy requires knowing exactly what contract is exposed by the target endpoint, then using this contract's definition to generate the proxy. In Indigo, this process is performed by a tool called svcutil. If the service is implemented using Indigo, svcutil can access the service's DLL to learn about the contract and generate a proxy. If only the service's WSDL definition is available, svcutil can read this to produce a proxy. If only the service itself is available, svcutil can access it directly using either WS-MetadataExchange or a simple HTTP GET to acquire the service's WSDL interface definition, then generate the proxy.

However it's generated, the client can create a new instance of the proxy, then invoke the service's methods using it. Here's a simple example of a client for the Calculator class:

using System.ServiceModel;

using Indigo.Example; // namespace for generated proxy class

 

public class CalculatorClient

{

  public static void Main()

  {

    CalculatorProxy p = new CalculatorProxy();

    Console.WriteLine("7 + 2 = {0}", p.Add(7, 2));

    Console.WriteLine("7 - 2 = {0}", p.Subtract(7, 2));

    p.Close();

  }

}

One more thing remains to be specified by the client: the exact endpoint it wishes to invoke operations on. Like a service, the client must specify the endpoint's contract, its binding, and its address, and this is typically done in a config file. In fact, if enough information is available, svcutil will automatically generate an appropriate client configuration file for the target service.