|
||
|
|
DataSheet COMsource Overview Client/Server Please Note: “COMsource for Solaris, Tru64 UNIX and other Platforms” is referred to as “COMsource” throughout the rest of this document. The Open Group’s COMsource provides an object-based, distributed, programming model designed to promote software interoperability. It is an open systems implementation of the Component Object Model (COM) middleware developed by Microsoftâ for the Windowsâ platform. COMsource provides all the basic functions, libraries and tools that a COM application requires. With COMsource, independent software vendors can easily port their COM applications to non-Microsoft platforms. COM implements a binary standard that allows two or more applications or "components" to work together regardless of whether they were written by different vendors, in different languages, at different times, on different platforms running different operating systems. DCOM, the Distributed Component Object Model, extends the COM model and provides applications with a way to interact remotely over a network. Using this programming model, a C++, Visual C, Visual Basicâ, or Java programmer encapsulates their application into software component objects. A component object is a reusable piece of binary code, written to the standard interfaces defined by COM, that can connect with other component objects also written to these standard interfaces. Thus, a programmer can write an application once and make its capabilities available to other applications. With DCOM, the programmer’s client application can be used by other applications on remote servers. COMsource Benefits COMsource provides the infrastructure necessary to write portable, interoperable clients and servers. The infrastructure, including features such as naming (Monikers), storage (Structured Storage), client access from scripting clients, easy programming of custom applications and management tools (Automation), is complete and portable. COMsource enables you to:
COMsource Technology The COMsource technology delivered from The Open Group includes the following components:
COMsource is based on the code included in Microsoft’s NT 4.0 version, up to and including service pack 3 (excluding functionality that doesn’t map onto UNIXâ; for example, impersonation). Component Object Model The COM model is designed to promote software interoperability by allowing multiple, diverse applications to work together. To support these interoperability features, COM defines and implements mechanisms that allow applications to connect to each other as "component objects". A component object is a collection of related function (or intelligence) and the function's associated state. In other words, COM, like a traditional system service API, provides the operations through which a client of some service can connect to multiple providers of that service in a polymorphic fashion. But once a connection is established, COM drops out of the picture. COM serves to connect a client and an object, but once that connection is established, the client and object communicate directly without having to suffer overhead of being forced through a central piece of API code. A fundamental strength of the COM model is that component objects can incrementally evolve or change without the need to simultaneously evolve or change existing clients of the object. Component objects can easily continue to support the interfaces that connect with existing clients while providing new interfaces through which they communicate with new clients. Distributed Component Object Model DCOM, the distributed implementation of COM, is at the heart of the COMsource technology. COM provides a model of objects organized into classes, supporting methods organized into interfaces. To this DCOM adds:
DCOM itself is layered on top of a remote procedure call runtime, which provides reliable communication over a variety of network transports, in particular, Transmission Control Protocol (TCP) and User Datagram Protocol (UDP). Layered Interfaces Layered on top of COM, and included in COMsource, are interfaces that support the construction of object-oriented services: Service Control Manager The Service Control Manager (SCM) is the component of the COM library responsible for locating class implementations and running them. The SCM ensures that when a client request is made, the appropriate server is connected and ready to receive the request. The SCM keeps a database of class information based on the system registry that the client caches locally through the COM library. Structured Storage Library Traditional file systems face challenges when they try to efficiently store multiple kinds of objects in one document. COM provides a solution: a file system within a file. COM structured storage defines how to treat a single file as a structured collection of two types of objects that act like directories and files¾storages and streams. This scheme reduces the performance penalties and overhead associated with storing separate objects in a flat file. COM components can use storage and stream objects to organize and store persistent data so that multiple components or applications can store information in a single file. Although an application or component developer can implement the structured storage objects, COM provides a standard implementation called Compound Files, which is included COMsource. Compound Files feature the following:
Monikers Monikers provide persistent, intelligent names. Names can represent many different entities. For example, a name can represent a file, a database query, a specific range of data within a file - such as a range of spreadsheet cells or a paragraph in a document, or a piece of code on the system that can execute a particular operation. In a world where clients have to know what a name means in order to use it, those clients end up having to write specific code for each type of name causing that application to grow monolithically in size and complexity. Monikers solve this problem. In COM, the intelligence of how to work with a particular name is encapsulated inside the name itself, where the name becomes an object, called a moniker, that implements name-related interfaces. Each moniker class has its own semantics regarding the sort of object or operation it can refer to, which is entirely up to the moniker itself. While a moniker class itself implements the operations necessary to locate some general type of object or perform some general type of action, each individual moniker object maintains its own data that identifies the particular object or operation. Monikers provide the perfect model for allowing applications to integrate with new name services. For example, if there was such a thing as a DCE moniker class, it would allow DCE servers or DCE server data to be treated as objects. Monikers could provide a means for further integration of DCE services to applications based on COMsource. Automation Automation allows COM objects to expose functionality to high-level programming environments such as visual development tools. Scripting languages can make use of COM components which support automation. Automation adds the following capabilities to COM:
Uniform Data Transfer COM provides a standard mechanism for transferring structured data between components. This mechanism is the data object. By exchanging pointers to a data object, providers and users of data can manage data transfers in a uniform manner, regardless of the format of the data, the type of medium used to transfer the data, or the target device on which it is to be rendered. Persistent Objects COM objects can save their internal state when asked to do so by a client. COM defines standards through which clients can request objects to be initialized, loaded, and saved to and from a data store. It is the client's responsibility to manage the place where the object's persistent data is stored, but not the format of the data. COM objects that adhere to these standards are called persistent objects. Connectable Objects Connectable Objects provide a generic ability for objects to support the following for ‘outgoing’ interfaces:
Object Linking and Embedding While COMsource does not include the application programming interfaces (APIs) for object linking and embedding (OLE), or ActiveXâ Controls, it does provide the underlying technology upon which they (or similar technologies) can be built. Microsoft RPC The Microsoft Remote Procedure Call (MS-RPC) is an implementation of, and is interoperable with, The Open Group’s Distributed Computing Environment (DCE) RPC system. The RPC is the underlying connection mechanism that facilitates client-server communication so that a component can effectively access resources distributed across a network. Using the associated Microsoft Interface Definition Language (MIDL), programmers can create calls to components that may be located anywhere over the network. Microsoft Interface Definition Language The Microsoft Interface Definition Language (MIDL) is a language for describing interfaces. A MIDL compiler is included in COMsource that turns MIDL descriptions into proxies and stubs, which can then be loaded into clients and servers respectively. Proxies and stubs can then interact with a component of the RPC runtime so that method invocations can be transparently communicated across the network. The MIDL is compatible with, and is an extension of, the Interface Definition Language (IDL) of DCE. Registry The Registry is a database that COM components use to store and retrieve configuration and initialization data. This data is stored in opaque binary files. COMsource includes registry tools such as sermon and regsvr that allow you to modify registry contents. Windows NT Distributed Security Provider Windows NT Distributed Security Provider (also called the NT Lan Manager (NTLM) Security Provider) supports the Windows NT Distributed Security model and is the standard security provider for NT-based local networks. The NTLM SSP will allow clients and servers on the open systems platforms that support COMsource to be able to use the security features of NTLM to secure their communications with clients and servers on other machines in the network. COMsource from The Open Group The Open Group offers two portable and interoperable reference implementations on the Solaris and Tru64 UNIX operating systems, and the ability to port to other operating systems. These reference implementations include source code, an interoperability test suite and the reference documentation set. The interoperability test suite is provided to test derivative works developed from COMsource for interoperability with existing COM or COMsource reference implementations. Prior to distributing any derivative work, a statement of interoperability must be provided to The Open Group verifying that the ported product implementation has passed the interoperability test suite. COMsource ordering details can be found at: www.opengroup.org/comsource. You can also contact The Open Group’s San Francisco, CA office at (415) 374-8280; FAX: (415) 374-8293. COMsource for Solaris, Tru64 UNIX and other Platforms was produced under the auspices of The Open Group's Pre-structured Technology (PST) process for collaborative technology development, by industry partners Compaq Computer Corporation, Hewlett-Packard Company, Microsoft Corporation, Siemens AG and The Open Group. ActiveX, Microsoft, Visual Basic, Windows, and Windows NT are registered trademarks of Microsoft Corporation. UNIX is a registered trademark of The Open Group in the US and other countries. Other product and company names herein may be trademarks of their respective owners. |
