Microsoft Windows Distributed interNet Applications Architecture (Windows DNA) is the application development model for the Windows platform. Windows DNA specifies how to: develop robust, scalable, distributed applications using the Windows platform; extend existing data and external applications to support the Internet; and support a wide range of client devices maximizing the reach of an application. Developers are free from the burden of building or assembling the required infrastructure for distributed applications and can focus on delivering business solutions.
Windows DNA addresses requirements at all tiers of modern distributed applications: presentation, business logic, and data. Like the familiar PC environment, Windows DNA enables developers to build tightly integrated applications by accessing a rich set of application services in the Windows platform using a wide range of familiar tools. These services are exposed in a unified way through the Component Object Model (COM). Windows DNA provides customers with a roadmap for creating successful solutions that build on their existing computing investments and will take them into the future. Using Windows DNA, any developer will be able to build or extend existing applications to combine the power and richness of the PC, the robustness of client/server computing, and the universal reach and global communications capabilities of the Internet.
For some time now, both small and large companies have been building robust applications for personal computers that continue to be ever more powerful and available at increasingly lower costs. While these applications are being used by millions of users each day, new forces are having a profound effect on the way software developers build applications today and the platform in which they develop and deploy their application.
The increased presence of Internet technologies is enabling global sharing of informationâ€not only from small and large businesses, but individuals as well. The Internet has sparked a new creativity in many, resulting in many new businesses popping up overnight, running 24 hours a day, seven days a week. Competition and the increased pace of change are putting ever-increasing demands for an application platform that enables application developers to build and rapidly deploy highly adaptive applications in order to gain strategic advantage.
It is possible to think of these new Internet applications needing to handle literally millions of usersâ€a scale difficult to imagine a just a few short years ago. As a result, applications need to deal with user volumes of this scale, reliable to operate 24 hours a day and flexible to meet changing business needs. The application platform that underlies these types of applications must also provide a coherent application model along with a set of infrastructure and prebuilt services for enabling development and management of these new applications.
Introducing Windows DNA: Framework for a New Generation of Computing Solutions
Today, the convergence of Internet and Windows computing technologies promises exciting new opportunities for savvy businesses: to create a new generation of computing solutions that dramatically improve the responsiveness of the organization, to more effectively use the Internet and the Web to reach customers directly, and to better connect people to information any time or any place. When a technology system delivers these results, it is called a Digital Nervous System. A Digital Nervous System relies on connected PCs and integrated software to make the flow of information rapid and accurate. It helps everyone act faster and make more informed decisions. It prepares companies to react to unplanned events. It allows people focus on business, not technology.
Creating a true Digital Nervous System takes commitment, time, and imagination. It is not something every company will have the determination to do. But those who do will have a distinct advantage over those who don't. In creating a Digital Nervous System, organizations face many challenges: How can they take advantage of new Internet technologies while preserving existing investments in people, applications, and data? How can they build modern, scalable computing solutions that are dynamic and flexible to change? How can they lower the overall cost of computing while making complex computing environments work?
Understanding the Microsoft Windows DNA Architecture
Microsoft President Steve Ballmer caught the attention of industry observers today by introducing Windows DNA for Manufacturing, a technical architecture designed to bring software integration to manufacturing environments. Earlier this month, a new Windows DNA Lab opened near Washington, D.C. -- the third such facility in the United States to spring up as a resource for companies building solutions on Windows DNA.
Clearly, Windows DNA is gaining a strong following. But as with any new industry trend, it raises an obvious question: What exactly does this architecture have to offer? More important, what does it mean to the people it's designed to affect? Jigish Avalani, group manager of Windows DNA marketing at Microsoft, explains that Windows DNA refers to the Windows Distributed interNet Application architecture, launched by Microsoft in fall of 1997.
"Windows DNA is essentially a 'blueprint' that enables corporate developers and independent software vendors (ISVs) to design and build distributed business applications using technologies that are inherent to the Windows platform," Avalani says. "It consists of a conceptual model and a series of guidelines to help developers make the right choices when creating new software applications."
Applications based on Windows DNA will be deployed primarily by businesses, from small companies to large enterprise organizations. Consumers are likely to use many of the applications built to take advantage of Windows DNA, such as electronic commerce Web sites and online banking applications.
A major force driving the need for Windows DNA is the Internet, which has dramatically changed the computing landscape. Five years ago, the process of developing programs used by one person on one computer was relatively straightforward. By contrast, some of today's most powerful applications support thousands of simultaneous users, need to run 24 hours a day, and must be accessible from a wide variety of devices -- from handheld computers to high-performance workstations. To meet these demanding requirements, application developers need adequate planning tools and guidance on how to incorporate the appropriate technologies. The Windows DNA architecture addresses this need.
Microsoft Windows DNA
Microsoft Windows Distributed interNet Applications Architecture (Windows DNA) is Microsoft's framework for building a new generation of highly adaptable business solutions that enable companies to fully exploit the benefits of the Digital Nervous System. Windows DNA is the first application architecture to fully embrace and integrate the Internet, client/server, and PC models of computing for a new class of distributed computing solutions. Using the Windows DNA model, customers can build modern, scalable, multitier business applications that can be delivered over any network. Windows DNA applications can improve the flow of information within and without the organization, are dynamic and flexible to change as business needs evolve, and can be easily integrated with existing systems and data. Because Windows DNA applications leverage deeply integrated Windows platform services that work together, organizations can focus on delivering business solutions rather than on being systems integrators. See Figure 1.
Figure 1. Windows DNA tools and system services
Guiding Principles of Windows DNA
The Microsoft application platform consists of a multi tiered distributed application model called Windows DNA (Figure 1) and a comprehensive set of infrastructure and application services. Windows DNA unifies the best of the services available on personal computers, application servers, and mainframes today; the benefits inherent in client-server computing and the best of Internet technologies around a common, component-based application architecture.
The following principles guided Microsoft in developing the Windows DNA architecture:
Â¢ Web computing without compromise.
Organizations want to create solutions that fully exploit the global reach and "on demand" communication capabilities of the Internet, while empowering end users with the flexibility and control of today's PC applications. In short, they want to take advantage of the Internet without compromising their ability to exploit advances in PC technology.
Organizations want the new applications they build to work with their existing applications and to extend those applications with new functionality. They require solutions that adhere to open protocols and standards so that other vendor solutions can be integrated. They reject approaches that force them to rewrite the legions of applications still in active use today and the thousands still under development.
Â¢ True integration.
In order for organizations to successfully deploy truly scalable and manageable distributed applications, key capabilities such as security, management, transaction monitoring, component services, and directory services need to be developed, tested, and delivered as integral features of the underlying platform. In many other platforms, these critical services are provided as piecemeal, non-integrated offerings often from different vendors, which forces IT professionals to function as system integrators.
Â¢ Lower cost of ownership.
Organizations want to provide their customers with applications that are easier to deploy and manage, and easier to change and evolve over time. They require solutions that do not involve intensive effort and massive resources to deploy into a working environment, and that reduce their cost of ownership both on the desktop and server administration side.
Â¢ Faster time to market.
Organizations want to be able to achieve all of the above while meeting tight application delivery schedules, using mainstream development tools, and without need for massive re-education or a "paradigm shift" in the way they build software. Expose services and functionality through the underlying "plumbing" to reduce the amount of code developers must write.
Â¢ Reduced complexity.
Integrate key services directly into the operating system and expose them in a unified way through the components. Reduce the need for information technology (IT) professionals to function as system integrators so they can focus on solving the business problem.
Â¢ Language, tool, and hardware independence .
Provide a language-neutral component model so developers can use task-appropriate tools. Build on the PC model of computing, wherein customers can deploy solutions on widely available hardware.
MICROSOFT WINDOWS DISTRIBUTED
Windows DNA: Building Windows Applications for the Internet Age
Windows DNA Technologies
The heart of Windows DNA is the integration of Web and client/server application development models through the Component Object Model (COM). Windows DNA services are exposed in a unified way through COM for applications to use. These services include component management, Dynamic HTML, Web browser and server, scripting, transactions, message queuing, security, directory, database and data access, systems management, and user interface.
Windows DNA fully embraces an open approach to Web computing. It builds on the many important standards efforts approved by bodies such as the World Wide Web Consortium (W3C) and the Internet Engineering Task Force (IETF). Adhering to open protocols and published interfaces makes it easy to integrate other vendor solutions and provides broad interoperability with existing systems.
Because Windows DNA is based on COM and open Internet standards, developers can use any language or tool to create compatible applications. COM provides a modern, language-independent object model that provides a standard way for applications to interoperate at all tiers of the architecture. Through COM, developers can extend any part of the application via pluggable software components that can be written in C++, Visual Basic, Java, or other languages. Because of this open approach, Windows DNA supports a broad range of development tools today, including tools from Microsoft, Borland, Powersoft, and many other vendors.
Microsoft developed the Windows Distributed interNet Application Architecture (Windows DNA) as a way to fully integrate the Web with the n-tier model of development. Windows DNA defines a framework for delivering solutions that meet the demanding requirements of corporate computing, the Internet, intranets, and global electronic commerce, while reducing overall development and deployment costs.
Windows DNA architecture employs standard Windows-based services to address the requirements of each tier in the multi tiered solution: user interface and navigation, business logic, and data storage. The services used in Windows DNA, which are integrated through the Component Object Model (COM), include:
Â¢ Dynamic HTML (DHTML)
Â¢ Active Server Pages (ASP)
Â¢ COM components
Â¢ Component Services
Â¢ Active Directory Services
Â¢ WindowsÃ‚Â® security services
Â¢ MicrosoftÃ‚Â® Message Queuing
Â¢ Microsoft Data Access Components
Microsoft built Windows DNA using open protocols and public interfaces, making it easy for organizations to integrate third-party products. In addition, by supporting industry-defined standards for Internet computing, Windows DNA will make it easier for developers to respond to technology changes. Some of the technologies recently added to the Windows DNA are outlined in the section given below, and are illustrated in the following diagram.
Figure 2. Technologies added to Windows DNA
Microsoft Windows Distributed interNet Application (Windows DNA) Architecture is a dynamic set of technologies that you can use to build Web applications. Microsoft has added several key aspects to the architecture with Windows 2000.
This section contains:
Â¢ Component Services
Â¢ Dynamic HTML: Dynamic Hypertext Markup Language (DHTML).
Â¢ Windows Script Components
Â¢ XML: Extensible Markup Language (XML).
Â¢ Active Directory Service Interfaces
Component Services :
New with Windows 2000, Component Services provides a number of services that make component and Web application development easier. These services include:
Queued Components allow you to create components that can execute immediately if the client and server are connected. They provide an easy way to invoke and execute components asynchronously. In the event that the client and server are not connected, the component can hold execution until a connection is made. Queued Components assist the developer by using method calls similar to those calls used in component development, thus diminishing the need for an in-depth knowledge of marshaling.
Component Services Events
Component Services Events lets publishers and subscribers loosely connect to data sources so that these sources can be developed, deployed, and executed separately. The publisher does not need to know the number and location of the subscriber, and the subscriber uses an intermediate broker to find a publisher and manage the subscription to it. The event system simplifies component and Web application development by allowing both publisher and subscriber identities to be persistent: Publishers and subscribers identities can be manipulated without being known to each other.
Dynamic HTML :
Dynamic HTML (DHTML), which Microsoft introduced with Internet Explorer 4.0, allows you to create much richer HTML that responds to events on the client. By upgrading your HTML pages to take advantage of DHTML, you will not only enhance the user experience, you will also build Web applications that use server resources more efficiently.
DHTML controls the appearance of HTML pages by setting properties in the document object model (DOM), a model which Microsoft has proposed to the World Wide Web Consortium (W3C) as a standard. DHTML exposes an event model that allows you to change DOM properties dynamically.
Windows Script Components :
Script component technology is made up of the following:
Â¢ The script component run-time (Scrobj.dll).
Â¢ Interface handlers, which are components that extend the script component run-time. An interface handler is a compiled component (generally written in C++) that implements specific
COM interfaces. When you install the script component run-time, you will receive the Automation interface handler, which makes it possible to call your script component from an .asp file.
Â¢ Your script component file (a.sct file). In your script component, you specify which interface handler you want to use. Your script component also defines the methods that can be called from an .asp file to accomplish the intended functionality.
Script components are an excellent technology for developing prototypes of COM components. Script components, like any other COM component, can be registered with Component Services if you intend for them to participate in transactions, or if you want to take advantage of the Component Services run-time environment. Because they are COM components, script components can access the ASP built-in objects.
Extensible Markup Language (XML), like HTML, allows you to apply markup, in the form of tags, to a document. However, unlike HTML, XML is designed to be used as a generalized markup language. In other words, markup applied to an XML document can be used to convey not only display and formatting information as with HTML, but semantic and organizational structure for the document. This flexibility makes XML extremely powerful, and the possible range of applications is impressive.
Active Directory Service Interfaces:
Microsoft Active Directory Service Interfaces (ADSI) is a COM-based directory service model that allows ADSI-compliant client applications to access a wide variety of distinct directory protocols, including Windows Directory Services, LDAP, and NDS, while using a single, standard set of interfaces. ADSI shields the client application from the implementation and operational details of the underlying data store or protocol.
An application called an ADSI provider makes itself available to ADSI client applications. The data exposed by the provider is organized in a custom namespace, defined by the provider. In addition to implementing the interfaces defined by ADSI, the provider also can implement the ADSI schema. The schema is used to provide metadata about the namespace structure and objects that are provided by the ADSI provider.
ADSI and IIS
IIS currently stores most Internet site configuration information in a custom data store called the IIS metabase. IIS exposes a low-level DCOM interface that allows applications to gain access to, and manipulate, the metabase. To make it easy to access the metabase, IIS also includes an ADSI provider that wraps most of the functionality provided by the DCOM interface, and exposes it to any ADSI-compliant client applications.
COM: The Cornerstone of Windows DNA
Avalani notes that Windows DNA is based on a programming model called COM (Component Object Model). The COM model has come into widespread use since its introduction by Microsoft and it is an integral part of many Microsoft applications and technologies, including Internet Explorer and the Office suite of applications.
Unlike traditional software development, which required each application to be built from scratch, COM allows developers to create complex applications using a series of small software objects. Much like cars or houses are built with standardized "parts," COM lets developers make portions of their applications using components. For example, Avalani says, a component might be a tax calculation engine or the business rules for a price list. A growing number of third-party vendors sell COM components.
This approach speeds up the development process by allowing several teams to work on separate parts at the same time. Developers can also reuse components from one project to the next, and they can easily swap out or update a particular component without affecting other portions of the application. COM also offers the advantage of programming language independence. That means developers can create COM components using the tools and languages they're familiar with, such as Visual Basic, C, C++ and Java.
An easy way to look at it is that COM serves as the glue between the tiers of the architecture, allowing Windows DNA applications to communicate in a highly distributed environment.
DNA - An Architecture for Distributed Applications
DNA stands for Distributed InterNet Architecture, and it is the model Microsoft promotes for development of applications that will be accessable by widely separated clients. It can also be, however, a confusing array of terms and technologies.
To combat this confusion, BengalCore recently wrote an explanation of the different sections and development components that make up the Microsoft DNA, as part of a course on new technologies.
The following picture shows the different pieces within the DNA architecture, and how they work together.
Placing your business objects on the server increases your control over the entire application, and over configuration issues. It also increases security aspects of the system, and reduces the client-side software footprint.
1. Central Database
By keeping all data in a central location, you open up opportunities for data sharing between clients and for central reporting. Business objects need only a central point-of-entry into the data store.
2. C++ COM DLLs
An easy way to port legacy code to a distributed application is to "wrap" that code with a COM interface. That code is then accessible to all other system components.
3. VB COM DLLs
Visual Basic provides easy control of databases, and into the automation methods for Excel, Access and SourceSafe.
4. IIS Web Server
Microsoftâ„¢s web server software product. This comes with the NT Server operating system, and provides support for Active Server Pages, ISAPI, and custom embedded controls.
5. Active Server Pages
ASP is a scripting language that is supported by IIS. It is a combination of HTML, VBScript, and COM. These scripts run on the web server, and then converted to HTML for the client response. ASP provides default components for interaction with the server or with a database. They can also embed custom business object components for your application.
DNA expands the client base of your application to anyone capable of running the Internet Explorer 4.0 browser, making crossing machine boundaries easier.
6. ActiveX controls
These are visual components that are embedded into a web page and downloaded to the client machine. They can provide custom display or input beyond that which is available in the standard set of controls (buttons, text fields, and lists). An example ActiveX control would be a custom chart or grid.
7. Internet Explorer 4.0
The 4.0 version of Internet Explorer supports several new features that allows the browser to become the framework for your applicationâ„¢s Graphical User Interface (GUI). By using your browser as the presentation layer, all of the networking to the server is handled.
8. Dynamic HTML
This extension to the HTML standard provides precise placement of objects on the screen, data binding, effects, and dynamic modification capabilities.
Graphics and presentation are the final piece to this puzzle. A consistent GUI provides customers with a pleasing means of interfacing with your application.
Given the proper underlying infrastructure, the multitier model of presentation, business logic and data can physically distribute processing over many computers. However, the core abstractions that have worked for singleâ€œ and twoâ€œtier models in the pastâ€high-level programming languages, database management systems, and graphical user interfacesâ€do not fully address the requirements of multitier application development. A different level of abstraction is needed to develop scalable, manageable and maintainable multiuser applications, and at Microsoft we believe this abstraction is cooperating components.
Microsoft's Windows DNA strategy rests on Microsoft's vision of cooperating components that are built based on the binary standard called the Component Object Model (COM). COM is the most widely used component software model in the world, available on more than 150 million desktops and servers today. It provides the richest set of integrated services, the widest choice of easy-to-use tools, and the largest set of available applications. In addition, it provides the only currently viable market for reusable, off-the-shelf client and server components.
COM enables software developers to build applications from binary software components that can be deployed at any tier of the application model. These components provide support for packaging, partitioning, and distributed application functionality. COM enables applications to be developed with components by encapsulating any type of code or application functionality, such as a user interface control or line of business object. A component may have one or more interfaces; each exposes a set of methods and properties that can be queried and set by other components and applications. For example, a customer component might expose various properties such as name, address, and telephone number.
With the Microsoft Windows DNA model, components take away the complexity of building multitier applications. Applications based on components and the Windows DNA model rely on a common set of infrastructure and networking services provided in the Windows application platform. The Microsoft Windows NT security service, for example, provides access control to the Internet Information Server (IIS), as well as transaction and message queuing services. Other common services include systems management, directory services, networking, and hardware support.
Client Environments and Presentation Tier
Today, many application developers using cooperating components target the development of their applications to the Windows platform to take full advantage of the rich user interface Windows has to offer. Likewise, customers have come to expect a rich, highly functional user interface from their applications. The extended reach of information and services to customers that the Internet has enabled has created a new challenge for the application developer. The application developer today must develop a user interface that is distributable, available on Windows and non-Windows platforms, and supports a wide range of client environments, from handheld wireless devices to high-end workstations. Yet, applications must be rich with features to stay competitive and maintain the functionality that customers have come to expect.
As depicted in Figure 3, Windows DNA offers a broad range of presentation options, giving the application developer the choice when developing the best solution. Windows DNA permits the developer to choose the appropriate Windows components and Internet technologies to support the richest possible interface and range of client environments, from handheld wireless devices to high-end workstations.
Maintaining broad reach to a wide range of client environments while achieving the greatest compatibility with all browsers, application developers will generally use standard HTML in developing their browser neutral applications. Microsoft tools and application services support the current generation of standard HTML.
Figure 3. Windows DNA presentation approaches
The compromise in using static HTML is the reduced amount of functionality and richness in an applications user interface that customers have come to expect. This is okay for some applications as their application requires broad reach and browser neutrality.
There is a class of applications that don't have a browser neutrality requirement. The reality is that many corporations standardize on a single browser. In addition, application developers who want to provide more functionality in their application than they can achieve with standard HTML write code to determine the browser being used. These browser enhanced applications are written to take advantage of the technologies inherent in the browser to gain maximum functionality and richness. With technologies like dynamic HTML (DHTML) and scripting, application developers can create actions with functional Web-based interfaces for data entry or reporting without using custom controls of applets.
DHTML is based on the W3C-standard Document Object Model, which makes all Web-page elements programmable objects. Think of DHTML as a "programmable" HTML. Contents of the HTML document, including style and positioning information, can be modified dynamically by script code embedded in the page. Thus, scripts can change the style, content, and structure of a Web page without having to refresh the Web page from the Web server. By doing so, the client does not have to repeatedly return to the Web server for changes in display resulting in increased network performance. Unlike Java applets or Microsoft ActiveX controls, DHTML has no dependencies on the underlying virtual machine or operating system. For clients without DHTML support, the content appears in a gracefully degraded form.
There are times when DHTML plus scripting is not enough. Segments of applications need to leverage the operating system and underlying machine on which it is hosted, while still maintaining an active connection to the Internet for data or additional services. It is in those instances that application developers can take advantage of the robust components and Internet services provided by Windows to build Internet- reliant applications. Unlike page-based applications that are being run within the context of a browser, an Internet-reliant application is a full-fledged Windows executable that has full access to the broad range of services provided by the Windows client. These applications generally use a combination of HTML, DHTML, scripting, and ActiveX controls to provide rich integration with the client system as well as full connectivity to remote services on the Internet.
Applications written using the Microsoft Win32 application programming interface (API) offer the most functionality with reach limited to the application platforms that support the Win32 API. Through the use of cooperating components, developers today can have access to Internet technologies in the Windows application platform from within a Win32-based application. Applications written to the Win32 API that take advantage of system features and leverage Internet connectivity are called Internet-enhanced applications. Some common examples are the Microsoft Office 97 and Microsoft Visual Studio 98 development systems. These applications support unified browsing by embedding hyperlinks from within the application, host the browser for the display of documentation written in DHTML, and provide the capability to download updates to the products over the Internet seamlessly.
Figure 4. Application services
The business logic tier is the heart of the application, where the application-specific processing and business rules are maintained. Business logic placed in components bridge the client environments and the data tiers. The Windows DNA application platform has been developed through years of innovation in supporting high-volume, transactional, large-scale application deployments, and provides a powerful run-time environment for hosting business logic components. As depicted in Figure 4, the application platform for developing Windows DNA applications include Web services, messaging services, and component services.
Integrated with Microsoft's application platform is a high-performance gateway to the presentation tier. Microsoft's Internet Information Server enables the development of Web-based business applications that can be extended over the Internet or deployed over corporate intranets. With IIS, Microsoft introduced a new paradigm to the Internetâ€transactional applications. Transactions are the plumbing that makes it possible to run real business applications with rapid development, easy scalability, and reliability.
Active Server Pages (ASP), a component of IIS, is the language-neutral, compile-free, server-side scripting environment that is used to create and run dynamic, interactive Web server applications. By combining DHTML, scripting, and components, ASP enables application developers to create dynamic, interactive Web content and powerful Web-based applications.
With the trend toward distributed computing in enterprise environments, it is important to have flexible and reliable communication among applications. Businesses often require independent applications that are running on different systems to communicate with each other and exchange messages even though the applications may not be running at the same time. Applications built using a combination of ASP scripts communicating with cooperating components can interoperate with existing systems, applications, and data.
Windows DNA is based on a programming model called COM (Component Object Model). The COM model has come into widespread use since its introduction by Microsoft and it is an integral part of many Microsoft applications and technologies, including Internet Explorer and the Office suite of applications.
Unlike traditional software development, which required each application to be built from scratch, COM allows developers to create complex applications using a series of small software objects. Much like cars or houses are built with standardized "parts," COM lets developers make portions of their applications using components. For example, a component might be a tax calculation engine or the business rules for a price list. A growing number of third-party vendors sell COM components.
This approach speeds up the development process by allowing several teams to work on separate parts at the same time. Developers can also reuse components from one project to the next, and they can easily swap out or update a particular component without affecting other portions of the application. COM also offers the advantage of programming language independence. That means developers can create COM components using the tools and languages they're familiar with, such as Visual Basic, C, C++ and Java.
In the early 1990s, the underlying concept that facilitated interoperability was componentization; the underlying technology that enabled interoperability was COM. As it turns out, componentization is not only a great way to achieve interoperability, but a great way to design and develop software in general. So, in the mid-1990s Microsoft broadened COM's applicability beyond the desktop application to also include distributed applications by introducing Microsoft Transaction Server (MTS). MTS was an extension to the COM programming model that provided services for the development, deployment, and management of component-based distributed applications. MTS was a foundation of application platform services that facilitated the development of distributed applications for the Windows platform in a much simpler, more cost-effective manner than other alternatives.
COM+ is the next evolutionary step of COM and MTS. The unification of the programming models inherent in COM and MTS services makes it easier to develop distributed applications by eliminating the tedious nuances associated with developing, debugging, deploying, and maintaining an application that relies on COM for certain services and MTS for others. The benefits to the application developer is to make it faster, easier, and ultimately cheaper to develop distributed applications by reducing the amount of code required to leverage underlying system services.
To continue to broaden COM and the services offered today in MTS 2.0, COM+ consists of enhancements to existing services as well as new services to the application platform. They include:
Â¢ Bring your own transaction. COM components are able to participate in transactions managed by non-COM+ transaction processing (TP) environments that support the Transaction Internet Protocol (TIP).
Â¢ Expanded security. Support for both role-based security and process-access-permissions security. In the role-based security model, access to various parts of an application is granted or denied based on the logical group or role that the caller has been assigned to (for example, administrator, full-time employee, or part-time employee). COM+ expands on the current implementation of role-based security by including method-level security for both custom and IDispatch(Ex)-based interfaces.
Â¢ Centralized administration. The Component Services Explorer, a replacement for today's MTS Explorer and DCOMCNFG, presents a unified administrative model, making it easier to deploy, manage, and monitor n-tiered applications by eliminating the overhead of using numerous individual administration tools.
Â¢ In-memory database. The In-Memory Database maintains durable state information and transient state information in a consistent manner. It is an in-memory, fully transactional database system designed to provide extremely fast access to data on the machine on which it resides.
Â¢ Queued components. For asynchronous deferred execution when cooperating components are disconnected, this is in addition to the session-based, synchronous client/server programming model, where the client maintains a logical connection to the server today.
Â¢ Event notification. For times when a loosely coupled event notification mechanism is desirable, COM+ Events is a unicast/multicast, publish/subscribe event mechanism that allows multiple clients to "subscribe" to events that are "published" by various servers. This is in addition to the existing event notification framework delivered with connection points.
Â¢ Load balancing. Load balancing allows component-based applications to distribute their workload across an application cluster in a client-transparent manner.
Microsoft Message Queue Server (MSMQ) provides loosely coupled and reliable network communications services based on a messaging queuing model. MSMQ makes it easy to integrate applications by implementing a push-style business event delivery environment between applications, and to build reliable applications that work over unreliable but cost-effective networks. The simple application based on COM lets developers focus on business logic and not on sophisticated communications programming. MSMQ also offers seamless interoperability with other message queuing products, such as IBM's MQSeries, through products available from Microsoft's independent software vendor (ISV) partners.
Extending to the Mainframe Transaction-Processing World
Using Microsoft's COM Transaction Integrator (TI), application developers can extend and expose complex instruction set computers (CISC) and information management system (IMS) transaction programs through the use of COM components. COM TI consists of a set of development tools and run-time services that automatically "wrap" IBM mainframe transaction and business logic as COM components that run in a Windows DNA environment. All COM TI processing is done on a Windows NT Server; host communication is accomplished through the SNA Server. COM TI does not require the mainframe to run any executable code or be programmed in any special way.
Universal Data Access
Universal Data Access is Microsoft's strategy for providing access to information across the enterprise. Today, companies building database solutions face a number of challenges as they seek to gain maximum business advantage from the data and information distributed throughout their corporations. Universal Data Access provides high-performance access to a variety of information sources, including relational and nonrelational data, and an easy-to-use programming interface that is tool and language independent.
Universal Data Access does not require expensive and time-consuming movement of data into a single data store, nor does it require commitment to a single vendor's products. Universal Data Access is based on open industry specifications with broad industry support, and works with all major established database platforms.
As depicted in Figure 5, the Universal Data Access-based framework operates at two levels. At the systems level, OLE DB defines a component-based architecture specified as a set of COM-based interfaces that encapsulate various database management system services. The OLE DB architecture does not constrain the nature of the data source; as a result, Microsoft and ISV have introduced providers for a wide variety of indexed sequential files, groupware products, and desktop products. At the application level, ActiveX Data Objects (ADO) provides a high-level interface to enable developers to access data from any programming language.
Figure 5. Data access
Top Windows DNA Performance Mistakes and How to Prevent Them
Microsoft Windows DNA is Microsoft's platform for building a new generation of effective and versatile business applications for the Web. Through the COM+ programming model, Windows DNA incorporates a number of familiar technologies, including Microsoft Windows 2000, Microsoft Visual Studio, and Microsoft SQL ServerÃƒÆ’Å¡Ãƒâ€šâ€žÂ¢, allowing for the construction of a secure, stableâ€and scalableâ€business infrastructure that can readily integrate diverse systems and applications.
At the core of Windows DNA is the capability of building n-tier applications, which include one or more middle tiers between the client and the server. An important element of contemporary software architecture, n-tier applications provide clear advantages over typical client/server implementations, especially in the level of scalability they can provide. They are essential for the increasing levels of cross-platform interactivity required by today's, and tomorrow's, business Web sites.
Producing a good n-tier application often entails a series of judgments in planning and implementing the final product. When those decisions are poorly made, development teams can encounter time-consumingâ€and often difficult to solveâ€performance problems after the application has been installed and implemented. Fortunately, many of these problems can be anticipated and prevented. This article shows you how to find and eliminate them early in the development process. The mistakes that follow were identified by Microsoft Consulting Services (MCS) consultants worldwide. We've assembled some useful solutions, and while following them may not prevent all of the problems you'll encounter, you will significantly reduce performance degradation.
Misunderstanding the Relationship between Performance and Scalability
Performance and scalability are not the same, but neither are they at odds. For example, an application may process information at an incredibly fast rate as long as the number of users sending it information is less than 100. When that application reaches the point at which 10,000 users are simultaneously providing input, the performance may degrade substantially, because scalability wasn't high enough in the list of considerations during the development cycle. On the other hand, that same high-performance application may be partially rewritten in a subsequent iteration and have no problem handling 100,000 customers at one time. By then, however, a substantial number of customers may have migrated to a product someone else got right the first time.
Sometimes applications seek scalability in terms of number of concurrent users strictly through performance, with the idea being that the faster a server application runs, the more users can be supported on a single server. The problem with this approach is that increasing the number of simultaneous users may create a bottleneck that will actually reduce the level of performance as the load increases. One cause of this kind of behavior is caching state and data in the middle tier. By avoiding such caching in the design phase of the development process, countless hours of backtracking and rewriting code can be avoided. The ideal is to find a point of balance that provides acceptable performance in a scalable implementation of a particular application. Finding this point always involves trade-offs.
Let's look at some of the basic concepts involved in scalability. Throughput refers to the amount of work (number of transactions) an application can perform in a measured period of time and is often calculated in transactions per second (tps). Scalability refers to the amount of change in linear throughput that occurs when resources are either increased or decreased. It is what allows an application to support anywhere from a handful to thousands of users, by simply adding or subtracting resources as necessary to "scale" the application. Finally, transaction time refers to the amount of time needed to acquire the necessary resources, plus the amount of time the transaction takes actually using these resources.
The point to note here is that scalability increases as throughput increases; that is, the higher the throughput growth per resource, the greater the scalability. Clearly, application developers must concentrate their efforts on increasing throughput growth if they are to increase scalability. Of course, the obvious question then becomes, how exactly does one go about increasing throughput? The answer to that question may sound reasonably simple: Reduce the overall growth of transaction times. But just how easy might that be?
Transaction times can be extended by a variety of factors. Acquiring the necessary resources can be slowed by such factors as network latency, disk access speed, database locking scheme, and resource contention. Added to that are elements that can affect resource usage time, such as network latency, user input, and sheer volume of work. Windows DNA application developers should concentrate on keeping resource acquisition and resource usage times as low as possible. Frank Redmond lists the following ways to manage some of these factors:
Â¢ Avoid involving user interaction as part of a transaction.
Â¢ Avoid network interaction as part of a transaction.
Â¢ Acquire resources late and release them early.
Â¢ Make more resources available. Otherwise, use MTS to pool resources that are in short supply or are expensive to create.
Â¢ Use MTS to share resources between users because it is usually more expensive to create a new resource than to reuse an existing one.
Eliminating the confusion that exists about the relationship of performance and scalability, in this context, primarily means remembering that running a high-performance application is not the only consideration for gaining an acceptable level of performance in a Windows DNA application. It must be scalable so that the largest number of simultaneous users can be logged on without compromising throughput to an unacceptable level.
Mistakes in the Middle Tier
The next three performance mistakes relate directly to middle tiers in the Windows DNA application. A middle tier in an n-tier application is necessarily complex because of the role it plays in the overall application. The specific tasks it performs can be separated into three general categories that are essential to Windows DNA applications.
The first task involves receiving input from the presentation tier. This input can be done programmatically or may come directly from a user. It may include information about (or a request for) almost anything. Second, a middle tier is responsible for interacting with the data services to perform the business operations that the application was designed to automate. For example, this might include sorting and combining information from different mailing lists to target a specific audience that was never previously considered to be a cohesive group. Finally, a middle tier returns processed information to the presentation tier so it can be used however the program or user sees fit. Within these three areas, performance can degrade significantly when developers use programming practices that are either little understood or mistakenly embraced as the "right" thing to do. These performance-compromising mistakes are explained more fully in the following sections.
Instantiating Deep and Complex Object Hierarchies in a Middle Tier
Development teams sometimes adopt complex sets of classes as part of a quest for object-oriented purity. In other cases, large numbers of simple objects are instantiated to model complex interactions through delegation. The practice of instantiating large numbers of objects and causing each to interact with the data store (to populate and persist itself) yields less scalable applications. Simply put, designing for the middle tier is not the same as designing for a traditional object-oriented fat-client application. The memory allocation associated with creating objects can be costly, and freeing memory can be even more so, because of the general practice of attempting to coalesce adjacent free blocks into larger blocks.
Performing Data-Centric Work in a Middle Tier
Developers sometimes fall into the trap of including data-centered tasks with the business services work in a middle tier instead of the data-services tier where they belong. Rules are frequently too rigid to account for all cases but it would be very unusual to find a justification for breaking this one. If data-centered tasks are included in a middle tier, your Windows DNA application is likely to perform more poorly than it would otherwise.
For example, it would be a mistake to retrieve multiple data sets from different tables and then join, sort, or search the data in middle-tier objects. The database is designed to handle this kind of activity and removing it to a middle tier is almost certainly a bad practice. True, there may be circumstances where doing so is called for because of the nature of the data store, but as much of this as possible should happen in the database before the dataset is returned to the middle tier.
Maintaining a Stateful Middle Tier
Most developers have heard that maintaining state in MTS/COM+ components is a bad thing to do, but a surprising number of projects still attempt it. Sometimes this happens with the hope that performance won't degrade to a significant degree. On the other hand, it is sometimes said that you can't use stateful components in MTS and that, of course, is not true. However, to achieve scalability and performance, you shouldn't use stateful components.
Specific issues exist with using the Session and Application objects to store state of any kind. Not the least of these issues is the current inability to scale such objects across multiple servers. This becomes especially problematic (even in single-server deployments) when one attempts to cache object instances, such as database connections in Session or Application objects.
Let's say you're using Microsoft's ActiveX Data Objects (ADO). If you store your ADO objects in Session variables, you'll introduce both scalability limitations and threading considerations. By storing a connection object this way, you lose the benefit of connection pooling. In terms of performance, doing this ensures that the connection object will only serve the user for which a given session is created, and the connection will not be released to the pool until the end of the session. Beyond that length of time, you must also take into account the default timeout assigned to a session variable. Session resources for each user are consumed for 20 minutes of idle time before being released. You can reduce this length of time either manually or programmatically, but you risk creating additional difficulties.
Instead of storing the object in a Session variable you need to, in effect, create it and destroy it in every applicable ASP page. Thanks to MTS and COM+, this doesn't involve the overhead normally associated with object creation and destruction. By using a technique known as interception, the MTS run time inserts a transparent layer called a context wrapper between a base client and an object in the MTS run-time environment. The MTS run time is then able to monitor the connection and take control on a call-by-call basis. MTS requires the use of the SafeRef method but this is not necessary in COM+ (Windows 2000 and later), because Contexts have replaced the MTS concept of context wrappers.
Poorly Tuning Your Database
Even with the ever-increasing processor power available for database servers, poorly tuned indexes and queries can bring an otherwise robust system to its knees. It is quite common to see developers coding stored procedures or queries without consulting the database administrator (DBA), or even running a project with no DBA involvement. Similarly, the table designâ€including the data types of keys, the degree of normalization or denormalization, and certainly the index structureâ€plays a critical role in the performance of the overall system. Some of these factors can be "designed in", but others, such as the index and normalization strategies, should be implemented as a "best guess" and then carefully tuned through load testing.In general, not using the database efficiently (making multiple queries when one stored procedure call would do, getting data one row at a time, explicitly locking data when it isn't necessary to do so) can be a ready source of problems. These can be solved by bringing developer attention to them before code is written.
Making Poor Algorithm Choices
With the schedule pressures that beset many projects, developers often implement the first algorithm that comes to mind to solve a particular problem. In addition to introducing common bugs into implementations (as in initializing variables inside a loop), developers may fail to take into account the load characteristics of the algorithms they choose. Careful planning during the early stages of the development process can prevent this problem. As in most software engineering situations, this is usually the least costly solution. If poor choices are inadvertently made, discovering the problem early through selective testing can minimize the damage.
Failing to discover poor performance until late in the project's development cycle is rarely an effective idea.
FEATURES AND ADVANTAGES OF WINDOWS DNA
Â¢ DNA helps to design and build multi-tier client/server applications. It provides a structured approach to creating applications whose components are clearly separated into distinct functional groups, with common communication protocols linking these groups. This provides the benefits of faster and less error-prone design and development, and interchangeability of components.
Â¢ DNA provides client transparency. The front-end (or client) is independent of the back end of the application, i.e. it needs no knowledge of this, irrespective of what, the back end of the application does, or how it does it. As long as it follows the DNA protocol and processing guidelines, it can be almost anythingâ€from a standard Web browser to a specially developed application written in almost any programming language.
Â¢ DNA applications provide full transactional processing support. In applications of any real level of complexity, multiple operations are performed at different levels of the application, and at different times. To guarantee integrity of the results, there needs to be control over each set of operations as a whole, as well as monitoring of every individual step. DNA, and the associated software plumbing components, can accomplish this almost transparently and seamlessly.
Â¢ DNA can be used to create applications that are fault tolerant. As no network can ever be 100% guaranteed to give continuous and fast performance. A distributed application needs to be able to cope with network delays and software failures, while protecting data integrity and providing high availability and reliability.
Â¢ DNA is ideal for distributed applications. Once an application becomes distributed, i.e. divided into separate parts linked by a network, the problem of communication between the parts arises. Earlier it was necessary to create custom formats and techniques for passing information between each part of the application, leading to longer design and implementation periods, an increased number of bugs, and poor interoperability between different applications. By standardizing the communication protocols and interfaces, development speed and application reliability is boosted.
The DNA methodology covers many existing technologies to help design and implement robust, distributed applications. It visualizes this whole application as a series of tiers, with the client at the top and the data store at the bottom. The core of DNA is the use of business objects in a middle tier of the application.
Also, in DNA, business objects are implemented as software components. These components can be accessed by the client interface application or by another component, and can themselves call on other components, data stores, etc. Componentization of business rules brings many benefits, such as easier maintenance, encapsulation of the rules, protection of intellectual copyright, etc.
Hence, DNA is an approach to design that can speed up overall development time, while creating more reliable and fault tolerant applications that are easily distributable over a whole variety of networks.
To run these applications, Windows DNA relies on a rich set of integrated services supplied by the Windows platform. These services are infrastructure technologies that would be required for any scalable, distributed application -- for instance, transaction processing, security, directory services and systems management.
By providing a stable base of common services, Windows DNA relieves developers from the burden of creating their own infrastructure and allows them to focus instead on delivering business solutions. Developers save time, reduce costs, get their applications to market more quickly and equip companies for responding proactively to changing business conditions. These benefits are especially compelling in today's competitive business climate.
Several more good reasons why companies should base their applications on Windows DNA. Because the architecture is built on open protocols and industry standards, solutions from other vendors integrate easily into the environment. This helps ensure interoperability with mission-critical business applications, such as corporate databases and enterprise resource planning systems. An open approach also facilitates compatibility with existing computing systems, which means that companies can continue to take advantage of their legacy systems as opposed to replacing them.
The benefits of distributed computing applications that embrace Internet technologies are many. For individuals, it means the freedom to communicate or access information at any time and from any place. For businesses, it means making more informed decisions, better understanding their customers, and responding quickly as their business needs evolve. For software developers, the challenge has been how to build these solutions. Windows DNA offers them a cohesive and proven application architecture for distributed and Internet-based computing solutions.
The Windows DNA architecture and the Windows NT platform offer many distinct advantages to customers and their ISV partners. Its key benefits include:
Â¢ Providing a comprehensive and integrated platform for distributed applications, freeing developers from the burden of building the required infrastructure or assembling it using a piecemeal approach.
Â¢ Easy interoperability with existing enterprise applications and legacy systems to extend current investments.
Â¢ Making it faster and easier to build distributed applications by providing a pervasive component model, extensive prebuilt application services, and a wide choice of programming language and tools support.
Windows DNA applications have proven themselves in a wide range of circumstances, and the value they represent in the modern distributed computing environment has been thoroughly demonstrated. They have, however, also shown themselves to require careful planning and thorough testing throughout the development process. Avoiding the kinds of mistakes noted in this article should reduce the amount of resources required to produce the kind of Windows DNA application you want. Performance and load testing is unavoidable. Do it in a manner that simulates real-world conditions for your particular application, and you'll be rewarded with an n-tier application that works and works well.
Â¢ INTRODUCTION 1
Â¢ MICROSOFT WINDOWS DISRTIBUTEDINTERNET APPLICATION 7
Â¢ TOP WINDOWS DNA PERFORMANCE MISTAKES and
HOW TO PREVENT THEM 26
Â¢ FEATURES AND ADVANTAGES OF WINDOWS DNA 32
Â¢ CONCLUSION 35
Â¢ REFERENCES 36
I express my sincere thanks to Prof. M.N Agnisarman Namboothiri (Head of the Department, Computer Science and Engineering, MESCE), Mr. Sminesh (Staff incharge) for their kind co-operation for presenting the seminars.
I also extend my sincere thanks to all other members of the faculty of Computer Science and Engineering Department and my friends for their co-operation and encouragement.