With the growing use of the Internet, organizations are looking at developing and deploying applications that run in a Web environment. Web applications are inherently n-tier, or distributed. An n-tier application separates the application into three distinct components:
Presentation – The piece of the application that a user interacts with.
Application Logic – The piece of the application containing all of the business rules and logic associated with the application.
Data – The mechanism that stores and manages the data associated with the application, which is usually a relational database.
The benefits of authoring to a three-tiered model are many. Partitioning applications cleanly into presentation, business logic, and data layers enhances scalability, reusability, security, and manageability. Designers of distributed applications need to be able to deploy and reuse objects anywhere in a network without sacrificing security, scalability, or manageability. To this end, three standards have emerged as the basis for providing distributed component models – the Component Object Model (COM), the Common Object Request Broker Architecture (CORBA), and Enterprise JavaBeans (EJB).
To meet the challenges of today’s application developers, a network operating system must provide a robust, integrated, distributed component model conforming to at least one of the three major standards. Distributed component object model implementations should meet the following technical requirements:
Language Independence – Allows developers to author components in all popular programming languages.
Binary Standard Adherence – Guarantees compatibility with other implementations of the same object model.
Component Services – Provides a complete component object model on which component-based distributed applications can be built. Key features include transaction services to ensure data reliability, and a component manager, in which parameters such as security identification and process isolation can be configured.
The Solaris 7 distributed application model is based on CORBA/IIOP, Java Beans and the Enterprise Java Beans technology. The CORBA architecture is designed to allow platform-independent interoperability between objects in a distributed network environment. In this open environment, objects can discover each other and invoke services on each other via an Object Request Broker (ORB), regardless of location, implementation language, or platform.
The APIs and underlying communications protocol supported by the ORB conform to the CORBA and Internet Inter-ORB Protocol (IIOP). Therefore, ORB-based applications are portable and can interoperate with other CORBA-conforming implementations in heterogeneous network environments. Theoretically, this functionality and interoperability will work properly when communicating between CORBA/IIOP implementations.
CORBA-applications written on the Solaris 7 platform can fully interface with other CORBA applications running on other platforms and written in other languages via CORBA’s IIOP protocol. CORBA applications on Solaris 7 are developed entirely in Java using the Interface Definition Language (IDL) as defined in the official OMG CORBA specification. Unfortunately, while Java language and IDL support is provided, Solaris 7 doesn’t include an ORB and it doesn’t include Java Beans or Enterprise Java Beans technology. This means you must purchase and/or install these components before you can create distributed applications on Solaris 7.
Windows NT Server 4.0 Implementation Details
Windows NT Server 4.0 ships with a complete, operating system-integrated implementation of the Component Object Model (COM). Introduced in the Windows operating system in 1993, COM is one of the most mature foundations for component-based applications. The key principles of COM can be summarized as follows:
Location Transparent – Every COM component can be called with a process, across processes on a single computer, or across multiple computers without being recompiled.
Language-neutral – Any popular language can be used to author COM components. On the Windows platform, support extends to Visual Basic®, C++, and Java. Developers authoring solutions in one language can easily use components written in other languages.
Discoverable Interfaces (DI) – DI provides tools and other applications to discover the interfaces and parameters that are supported by the component, making it easy for developers to understand how to work with enterprise applications.
Distributed COM (DCOM), introduced in 1996, makes it possible to create networked applications built from components. With DCOM, developers can easily call and interoperate with components and applications running on other COM-capable systems over a network.
Beyond providing core support within the operating system, Windows NT Server 4.0 also provides an enhanced set of services for COM applications and developers. These services are included as the Microsoft Transaction Server (MTS) 2.0 in the Windows NT Option Pack. In a nutshell, MTS integrates COM components with transactions, providing a robust solution for developing enterprise-level, COM-derived applications. It also provides many important infrastructure pieces including the ability to graphically manage components and configure such settings as component security identification and process isolation. It is one of the most complete infrastructures available today on which to build distributed, component-based applications.
Functionality and benefits provided by MTS can be summarized as follows:
Automatic Transactions allow configuring a component’s transactional requirements when a component is deployed. The result is greater reliability and the potential reuse of business objects built as MTS components.
Configurable Security allows a system administrator to define roles, then specify which interfaces and components can be accessed by clients in each role, greatly simplifying the work required to create secure server applications.
Database Connection Pooling allows components to reuse existing connections to a database rather than recreating new ones, simultaneously improving performance and scalability.
Automatic Thread Support allows developers to write single-threaded components and then let MTS assign threads to those components as needed.
Component State Management provides the Shared Property Manager (SPM) to allow components to store and then later retrieve their in-memory state after a component has given up its memory state at the end of a transaction. This provides greater flexibility in the types of COM applications that can be produced.
Process Isolation allows individual COM applications to be grouped into one or more packages. Each package can then be run in its own process. This allows greater fault tolerance since the failure of a single component will only bring down the package of which the component is a member.
Windows 2000 Server Implementation Details
Windows 2000 Server enhances the COM and MTS implementation in Windows NT Server 4.0. It introduces COM+, an evolution of the technologies in Windows NT Server 4.0 and MTS 2.0. New features and benefits can be summarized as follows:
In Memory Database (IMDB) provides an application with fast access to data, without incurring the overhead with storing and accessing durable state to and from physical disk. This allows frequently used data to be cached in memory and it provides a means for high-speed, low-overhead access, increasing the performance of data-driven COM applications.
Queued Components (QC) allow clients to invoke methods on COM components using an asynchronous model. This provides many benefits to developers authoring applications intended to run on unreliable networks and in disconnected usage scenarios.
Dynamic Load Balancing automatically spreads client requests across multiple equivalent COM components. This allows load to be distributed between multiple systems, increasing performance and scalability of COM applications.
COM+ Events provides a publish-and-subscribe event service. Via a general event mechanism, multiple clients can “subscribe” to various “published” events. When the publishing application fires an event, the COM+ Events system iterates through the subscription database and notifies all subscribers. This allows more code reuse and lowers development costs. Programmers do not need to constantly modify code to take action when certain criteria (events) are met.
MTS Integration has been implemented to fully tie together enhanced functionality in MTS with the core component services infrastructure in the operating system. Several improvements in functionality include broader support for attribute-based programming and integration with other transaction environments with support for the Transaction Internet Protocol (TIP).
Distributed Applications Model Summary
Windows 2000 Server is a strong choice for customers to build and deploy distributed component-based applications. The advanced features in COM+ -- Dynamic Load balancing, Queued Components, COM+ Events, and In-Memory Database -- provide unmatched ease of development, performance, flexibility, and scalability. on
Windows NT Server 4.0 is second only to Windows 2000 Server. It lacks equivalent functionality to the COM+ support. But the combination of COM as the distributed component model and Microsoft Transaction Server 2.0 provides a potent platform on which to develop enterprise applications. It has key benefits such as automatic transaction support, configurable security, database connection pooling, automatic thread support, state management, process isolation, and legacy host integration. These provide many essential features for developing component-based line-of-business applications that are simply not found in Solaris 7. In addition, it provides complete language neutrality, allowing developers to use their language of preference to deploy COM-based applications. This is in stark contrast to the Java-only CORBA implementation in Solaris 7.
Solaris 7 provides only limited support for the distributed application model through its support of Java and IDL. To create distributed applications, key components must be installed. A third party ORB is needed to handle requests between distributed objects. Java Beans or Enterprise Java Beans technology must also be installed to complete the distributed architecture.