.NET FrameWork: Introduction
The .NET Framework is the result of two projects. The goal of the first project was to improve development on Microsoft Windows®, looking specifically at improving the Microsoft Component Object Model (COM). The second project aimed to create a platform for delivering software as a service. These two projects came together more than three years ago. The finished product dramatically improves programmer productivity, ease of deployment, and reliable application execution, and introduces a totally new concept to computing: that of XML Web services—loosely coupled applications and components designed for today’s heterogeneous computing landscape by communicating using Internet protocols and standards, such as SOAP and XML.
When it was created, the Web was basically a read-only file system with the added benefit that it used industry standards and protocols, enabling easy access to the contents of files. The few Web sites that were interactive were typically outward extensions of existing two-tier applications.
Early Web development was typically based on the C programming language and the Common Gateway Interface (CGI), with which very few programmers had experience. As a result, development costs for dynamic Web applications were high.
In addition, most of these Web applications were built on two-tier architectures, causing challenges around scalability and application integration. Developers simply did not design Web applications to be used by anything other than the Web page they were hosting; in other words, the user interface and the application logic were the same thing. Consequently, it was difficult to link Web applications together to form more interesting aggregations. An example of this problem would be a Web site that sells curtain rods but does not offer curtains, forcing potential customers to visit at least two separate sites to purchase a complete solution for their window treatments.
As a result of advances in the Microsoft Component Object Model (COM) and the release of technologies such as Microsoft’s Active Server Pages (ASP) in 1996, Web sites offered a more interactive user experience. ASP does this by making it easy to call the business logic and platform services that developers need through simple script languages. COM support makes it easy to write applications through its ability to package this business logic into modular units that can be written in a wide range of popular programming languages, such as Microsoft Visual Basic®, C++, or COBOL.
Web sites are now offering richer user experiences and taking basic steps to overcome some of the challenges of application integration, with tricks such as using HTML frames to embed one company’s Web site within another and HTML “screen scraping” to extract data from Web pages.
But these strategies for application integration have shortcomings. Simply put, they are brittle: What happens if the other Web site changes its content to promote a competitor or the company goes out of business, leaving the page with a broken link?
Advancements in Web development are rapidly moving from this two-tier architecture to an n-tier design, which enables a richer integration strategy by exposing business objects/middle-tier logic to Web and partner integration. The challenge with trying to use encapsulated business logic in this way is that most of these applications are designed on tightly coupled, proprietary protocols.
To date, the companies that have tried to offer solutions for enabling a Web site to expose application integration information and functionality in a modular, scalable, and Internet-friendly way have encountered significant challenges. Chief among these challenges are the following:
Time to market. The length of development time for getting an application or Web site to market may render the offering no longer viable.
Scaling to the Web. Existing object models and component designs simply do not work over Internet protocols. Stateless application development that can be rerouted and served by any server is a new concept for many developers. Yet such a design pattern is vitally important to achieve global scalability.
ack of end-to-end development tools. Tool sets available today don’t empower organizations with the flexibility necessary to stay ahead of their competitors. In the rapidly changing world of the Internet, organizations must exhibit the agility to integrate with new partners, using development tools that solve the challenges of today’s heterogeneous computing environments.
Solution: XML Web Services
An XML Web service is an application that exposes its functionality programmatically over the Internet or intranets using standard Internet protocols, such as HTTP and XML.
o solve the challenges facing Internet development now and in the future, we need to be able to write applications in any programming language, access any platform, and scale over the Internet to global proportions. This application development strategy is very compelling, as it enables companies to make use of existing hardware, utilize current applications, and use developers they have on staff, without having to retrain them on a new programming language.
This application style is called XML Web services, and it represents the next evolution of application development. An XML Web service is an application that exposes its functionality programmatically over the Internet or intranet using Internet protocols and standards, such as HTTP and XML.
XML Web services solve the challenges facing Web developers by combining the tightly coupled, highly productive aspects of n-tier computing with the loosely coupled, message-oriented concepts of the Web. Think of XML Web services as component programming over the Web.
Conceptually, developers integrate XML Web services into their applications by calling “Web application programming interfaces (APIs)” just as they would call local services. The difference is that these calls can be routed across the Internet to a service residing on a remote system. For example, a service such as Microsoft Passport could enable a developer to provide authentication for an application. By programming against the Passport service, the developer could take advantage of Passport’s infrastructure and rely on Passport to maintain the database of users, make sure that it is up and running, backed up properly, and so on—thus shifting a whole set of a development and operational chores.