Integrating the World with .NET...Again Ever since the beginning of modern computing, we have sought out mechanisms that allow applications to access both the services and data of other applications, no matter where they exist. Indeed, it has been the whispered goal of developers to create applications so open and so well architected that other applications could access their value without having to understand anything about them. This was the goal of the distributed object movement of the early 1990s. Common Object Request Broker Architecture (CORBA), Component Object Model (COM), and a handful of other, more proprietary instances of distributed objects promoted technology that promised open access to application services and information. That is, if we would only do things their way. We are about to see another attempt to reach application development nirvana with the advent of the .NET strategy from Microsoft. Once again, we have another framework for doing something we've been trying to do for years. What's changed? In a word: the advent of the "Internet," and I don't mean the Web. Integration Obstacles Over the last few years, there has been a new interest in application integration, or allowing applications to share information and processes between and within enterprises. This has proven to be a difficult problem to solve, because differences in systems, both at the platform and application levels, are difficult to work around. For example, the simple structure of a customer record is different from application to application, and processes are exposed differently (if they are exposed at all). Enter a new breed of application integration technology, including products that work from the inside out, or from the enterprise to the trading community, and those that work from the outside in. While we're clearly getting better and allowing very different applications to exchange information (and sometimes processes), achieving total integration is still out of reach. We can define total integration as the ability to have many applications network-connected, exchanging information and sharing processes without having to understand anything about the applications they are interacting with. Indeed, the application would only need to leverage a common infrastructure for locating, understanding, and invoking remote application services. The uses for this type of integration are endless and include creating composite applications, or applications that aggregate the processes and information of many applications. For example, using this paradigm, application developers simply need to create the interface and add the application services by binding the interface to as many Internet-connected application services as required. .NET to the Rescue The concept of .NET is to provide this total integration. .NET defines Internet-connected applications as Web services. You can think of Web services as methods exposed by a company or software program that are both discoverable and accessible by other programs or organizations in need of a particular service; for example, purchasing a product, reserving a flight, and calculating tariffs discrete business services that have value to many organizations. .NET is an architectural vision, more than actual technology. However, pieces have already emerged, such as Universal Description, Discovery and Integration (UDDI), and a host of tools forthcoming from Microsoft that provide the opportunity for total integration. What is more, SOAP provides .NET with a standard way to expose objects through firewalls, business to business. The UDDI specification aims to define a common mechanism to both publish and discover information about Web services. Those that put UDDI together (IBM, Microsoft, and Ariba, and 63 others) look to create a type of "Yellow Pages" for the Internet. The first generation of the specification is out now. (See the "UDDI" section later in this chapter for more details.) Critical Success Factors Okay, understanding that .NET, at its core, is really nothing new, what are the chances that .NET will influence application development going forward? What are the chances that it will change the way businesses think about integration, inside and outside? Before any of this happens, a few things need to occur: First, developers must widely accept the .NET way of doing things. I am not sure Microsoft has captured the hearts and minds of most developers. Java still makes up a large part of enterprise development, for example. If Microsoft is to succeed here, it has to show capabilities at the enterprise level not yet seen within Microsoft development tools. Second, Microsoft must become heterogeneous. Let's face it, most enterprises will not give up their Sun boxes for Windows 2000 just yet. Microsoft needs to demonstrate it has the ability to work with the enemy, as well as deal with the frustrations of integrating many very different platforms. Finally, the .NET standard must be controlled by many companies, not just Microsoft. That lack of control may frustrate Microsoft, but without the perception of this standard being open, it doesn't have a chance. | 
