Net2000 Smart Components
Articles and Tips: article
Software Engineer
Net2000 Product Development
01 Mar 1996
"Smart Components" is Novell's project to provide an operating environment for distributed components. Net2000 Smart Components are an integral part of the "Smart Global Net" and enable users to access needed information via a distributed object system. Three parts make up the Smart Component Architecture: the Interface Adapter, the Component Core Object(s), and the Component Management Services. At its heart, Smart Components is a powerful application of exploiting NetWare Directory Services. In addition, NDS provides a global registry for platforms where a registry is missing.
Introduction
"Smart Components" is Novell's project to provide an operating environment for distributed components. This operating environment provides a framework where software, encapsulated as components, can be located and run in a distributed manner anywhere within the NDS tree. Novell, using NDS as a key technology, is able to create a network wide system that supplies the infrastructure to allow for components to act as distributed objects. Components that are network distributable, managed, and object-oriented add excellent capability to today's business environment.
Component consumer products - like Visual Basic, Delphi, and PowerBuilder - support native interface object models. OLE Controls and Automation are examples of a native interface model using COM on Windows . Using this native support, Net2000 components function to expose back-end networking services. We refer to this capability as "Smart Net Components." These Smart Net Components perform intelligent access to the "net." They run directly or via component proxies on the desktop to connect to networking services. Net2000 Smart Components are an integral part of the "Smart Global Net." They enable users to get access to the information they need via a distributed object system. At their core, Net2000 Smart Components render a distributed object solution.
This DevNote addresses the architecture of the Net2000 Smart Components. The Smart Components project has two main goals:
Provide a structure for distributed components
Provide services where components can communicate and be integrated.
The Net2000 Smart Component initiative is both a distributed component architecture and a set of deliverable components which expose networking services using this architecture. Fundamental to the component architecture design is the easy addition and support of third-party components.
At his heart, Smart Components is a powerful application of exploiting NetWare Directory Services. Without NDS, Smart Components, as a technology, would not exist. This new component environment uses NDS instead of the Windows registry. Additionally, NDS provides a global registry for platforms where a registry is missing. The NDS registry is used as a repository to store both the component interface information and the component implementation information.
Architecture
Three parts make up the Smart Component Architecture:
the Interface Adapter
the Component Core Object(s)
the Component Management Services
The parts of the Smart Component Architecture are shown in Figure 1. These three parts access the Interface Repository and the Implementation Repository. This forms the main plumbing needed for a distributed object system.
Figure 1: Main parts of the Smart Components Distributed Object System.
Distributed components are packaged as independent pieces of code that can be accessed by remote clients using marshalled method invocations. The Interface Adapter and the Components Management Services work in tandem to do just that: distribute objects as shown in Figure 2.
These two fundamental parts supply the environment for managing objects (environment instantiation), advertising their presence, and describing their metadata (interfaces). Stated another way, these two parts mediate interactions between client application that need services and server objects capable of providing them. These server objects may be anywhere on the network system including being local to the client machine. The Component Management Service finds, loads, and creates proxy/stubs.
In conjunction with the Component Management Services, the Interface Adapter steps in to federate the interfaces thus providing access to the native object-speak format of the client platform. This federation capability allows a client to transparently invoke a method on a server object in a very distributed way. The server object can be local or anywhere in the network.
Figure 2: Smart Components: Software Architecture.
Novell networking services (file, print, NDS, telephony, E-mail) are abstracted into objects implemented as component cores. These objects are then exposed by the Interface Adapter as shown in Figure 1.
Interface Adapter
The Interface Adapter exists to provide "object-speak" formatting and interface type library storage. The Interface Adapter uses the technologies of NDS and component shell generation tools to implement an Interface Repository. Figure 3 depicts the need for the Interface Adapter to supply object interfaces for various component definitions. The Interface Repository supplies the plumbing for both static and dynamic component interface binding. The Interface Adapter exists to supply heterogenous object interfaces.
The global network will always remain heterogenous in a competitive and evolving world. The challenge for the Interface Adapter is to present a homogeneous component access to heterogenous platform components. The key technology is implementing as an interface type library using NDS. Using this approach, a global interface access is provided. An important note is that all components can only be manipulated via its interfaces. The Interface Adapter's job, then, is to provide global and universal component interface compatibility access.
Figure 3: Component interfaces.
Object-Speak Formatting
Multiple programming languages occur on a given platform. Even though there can be many heterogenous programming languages on a given platform, there generally is one accepted object interface model. The object interface model is generally defined by the supplier of the Operating System. Examples of this are COM on Windows and SOM on OS/2. Novell's Interface Adapter, when implemented on a given platform, will supply the object interfaces in the model that is native to that platform as its default object interface.
When a Visual Basic application wishes to access a component it uses OLE Automation Interfaces. These interfaces are based on COM "object-speak" mechanisms. COM, then, defines a binary access protocol that glues software together. But what if I want to access the component from Visual Basic using OLE Control Interfaces? OLE Control Interfaces include all the OLE Automation interfaces (see Figure 4). However, there are additional interfaces required for controls than those required for OLE automation.
Let's assume that the component only supplies OLE automation interfaces natively. In this case, the interface channel would supply default OLE Control Interfaces in order that this OLE Automation component could be consumed as an OLE Control. In addition the Delphi product from Borland desires to consume components that are contained in its VCL library. The Interface Adapter also supplies OLE automation and OLE Controls that are specified in the Interface Repository as plug-ins to the Delphi Component Pallet.
Figure 4: Component objects.
Interface Type Library Storage Using NDS
In order to provide runtime dynamic binding of object interfaces, a component consumer requires the ability to request from the component environment information about available component methods and their parameters. On many platforms, like Windows , this information is stored in type libraries. The Windows registry serves as a means for locating a type library. The availability of this information when store on a client machine is limited only the local machine environment.
To be useful in a distributed object system, type libraries must be supported by a NDS like technology. The Interface Adapter environment uses NDS to store a component's methods and parameter information. Thus, providing a global network access to interface information. In the Smart Component Environment, NDS will then be used to store both a component's interfaces and a component's instantiation information. Component interfaces and Component Instantiation Information are stored in the Interface Repository and Implementation Repository respectively. Component instantiation is discussed later on in this DevNote in the "Component Management" section.
Component Shell Generation Tools
By using a component shell generation tool, a developer of the core component object is shielded from knowing about component interfaces. This generation tool acts much like a component coach. This tool uses interface definitions written in IDL as input. The output from the tool is a software component shell that defines component interfaces. The component developer then uses this shell to complete the component object core.
Component Plug-in Technology
As discussed earlier, many of the desktop component consumer products have the concept of a "component pallet." A component pallet is a library reference set of available components that can be placed on forms and in applications. Net2000 will provide tools to insert components defined in the Net2000 distributed component registry (Implementation Registry) to be available natively in these "component pallets." This is done by generating component snap-in libraries off of the NDS component registry.
Direct Support for Component Management Services
A requirement for the Net2000 Architecture is to insulate a component container (consumer) from having to include support for component management. The Interface Adapter and the Component Management Services work together to supply complete transparent access and instantiation.
Component Management
NDS is used to store component information. The use of the Windows Registry is replaced by NDS. Novell has an extensible directory service capable of supporting the management of a distributed components environment. Management of component retrieval has to occur in a global network. A component class ID when registered in NDS, in effect, publishes the availability of this component to all connected platform clients.
The Component Management Service responds to instantiation requests by a component consumer (clients) by loading and creating a component instantiation. Via the Interface Adapter functionality, the component interfaces are then returned to the requester. Functionality for licensing, authentication, authorization, and metering of a component is also supplied by this component management infrastructure.
Domain federation and distribution in heterogenous environments are handled by the Component Management Services. Domain federation refers to the capacity to supply components for heterogenous platforms. For example, using NDS when requesting component instantiation, the Component Management Service piece selects the component binary which matches the execution platform.
NDS is essentially used to store component references to all matching components written for specific platforms. From the component reference information, the correct component can be loaded. The distribution part of this capability allows for proxy and stubs to be created so that a component can be distributed in the network exposed to remote component consumers. Writing components in JAVA can lead to heterogenous platform execution.
Component Core Objects
The motive for providing Smart Components is centered in the need to expose Novell networking services. The Smart Component operating environment is being created to render support for the external use of networking services at the client platform. The core of a component is created as an object with well-defined behavior (code) and state (data).
This encapsulated core provides an abstracted object of a traditional low level NetWare API. These components now provide useful services at a high enough level of abstraction to be consumed by component-consumer products such as VB and Delphi. The Interface Adapter acts as "object-speak" functionality to wrap the core object into meaningful OCX and OLE automation interfaces.
Third-parties may also develop components that use the Interface Adapter and Component Management Service capabilities to expose their functionality to component consumer products.
This concludes an overview of the Net2000 Smart Components Architecture. Novell is uniquely positioned to provide a distributed components system. The strengths of NDS and networking technologies supplies the foundation upon which a distributed object system can be built.
* Originally published in Novell AppNotes
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.