Windows DNA Architecture

The Microsoft approach to writing distributed applications is called the Windows Distributed interNet Applications (DNA) architecture. Windows DNA is a framework for building three-tier, component-based applications that can be delivered over any network. The goal of Windows DNA is to unify PC, client/server, and Web-based applications around this common application architecture, which is suitable for applications of any size.

Windows DNA is not a product; it's a strategy—a road map, if you will, to writing applications using Microsoft technologies and products. Microsoft's goal is to provide the platform, component technology, application infrastructure, interoperability services, and tools developers need to write all three tiers of their applications, as shown in Figure 1-4.

click to view at full size.

Figure 1-4. Windows DNA architecture.

The Component Object Model

The heart of Windows DNA is an integrated programming model based on the Component Object Model (COM) and Internet standards. All services are exposed to applications via published COM interfaces. Windows DNA services also adhere to open protocols such as Hypertext Transfer Protocol (HTTP) and Lightweight Directory Access Protocol (LDAP) to provide interoperability with other systems.

COM is a language-independent, system-level object model that provides a standard way for components and applications to interoperate. Thus, developers can use any language or tool to create applications. Developers create COM components that expose one or more interfaces. Each interface provides a set of methods and properties that can be accessed by other components or applications. Many developer tools provide support for writing and using COM components—for example, Microsoft Visual Studio, PowerBuilder, and Delphi.

Distributed COM (DCOM) extends COM across machine boundaries, providing remote invocation of COM components in a location-transparent manner. Location transparency enables a client application to function consistently, regardless of whether the components it uses are located locally on the client machine or remotely on a separate machine. DCOM supports a variety of network protocols, including Transport Control Protocol/Internet Protocol (TCP/IP), User Datagram Protocol/Internet Protocol (UDP/IP), and Internet Tunneling TCP/IP protocol, and is available on a number of non-Windows platforms to help integrate Windows DNA applications with existing systems.

We will examine COM and DCOM in more detail in Chapter 2.

The Presentation Layer

Windows DNA builds a rich, highly integrated application environment on top of Windows operating system services and COM. This environment extends across all three tiers of the distributed application. In the presentation layer, Windows DNA supports a wide variety of client devices, from handheld PCs to high-end workstations. Microsoft products and technologies support a range of user interface types, from vanilla HTML, to Dynamic HTML (DHTML), to native Win32 applications. The key to supporting this diverse set of hardware and user interface styles is a common component model, scripting environment, and other client infrastructure services.

For Web-based clients, Microsoft provides Internet Explorer. Internet Explorer is an integral part of Windows 95 and later and Microsoft Windows NT 4.0 and later, and it is also available for Microsoft Windows 3.1, Macintosh, and UNIX platforms. Internet Explorer supports HTML, DHTML, client-side scripting, Java applets, Netscape plug-ins, and Microsoft ActiveX Controls. These languages and components can be used to create a rich, interactive user interface. Internet Explorer is itself component-based. The browser is actually a thin container for Microsoft's HTML rendering component. This component can easily be used in other applications, giving them access to a wide array of Internet services.

Perhaps one of the most interesting features of Internet Explorer is its support for DHTML. DHTML is an open, language-independent object model for HTML. Using DHTML and client-side scripting, developers can write interactive, platform-independent user interfaces that don't require developing custom components. All Web page elements are exposed as programmable objects. Thus, client-side script can be used to change the style, content, and structure of a Web page without refreshing the page from the server. This capability can have a dramatic impact on application performance by reducing network traffic.

We will look briefly at designing and coding both Web and native user interface applications, but this book does not discuss the Win32 API, HTML, or DHTML in detail. For more information about these topics, please see the references listed in the bibliography.

The Business Layer

To help developers write scalable component-based business logic, Windows DNA includes a powerful set of integrated application services, or middleware, that takes care of the "plumbing" in a three-tier application. These services are tightly integrated with each other and the underlying operating system and are exposed in a unified way through COM. They include the following:

  • Web services, through Microsoft Internet Information Server (IIS)

  • Transaction and component services, through Microsoft Transaction Server (MTS)

  • Queuing and asynchronous services, through Microsoft Message Queue Server (MSMQ)

  • Server-side scripting, via Active Server Pages (ASP) hosted by IIS

  • Interoperability services, such as the COM Transaction Integrator (COMTI) for accessing the IBM Customer Information Control System (CICS) and IBM Information Management Systems (IMS)

MTS is a high-performance execution environment for server-side components, as well as a distributed transaction manager. MTS promotes a radically simplified programming model for the middle tier of the three-tier architecture. MTS provides automatic services such as thread pooling, multiuser synchronization, instance management, scaling, fail-over, and database connection management, enabling developers to focus on writing the business logic specific to their applications. Developers can write server-side COM components encapsulating their business logic as if the components will be used by a single user. When these components are run within the MTS execution environment, they automatically scale to support large numbers of concurrent users.

In addition, MTS provides automatic transaction services. Developers can set an attribute on a component to indicate the level of transaction support required. MTS will automatically create transactions, enlist resources, and manage the transactions. Developers need to make only one function call to let MTS know whether their component has successfully completed its work. Transaction management works for a wide array of resources, including Microsoft SQL Server, MSMQ, Oracle, and IBM DB2.

We will look at MTS in more detail in Chapter 4.

IIS 4.0 provides key services for server-side Web applications. IIS is integrated with MTS and uses MTS for many run-time services, including transaction management, connection pooling, and process isolation for Web applications.

One of the key features IIS provides for Windows DNA is ASP. ASP provides a server-side scripting environment that makes it easy to create and run dynamic Web applications. Server-side scripts can generate customized HTML pages on the fly. Like client-side scripts, ASP can use COM components to extend the functionality of a Web application. These COM components can run within the MTS environment. ASP can be scripted in any language that has an Active Scripting engine; IIS includes native support for VBScript and JScript. ASP is a powerful bridge between the presentation layer and the business layer for Web-based applications.

We will look at ASP in more detail in Chapter 5.

MSMQ provides asynchronous services for distributed applications. MSMQ provides reliable store-and-forward delivery of messages between applications and components over the network. Message queuing guarantees that messages will eventually be delivered even if network links are down, receiving applications are off line, or machines fail. This capability is useful for scenarios in which guaranteed delivery is more critical than immediate delivery. For example, in an order-entry application, it's important that orders get scheduled for shipment eventually. However, it's not critical that the shipment be scheduled while a customer is on the phone with an order-entry operator. MSMQ is interoperable with IBM MQSeries and other message queuing environments through products from Level 8 Systems.

We will look at MSMQ in more detail in Chapter 6.

Finally, Microsoft supports a range of interoperability services. Many services are based on open protocols or published interfaces that permit direct interaction with existing mainframe and UNIX systems. In addition, Microsoft provides products such as COMTI.

COMTI enables Windows DNA applications to transparently integrate with code running on IBM mainframes under the control of CICS and IMS. COMTI provides a set of developer tools and run-time services to automate "wrapping" mainframe transactions and business logic as COM components. The COM components run on a Windows NT machine and talk to the mainframe via Microsoft Systems Network Architecture (SNA) Server.

We will look at COMTI in more detail in Chapter 6.

The Data Access Layer

In addition to the wide array of services for the presentation and business layers, Windows DNA encompasses technologies for accessing data. The Windows DNA approach to data access is called Universal Data Access (UDA). UDA is a COM-based framework based on open industry standards.

Rather than requiring all data to be stored in a common data store, UDA provides a common programmatic interface to virtually any type of store, whether for structured or unstructured data. Most applications require access to multiple types of stores; UDA simplifies the development of these applications by reducing the number of APIs developers must learn in order to access their data.

At its core, UDA specifies system-level interfaces called OLE DB. Data providers implement OLE DB interfaces to provide access to specific data stores, such as Microsoft SQL Server and Microsoft Exchange. OLE DB service providers build independent services such as query processors and content indexers that work across all data providers. UDA also specifies an application-level programming interface called ActiveX Data Objects (ADO) that uses OLE DB to access data but presents a simpler programming model to the developer. ADO is an evolution of earlier Microsoft data object models such as Data Access Objects (DAO) and Remote Data Objects (RDO). Developers can use ADO to easily create data access components for their business components that retrieve and store data across a wide variety of data stores.

We will look at UDA in more detail in Chapter 3.

Designing Component-Based Applications
Designing Component-Based Applications
ISBN: 0735605238
EAN: 2147483647
Year: 1997
Pages: 98
Authors: Mary Kirtland
BUY ON AMAZON © 2008-2017.
If you may any questions please contact us: