Novell is now a part of Micro Focus

Open Solutions Architecture Technical Overview

Articles and Tips: article

ART NEVAREZ
Chief Architect
Java Technologies Group

01 Mar 1998


Introduction

Open Solutions Architecture (OSA) consists of three significant initiatives for Novell and the industry (we will focus on the first two):

  1. Novell's internal strategic architecture and road map for migrating its platform, services, and products to open standards and protocols - to build the Java platform.

  2. An open architecture to promote third-party Independent Software Vendor (ISV) participation in building an interoperable foundation necessary for business critical solutions that meet customer needs.

  3. An open distribution model to promote rich network-aware solutions that are "channel-ready" and available through Novell's channel partners-10,000 platinum resellers and 120,000 CNE's.

Why is Novell developing OSA? Because the systems at work are heterogenous and will continue to increase in diversity, the market demands solutions from these diverse building blocks, and the complexity must be managed in order to make us more productive.

For example, a typical application may consume Oracle's NCA, communicate with Netscape's Fastrack Web Server, and build all components using ActiveX controls from Microsoft. OSA is intended to provide the necessary tools and infrastructure to achieve the integration of these disparate technologies and architectures into a unified solution.

OSA integrates Novell's existing product architectures and provides the context for future architectures as well. Over time, Novell's services will support the architecture directly. For example, today's Directory Services do not support the Java execution platform directly. As Novell expands its support for the Java Execution platform, some or all of the components of the Directory will migrate to Java. Novell, directly, or, most likely in conjunction with industry partners, will provide the tools necessary for the consistent and open consumption of all the elements of the architecture.

At the heart of the NetWare nework operating system (NOS) is the belief that a dedicated network operating system is better for hosting the network than a general-purpose operating system. The NOS squeezes every last bit of performance out of the wire, the processor, and the disk. This allows NetWare to shine in benchmarks. The NOS environment is as close to the metal as you can get-all its components and extensions are written to execute in Kernel space. In fact NetWare evolved as an extremely powerful and rich kernel-level environment, but with no support for application level code running in user space.

Extensions to the NetWare Kernel are written as NLMs. Compared to other kernel development environments, NetWare is second to none. It includes a rich API exported through a C-runtime library called CLIB, where any piece of code on the server is a peer to the NOS. This architecture provides a large degree of freedom, but requires highly skilled programming.

The challenge for the NetWare server architects, then, is to maintain the environment's high performance, and, at the same time, include an application-level development environment that enables network-centric solutions. To meet the challenge, NetWare 5, the next generation Novell network platform, includes enhancements such as virtual memory, as well as the ability to run applications in user space. The OSA SDK supports these new features, as well as the features included in the NetWare SDK.

The Client "The Ghost in the Machine"

Novell's philosophy for the client is simple: make the network transparent. The network should not demand attention -, the user should not even notice it. So Novell builds clients that transparently redirect access to the local operating system to one or several network servers, so that the network appears as a set of local file systems, printers, and other local resources. Most end-users don't know that they use NetWare today.

Typically a Novell client consists of a redirector, a requester, and a security module. The redirector module intercepts local operating system calls and converts them into service requests to the server. In turn, the replies from the server, are similarly converted back into local operating system replies. The redirector usually uses a requester, which is: a module that communicates with the server using NetWare Core Protocols (NCP).

Client such as Novell's Client32 or Client for NT are usually written as kernel extensions to the local OS. This allows the client to load as the OS is loading, and in most cases, to authenticate the user during the startup procedures. This type of authentication is often referred to as early-bound authentication. The client establishes a network context or session on behalf of the user. Included in the OSA SDK is the NetWare Login SDK that allows fine-grained customization of the login process and program.

The client supports APIs for consuming services resident on the network, such as the NetWare file system and print services. These APIs use a generic NCP library. In turn, the generic NCP library uses a portable client C library that abstracts the underlying Novell Client Architecture.

The client APIs are packaged as both static and dynamically link libraries. The library vends the same interface is provided across a variety of platforms, including the NetWare server platform itself. Therefore a developer can more easily port application from one environment to the other using these interfaces. The OSA SDK will include the full set of APIs traditionally supported by the NetWare SDK.

Client/Server

NetWare's first principle is performance. Most APIs are written in C, resulting in fast code and high portability. NetWare's client-server architecture maximizes performance by designing code that minimizes buffer copies and state/context transitions between the application-level API and the kernel-level requester. The function prototype for an API is often arranged so that the resulting stack frame, as set up by the compiler, can serve as the communications buffer that travels through the different layers of the client.

This results in a single copy from a caller's stack onto the communication's hardware buffer. In cases where the API request is bigger than the communication buffer, the requester fragments the packet into multiple smaller packets. This results in an additional copy, but this is done only when absolutely necessary. In contrast, most communications packages simply make function calls from layer to layer. This results in a copy from one caller's stack to the next. NetWare's single buffer copy design yields fast code, but the interfaces appear to be low-level.

The architecture just described is often referred to as "fat client" architecture -"fat" in the sense that comparatively large amounts of code need to be installed before the services can be accessed. This design has some drawbacks, but the performance gains often outweigh the costs. The protocols are usually custom-designed to the requirements of the service. Therefore the NCP resembles a hand-crafted RPC mechanism.

On the server side, the architecture of the services is monolithic and self-contained. A service defines and implements its protocols and communications infrastructure, and the protocol usually dictates the client-side API. These protocols are hand-crafted - has resulted in slower development times. OSA enables developers to create solutions using the principles of high-performance, and the client-server service elements using popular component technologies. The SDK will provide tools that automate the construction of the low-level protocols and infrastructure and minimize the amount of hand-crafting.

Today, the NetWare server platform offers many different scripting languages, including Perl 5, NetBasic, Rexx and ScriptEase. The Novonyx Enterprise Server platform is also available for the NetWare platform - the FastTrack web server and NetScape JavaScript. The challenge today is that these different scripting language environments are completely incompatible. The NMX function library standard has only been adopted by its originators and some of the scripting languages lack component-based or object-oriented programming features and semantics.

Clearly, script-based programs and the new server-side Java, CORBA and database access/connectivity infrastructures require and interoperability layer. Novell is creating this interoperability layer in OSA. Future versions will consume JavaBean software components and Java servlets running on the server platform. On the client, Novell has invested significant resources in developing ActiveX controls and the corresponding JavaBeans to provide client-side access to the network services. Note that JavaBeans can execute within the NetWare Java platform.

The NetWare Java Platform

With the current OSA SDK, Novell ships the Java Virtual Machine for NetWare and JDK version 1.1.3. The SDK includes additional class libraries, such as several name space providers for the Java Naming and Directory Interface (JNDI), a set of Java Native wrappers (JNI) for the NetWare cross-platform APIs, and the JavaBeans mentioned in the previous section.

In addition to standard JDK and extensions, the included version of the NetBasic, Perl and JavaScript support the loading and execution of any Java class including JavaBeans. To support integration and interoperability, the NetWare Java Platform also includes the Visigenic 3.0 Object Request Broker, and a CORBA Trader Service completely written in Java.

Novell will fully support the development of standard Java interface definitions through its existing partnership with JavaSoft, and other industry leaders. The objective: avoid the interface wars in the Java world, and to-

  1. Completely support the standard JDK definition on the NetWare server

  2. Collaborate with JavaSoft to help define the optimal Java Server Platform

  3. Introduce new interfaces only in the absence of existing standards

  4. Work with JavaSoft to include new interfaces

  5. Adopt the JavaSoft standard in the event of an API collision

Novell is actively supporting the Java Server Platform. Novell believes this definition is critical. JavaSoft has defined Personal Java, Embedded Java, not Server Java. In an ideal world, the core Java JDK would be some critical subset of the existing definition, and the Embedded, Personal, Server, and other Java platforms extend the core with new functionality and definitions.

CORBA. The developer uses IDL to describe service semantics and then uses CORBA tools to generate stubs and skeletons for the target language bindings-C, C++, Java or others. Using CORBA as a foundation, developers can still create services entirely in Java. The main difference: the service will derive from the omg.org package and not from the java.obj package. In order to provide solutions that run anywhere on the network OSA uses Java as its focal execution platform. Services that run anywhere must be written in Java; services targeted at the specific platform can be written in any other language. It is not a requirement to write in Java, but it will be extremely compelling to do so.

Distribution/Communications. The distribution and communications layer enable services to communicate with one another. Novell's implementation of this layer relies on Java's Remote Method Invocation (RMI) and CORBA's Internet Inter Orb Protocol (IIOP). Components at this layer provide the semantics required for enabling objects running on different address spaces to communicate-this layer provides the foundation for distributed objects running in a network.

Java/RMI. Communications use RMI protocol and wire formats. Other Java-based mechanisms can also be used-servlets or Enterprise JavaBean. For services not written in Java directly, developers can build Java/Native mappings, which can be accessed remotely but which access the underlying non-Java service using Java native method calls. For example, the OSA SDK ships with a set of Java Native Interface (JNI) wrappers for the NetWare libraries-these interfaces could be accessed remotely using RMI. Consequently developers would write the service implementations as RMI classes and interfaces.

CORBA/IIOP. Communications use IIOP on the wire and the ORB client/server infrastructure as specified by the IDL specification of the service. Developers can also use IDL-based wrappers to map a non-CORBA service into the CORBA environment to service CORBA clients. In 1997, JavaSoft ,the OMG, and a group of industry leaders, including Novell, announced an effort to bring together the RMI and IIOP protocols. Modifications are needed, but the end result is that an RMI server implementation can service a CORBA-client request, and a CORBA server implementation can service an RMI-client request. To provide this, the OSA SDK supports both CORBA and RMI. Today, the service implementations are focusing directly on an RMI implementation, although Novell anticipates interoperability with IIOP in the future.

Java Interfaces and Frameworks. The client accesses Java interfaces directly or through abstractions that may be provided through frameworks. An example of the framework abstraction model is the Java Naming and Directory Interface (JNDI), which is accessed by the application as a local interface. In turn, this interface accesses a Novell service provider for a particular naming system, such as the file system or NDS, using RMI to invoke the call remotely. The service accesses the network through a framework abstraction that hides the details of the underlying distribution and communications layer. This communications layer uses RMI presently, but could use a CORBA mapping just as easily.

IDL Language Bindings. The client accesses the service using the language stubs generated by the IDL compiler and resulting client-side executable code. The service can thus be accessed from any supported language, independent of which language implements the service.

OSA relies heavily on Java. This reliance enables code to execute on disparate network operating system and hardware platforms, and it also results in code that can be mobile, replicated and partitioned without the extraordinary means required if Java is not used. Further, because of Novell's goals for interoperability in the network workplace, it is investing significant resources in creating a CORBA infrastructure. This will permit the use of languages other than Java. With the announced direction to bring RMI and IIOP together, interoperability will only increase.

However, OSA's interoperability does not translate to slow performance. In keeping with Novell's philosophy of high performance, NetWare will provide a high-speed Java execution platform. The Java platform will be tightly integrated with CORBA infrastructure and services to inter-operate with languages other than Java, and with services that may not have been written directly to the platform, either because these are existing services, or because they are new services that have different requirements than those offered by the main platform.

OSA incorporates industry standards for integration and interoperation but also supports de facto standards that make business sense. For example, RMI is the de facto standard for Java-and Novell supports connectivity standards such as IIOP and LDAP. But Novell sees value in its own NCP connectivity standard, with more than 50 million clients and growing. The LDAP and RMI pathways are an interesting case of how Novell is guaranteeing connectivity to Novell services. For example, NetWare supports LDAP. But NetWare server support doesn't guarantee client support. Therefore Novell has licensed Sun's LDAP provider to provide LDAP client access to NDS.

RMI does not yet support several necessary infrastructure mechanisms for connecting to Novell services, such as authentication and session-based connectivity. Novell will provide an enhanced implementation of RMI that complies with the formal specification, while anticipating that once the mechanisms are updated in RMI, Novell engineers can move code to the then-standard and robust RMI classes. Novell will work with JavaSoft to incorporate equivalent enhanced mechanisms to RMI. OSA will enable connectivity using de facto and industry standards. It will ensure the integration and interoperation of the different standards.

The Virtual Platform

We have already examined major elements of the Virtual Platform. But the key to the virtual platform is Java the platform, not merely the language. Another key is CORBA, for integration with non-Java services, or for access to CORBA services written in Java.

OSA will support a "floating" client/server model. By factoring a service into an object model, a presentation layer, and the back-end service implementation, the infrastructure delivers as much or as little of the implementation as is optimal for the client's host. This model does not merely extend fat or thin-clients, but rather fits the client dynamically to the capabilities of the receiving node on the network.

Novell has adopted a canonical framework model. In this model, the consumer of a service codes to the interface, and the architecture uses a Service Provider Model that allows an interface to be serviced by multiple service providers-JNDI is a good example of this model. This design allows the implementation to be remoted at the Service Provider level, or at the higher, public interface level.

Depending on the service, it is possible to remote at the service provider interface. The key is flexibility in composing the thickness of the client by remoting as little or as much of the implementation as is optimal.

The value of the Virtual Platform, then, is in its architecture, in the completeness of its services, in the flexibility of the implementations. Its value is its dynamic, highly adaptable environment. Enhancing the Virtual Platform results in a NOS for connecting the networks and services that comprise the network workplace. Novell will offer a suite of tools for managing everything from the firewall and Internet, to network management events, to user accounts and resource access.

The Universal Component System

Novell is currently developing the UCS. The project's goal is to first provide a revised component infrastructure in the NLM environment based upon the existing NMX function library standard. Then the component infrastructure will be designed to interoperate with Java classes and Java Beans within the NetWare Java Virtual Machine.

In UCS, components written using popular scripting and component languages can be controlled programmatically in the virtual platform, whether or not the developer has explicitly implemented a particular interface. UCS is based on the notion that all component software work in the same way. Each component has properties, methods, and in some cases, events. Only the manner in which those features of the component are exposed differ. Building a uniform interface for all components means is a matter of abstraction-a matter of extracting the common semantics.

To abstract component interfaces, UCS defines a series of object classes that comprise the UCS API call interface. These classes provide late-bound access to any component installed onto the system, whether or not it was written using the OSA SDK. The main requirement is that the name of the component must be sufficiently detailed to uniquely qualify the type of object manufactured by a UCS factory on the NetWare platform. All compliant scripting engines will be connected into the UCS API call layer-and thereby can bind to any component available in UCS.

The first three scripting languages to be integrated will be PERL, NetBasic 7 and JavaScript. Once connected, they can work with a wide variety of component-based services distributed throughout the network. Internally, the UCS architecture uses a simple provider model, where one or more local or remote component models can be connected into the system by implementing the UCS Provider Interface.

Each provider is responsible for implementing the necessary interfaces to render the component model and registering itself with the UCS system when it is installed onto a given machine on the network. Novell Directory Services stores component metadata that UCS uses to instantiate and communicate with the component. Several providers are planned for UCS:

NLM-to-Java Provider. The first provider to be written on the NetWare platform. Enables access to Java classes and JavaBean components running in the NetWare JVM. This provider is critical, as it allows scripting languages such as Perl, NetBasic, JavaScript and Rexx to consume Java components while building CGI scripts to run in a conventional web server on NetWare.

Java-to-NLM Provider. Another critical provider into the UCS environment on NetWare. Will allow any Java program on NetWare to make calls through to a series of pre-built NLM components that uncover virtually all of the available server-side APIs-including BTRIEVE, Oracle, C-Worthy screen routines and so on. Using the Java-to-NLM provider, a developer can write a Java servlet or command-line utility to generate a C-Worthy style screen, thereby saving the memory overhead of loading the JVM GUI.

NLM-to-ActiveX Provider. Bridging NetWare with ActiveX software components on Windows NT and Windows 95 will allow the NetWare mid-tier web application to become an integration point within the network workplace. It also allows customers to combine NetWare's high-performance networking platform with the wide selection of off-the-shelf components available for the Windows workstation market. Customers will build web-based solutions using NetWare and their favorite Windows software components-all without having to buy a copy of NT Server.

NLM-to-CORBA Provider. UCS will bridge NetWare to CORBA based services running anywhere in the enterprise. This appeals to a certain segment of our customers. However, most CORBA developers do not appear to be aware of the need for scripting technologies that enable higher-level consumption environments for their services, allow any Java program on NetWare to make calls through to a series of pre-built NLM components that surface virtually all of the available server-side APIs all without having to buy a copy of NT Server.

UCS-NMX Components. HiTecSoft has created a vast library of functions that abstract virtually all the publicly available NetWare NLM functions including libraries that work with third-party products such as APC Intelligent Power Supplies and Oracle's database. These components were created for the NetBasic 6 product family. The NetBasic script syntax has been improved with support for properties, methods and real objects; Novell is porting existing NMX function libraries to operate in the new programming model. Once complete, this project will offer a complete library of functions for use with any supported scripting language.

NetPages Infrastructure. The NetPages infrastructure provides a way to blend scripting languages into HTML pages created using ordinary web page authoring programs. Once the overall layout of a page has been created, scriptlets written in Perl, VBScript or JavaScript can be inserted into the HTML tags on the page. These execute-at-server scriptlets will be run on the NetWare server before the page is transmitted back over HTTP to the web browser client. In this way, a web page can be built that makes use of any OSA Service or Bean to make use of databases, the network directory, server administration and so on.

ODBX NDO Component. The NetWare Data Object is a UCS-NMX Component that abstracts the B2Systems ODBX API. It is a component that offers simple SQL query capabilities for over a dozen different types of databases. Using the Logical Data Base format, it is also possible to perform SQL queries across multiple types of RDBMS systems.

UCS Component & Application Distribution. Once Java components and their configurations are manageable in the directory, the next step is to distribute the configurations to other server nodes. In large-scale web server apps, a farm of identically configured systems are used to service requests from potentially thousands of concurrently connected users. Being able to clone a component configuration from one machine to many other nodes in the network is valuable.

Not only would this solution be required to distribute individual Java components, such as a JAR file, but also an entire server application. This might include Java JAR archives, NLM modules, configuration file changes, script programs, web page content, and other components.

Trader-Enabled Remote Provider. The initial remote invocation strategy for components by UCS is a simple point-to-point model, where the publisher advertises the presence of a component/application on the network by using the directory. Then the subscriber discovers that advertisement and connects to the publishers' server and consumes the component service. A more sophisticated solution is to use the Java Trader Service to locate the objects on the network.

Licensing/Metering Beans. Novell will supply a Licensing Bean that can be used from any customer written Bean, class library, or servlet to determine whether a user has been granted access to a given application or component. Making Novell's new licensing service easy to use is critical to its adoption, and will solve a real business issue for many developers in this space. Finally, the common question, how do I make money on the Java? has an answer: using the Open Services Architecture and the Universal Component System.

This infrastructure comprises a high-level application development environment, where the UCS is a sort of server dock for components. In this doc, any component, from any component model, can be rendered in a consistent, fully networked environment-whether the component is written in Java or not. This server dock will provide interfaces for incorporation into a component's code. Or the component can be wrapped with a class that decorates the component with a set of capabilities, such as network management, licensing, metering, load balancing, security, and others.

UCS is how components are made Channel-Ready, either with components that implement interfaces directly, or by creating simple abstractions that connect the component to the UCS infrastructure. A solutions provider need only write minimal code to integrate code running on any platform on the network. Of course, there is no effort involved if the component is written in Java - UCS environment will consume the Java component directly.

So the Virtual Platform is a Java-based platform that floats on a network. Complemented with a Virtual Network Dock for components, developers can develop solutions, not just using low-level languages like C or Java, but with Visual Basic, JavaScript, or Perl, thereby expanding the programmability and robustness of the network workplace to Novell's vast channel.

Conclusion

Novell's OSA is a collection of components for all tiers of the network workplace. Alone, the Web will provide sufficient opportunity for solutions developers and network administrators. But OSA will bring together the Web market, other Internet services, and the Intranets, local and wide-area networks that make up today's business market. The infrastructure, services and tools that are part of the OSA SDK and products provide a technically cohesive architecture to build solutions that target all these markets.

The solutions market is vast, despite the absence of architectures that open these markets and lower the cost of entry. The technology is only part of it, but the vision provides the context and the direction both for Novell and the industry. Through OSA, Novell will deliver a services foundation that will be used as the building blocks of the network workplace-the foundation of the enterprise and the Internet.

* 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.

© Copyright Micro Focus or one of its affiliates