Microsoft Corporation
Applies to:
Microsoft® "Indigo"
Microsoft .NET Common Language Runtime
Microsoft Windows® XP
Microsoft Windows Server 2003
Summary: Find out the answers to some common questions about Microsoft "Indigo," including what it is, the features and benefits of it, and more.
Contents
The Basics
Migration and Interoperability
Release Plans: Schedules, Vehicles, Features, Quality
The Basics
What is Microsoft Indigo?
Indigo is a set of .NET technologies for building and running connected systems.
Indigo is a new breed of communications infrastructure built around the Web services architecture. Advanced Web services support in Indigo provides secure, reliable, and transacted messaging along with interoperability. Indigo's service-oriented programming model is built on the .NET Framework and simplifies development of connected systems. Indigo unifies a broad array of distributed systems capabilities in a composable and extensible architecture, spanning transports, security systems, messaging patterns, encodings, network topologies, and hosting models. Indigo will be an integral capability of Windows "Longhorn" and will also be supported on Windows XP and Windows Server 2003.
Microsoft has also done significant work to integrate Indigo with existing Microsoft technologies for building distributed systems including COM+, MSMQ, and ASP.NET Web services. Applications built with those existing technologies can now be exposed as services without modification to the application. This infrastructure-level solution greatly assists developers in exposing existing applications as services. Indigo also provides simple and mechanical mechanisms to migrate applications that use .NET Remoting, ASP.NET Web services, and .NET Enterprise Services to natively use the Indigo programming model.
How will Indigo change the way developers build applications?
Indigo is built from the ground up on the principle of service-orientation. Service-orientation differs from object-orientation primarily in how it defines the term "system." Object-oriented development views a system as a set of class libraries communicating directly in a tightly coupled fashion over a network. Service-oriented development views a system as a set of autonomous services that can easily communicate across both private and public networks.
What is "service-orientation"?
Service-orientation describes a new method for architecting connected systems, and is based upon three simple concepts:
- A service is a program that other programs interact with using messages.
- A client is a program that makes services usable to people.
- A connected system is a collection of inter-connected services and clients.
Instead of integrating disparate applications via direct object activations as in distributed object systems, applications expose a set of "services" that other applications can utilize. With service-orientation, applications running on different platforms and programmed using different development platforms can fully interoperate. In addition, application developers and system integrators do not require specific knowledge of the underlying object models, type systems and protocols of the software being integrated. Instead, all applications expose their services using standards-based protocols and policy definitions that can be dynamically acquired. This 'uncoupling' of the applications that comprise connected systems enables simpler integration, more flexibility in adapting systems to changes over time, and also enables more reliable operations.
Why is service-orientation important?
Service-orientation, as opposed to distributed object architectures such as J2EE, more closely reflect real-world processes and relationships. Hence, service-orientation represents a much more natural way to model and build software that solves real-world business processing needs. For example, distributed object systems are tightly coupled, and modifying one part of a distributed object system will break other parts of the system unless these other parts are modified as well and then the changes are deployed in unison. But such an approach is not practical, especially when different parts of the system are developed and operated by different organizations, such as in B2B scenarios. In addition, typically distributed object systems require that different parts of the system be created using the same underlying development language and object architecture—again an unrealistic requirement. Service-oriented systems, however, are loosely coupled and designed to support change. Services can be programmed in any language using any development tool, and can run on different platforms yet still be easily integrated.
Does service-oriented development conflict with object-oriented development?
No. Service-oriented development complements OO development. OO continues to fulfill an important role in the internal design of services. Service-orientation deals with how to interconnect services to build connected systems. To use an architecture analogy, OO addresses the architecture within a single building (a "service"), while service-orientation addresses the issues around city planning (a "system").
What is hard about service-oriented development today, and how specifically will Indigo make service-oriented development easier?
Today, it is difficult to model and build service-oriented systems due to the lack of a service-oriented programming model and the required communications infrastructure for interconnecting services within and across organizational and platform boundaries. Web services have provided a great start based upon standards such as SOAP v1.1, XML, and WSDL, and .NET today provides the best development platform for building Web services. But as the services get more complex and are used to solve bigger business problems, it is clear that both the Web service standards and the programming model needs to continue to evolve. For example, robust connected systems need transactions, reliable messaging, and integrated security—features that Indigo fully incorporates within its communication infrastructure. In addition, developers need a simple programming model for building services and clients in a productive way, another critical requirement Indigo addresses.
How is Indigo different than J2EE for building service-oriented applications?
J2EE is deeply rooted in a classic distributed object architecture (based on EJBs)—an architecture that has proven to be complex and brittle for Internet and enterprise-scale business integration scenarios. Service-oriented development is a fundamentally better way for building connected systems. But with its distributed object architecture, J2EE is not designed for service-oriented development. Indigo builds on .NET's leading-edge support for Web services, and provides a complete service-oriented programming model and integrated communications infrastructure for building and running connected systems in a productive and reliable way.
Migration and Interoperability
How will Indigo be made available to developers?
Indigo is part of Windows Longhorn and is available to every Longhorn application. Indigo will also be available as a separate download for Windows XP and Windows Server 2003.
How hard will it be to migrate to Indigo?
Indigo is designed to enable smooth migration of existing applications, and allows organizations the flexibility to migrate applications if and when they choose. All Indigo features are exposed via .NET managed APIs, and Indigo applications are built using the .NET framework. Indigo extends and enhances the .NET infrastructure technologies including ASP.NET Web services/ASMX, Web Service Enhancements (WSE), .NET Remoting, System.Messaging, and Enterprise services. From a scenario perspective, Indigo will also provide a superset of the functionality provided by MSMQ and COM+. In many cases the Indigo infrastructure can upgrade these features with few changes to existing .NET applications. In addition, new Indigo applications will interoperate with applications that use current .NET Framework 1.1 technologies, MSMQ, and COM+ via wire-level interoperability. This means that existing applications and Web services can be upgraded incrementally with new Indigo features or integrated "as-is" with no changes. Finally, all existing technologies will remain in place as fully supported .NET technologies. This strategy ensures that customer investments in existing Microsoft technologies are fully preserved.
How much of a learning curve will developers experience in adopting Indigo as a way to build connected systems?
Developers will be able to quickly and easily take advantage of the Indigo programming model because it is designed to fit naturally with existing .NET programming concepts while dramatically simplifying service-oriented development. Indigo is based on the .NET CLR and the Indigo programming model is accessible via any .NET language (C#, VB.NET, J#, COBOL, etc.). In addition, the Indigo communications infrastructure dramatically reduces the amount of manual development that is today required to build transacted, reliable, and secure service-oriented applications.
For developers building applications today, what should they do to insure an easy transition to exploit Indigo when it ships?
Developers should do the following to build applications today that can easily transition to the Indigo communications infrastructure and programming constructs in the future:
- Build services using the ASP.NET (ASMX) Web service model.
- Enhance your ASMX service with WSE if you need the WSE feature set.
- Use object technology in a service's implementation.
- Use System.Messaging if you need the reliable messaging and queuing features in MSMQ.
Specific Caveats:
- ASMX
- Avoid or abstract using low-level extensibility such as the HTTP Context object.
- .NET Remoting
- Avoid or abstract using low-level extensibility such as .NET Remoting sinks and channels.
- Enterprise services
- Avoid passing object references inside of ES.
- Do not use COM+ APIs—use System.EnterpriseServices.
- Do not use MSMQ APIs—use System.Messaging.
Will Indigo replace ASP.NET Web services? How will I convert my existing ASMX-based applications?
Indigo will not replace ASP.NET Web services. Existing ASP.NET Web services will interoperate with services and clients built on Indigo. For developers who want to migrate ASP.NET Web services to Indigo, the migration will be simple and straightforward, with the caveats noted above.
Will Indigo replace Enterprise services? How will I convert my existing ES applications?
Indigo will not replace Enterprise services (such as transactions). Existing ES applications will interoperate with services and clients built on Indigo. For developers who want to migrate ES applications to Indigo, the migration will be simple and straightforward, with the caveats noted above.
Will Indigo replace COM+?
COM+ is a feature of Windows and will continue to be supported. Existing COM+ components can be integrated within Indigo applications via the existing .NET/COM+ interoperability, or COM+ components can be migrated incrementally to .NET including the new Indigo features. In addition, the Longhorn version of COM+ will be upgraded to support Indigo services.
Will Indigo replace MSMQ? How easily will MSMQ applications transition to take advantage of the Indigo message infrastructure?
Indigo will not replace MSMQ. MSMQ will continue to be supported as a part of Windows, and the Longhorn version of MSMQ will be upgraded to fully support Indigo services such that MSMQ applications can communicate with Indigo services and vice versa.
Will Indigo replace WSE? How easily will WSE applications transition to take advantage of the Indigo infrastructure?
WSE is a vehicle for early adopters to take advantage of leading edge Service Oriented technology, such as the latest standards for transactions and security for Web services. Indigo provides a better, more complete communications infrastructure and programming model for building service-oriented programs than WSE. While Indigo applications will interoperate with applications built on the last version of WSE, WSE should only be used when gaining a first mover advantage is more important than having code portability to the next major revision of the platform. Migrating WSE code to Indigo may require a non-trivial development investment.
How does Indigo relate to SOAP? Will Indigo applications interoperate with Web services built in J2EE, or built with other technologies?
Indigo includes support for the latest Web services standards, including SOAP. Applications built with Indigo will interoperate with any application built on infrastructure that also conforms to these standards. This includes IBM WebSphere, BEA WebLogic and other Web services built in J2EE that are SOAP-standards compliant. Microsoft is deeply committed to platform interoperability, and an active member of the key standards organizations defining the latest standards for Web services including SOAP and XML.
Release Plans: Schedules, Vehicles, Features, Quality
When will Indigo ship?
We have not announced a release date for Indigo. A developer preview version is being made available to developers attending the Professional Developers Conference in the fall of 2003.
How does Indigo relate to Longhorn?
Indigo is a major feature of the Longhorn version of Windows. Indigo will be available to all Longhorn applications.
When can developers start building Indigo applications?
Developers can start learning about Indigo and building working prototypes using the preview release provided at the Professional Developers Conference.
Will Indigo be made available only through Longhorn?
Indigo will also be provided as a separate download for Windows XP and Windows Server 2003.
How does Indigo relate to "Whidbey"?
"Whidbey" is the code name of the next release of the .NET Framework and Visual Studio® .NET development tools, incorporating new features such as support for 64-bit platforms. "Whidbey" is still in development and is being made available in developer preview form at the Professional Developers Conference 2003. Indigo is a set of additional .NET managed class libraries, and is fully compatible with the "Whidbey" Visual Studio tools. A developer preview of Indigo is also being provided at the Professional Developers Conference 2003.
Is the PDC preview release of Indigo feature complete?
No. The version of Indigo being delivered at the PDC is a developer preview. Later releases will incorporate new functionality into Indigo, although no specific announcements are being made at this time. Also, Microsoft continues to work with a broad set of customers to ensure Indigo meets their core requirements before it ships.