Browse DevX
Sign up for e-mail newsletters from DevX


Preparing for Indigo—Choosing the Right Technology Today : Page 3

Today .NET offers three distinct technologies for application connectivity: Web services, remoting, and Enterprise Services. Each offers something that the other does not: interoperability, extensibility, and productivity. In preparing for Indigo, you need to choose today a technology that best approximates its programming model, most likely Enterprise Services.

Introducing Indigo
Indigo is the code name for the next generation application "plumbing" technology from Microsoft. Indigo will be released in the form of an SDK separately from the major .NET release cycles. Indigo requires .NET 2.0 and an underlying Windows XP family machine. No doubt you have heard the hottest buzzword in software engineering today—SOA or Service Oriented Architecture.

Indigo is intended to ease the task of developing SOA applications. In a nutshell, SOA is merely a natural evolution of existing analysis and design methodologies, in particular of component-oriented programming. With SOA, you strive to minimize the coupling between the client and the server by using interface-based programming (a core principle of component-oriented programming), and avoid sharing any type metadata between the client and the server (like Web services). In SOA you allow the service provider and service consumer to interact across boundaries. SOA requires a high degree of abstraction of the underlying technology, and uniform use of interaction standards. It is impractical to try and develop the required SOA connectivity on your own. This is exactly what Indigo provides—ready-made, out-of-the-box connectivity and plumbing that you can use to build SOA applications.

Allow clients to access the service over Web services, while inside the service uses Enterprise Services.
It is very important to realize that while you can use Indigo to build applications that address business models that are very difficult and costly to implement using other methodologies, you can and should use Indigo to address existing business needs. What this means is that you can use Indigo instead of Web services, remoting, or enterprise services, even if your application is not fully SOA. Doing so will ease the transition into SOA later on, when the business requirements will mandate such a degree of interaction, agility, and decoupling.

The Indigo architects were well-aware of the devil's alternatives that today's technologies pose to developers, forcing them to choose between interoperability, extensibility, and productivity. Indigo actually unifies the advantages of the three distinct technologies that preceded it: Indigo offers the same interoperability and boundaries-crossing ability of Web services. Indigo is based on a set of industry standards for Web services that are completely agnostic of development language, implementation technology, platforms, and vendor.

Indigo offers interoperability, extensibility, and productivity—the best of all worlds.
Indigo utilizes an extensible architecture, which like .NET remoting, uses messages to transport the client request to the service. The message processing on the client and service side is extensible, and you can add your own hooks and custom behavior when required. In fact, many parts of Indigo itself are implemented using Indigo's own extensibility model. Indigo offers a powerful set of services that significantly ease the task of developing modern applications. Like Enterprise Services, Indigo supports propagating distributed transactions, granular security and flow of security call context, concurrency management, asynchronous disconnected calls, reliable messaging, a publish-subscribe event broadcasting model, smart instance management techniques, and even service hosting and administration tools. In short, Indigo offers interoperability, extensibility, and productivity—the best of all worlds.

Thanks for your registration, follow us on our social networks to keep up-to-date