Abstract: Duke ORB Walker is a concept for a software system modeled on the Lycos Web Crawler developed at CMU. With the release of Netscapes 3.0 SuiteSpot Server, which bundles the VisiBroker Java ORB from Visigenics, ORB technology is now ubiquitous on the Internet. Duke retrieves information from CORBA server interfaces discovered on the Internet and keeps a complete database of each CORBA server encountered. Duke uses the CORBA interface repository (IR) capability to interrogate each server encountered, determine the name of supported operations, and the number and types of parameters accepted and returned and records the information in a searchable database.

1. Introduction

A long, long time ago in a galaxy far, far away lived a young Java knight named Duke. Duke was about to confront the evil empire, based in the Redmond system. Duke was relying on his mastery of a not entirely understood force called "the Web" and an ancient technology (circa 1989) called CORBA to defeat the emperor, however he would need something more. Something to pull together all his forces for the ensuing confrontation

The story may be fictional but it does strangely reflect the current state of the software industry. Independent of where the technology is originating, the software industry as a whole is progressing towards a component based philosophy, where large software systems are integrated, rather than developed, from commercial, off-the-shelf (COTS) components.

This movement towards component-based software development has been prompted by a number of factors, both technical and economic. At the level of vertical-market products, for example, software design costs are generally $1 million to $10 million with near zero cost of reproducing additional units, and the typical production quantity is one [1]. Reusable software components help organizations recover costs, improve component quality through specialization, and develop systems rapidly from existing components.

A variety of component models such as JavaBeans [2] and COM and distributed object technologies such as CORBA have come into being that have the ability to affect the way software systems are developed. During the past decade, most new software development was based on standard operating system platforms such as POSIX and Windows NT and used existing toolkits such as Motif and the WIN API to provide GUIs. Beyond these functional subsystems, the number of software components typically integrated is limited to one or none due to the conflicting assumptions of candidate components. Examples of assumptions that prevented software components from being integrated include:

• language bindings
• synchronization models
• platform support
• system resource requirements

Distributed object technologies such as CORBA have the potential to reduce the amount of custom software development and to support greater integration by allowing the integration of components with varying assumptions. Technologies such as JavaBeans, and eventually CORBABeans, can further reduce the effort required to integrate components by offering a well-defined component model.

In February 1997, Netscape and Visigenic corporations announced that Visigenic's VisiBroker for Java and VisiBroker for C++ object request broker technology would be incorporated in Netscape ONE, the open network environment. This development allows Netscape Enterprise Server 3.0 customers to deploy distributed Intranet applications with the bundled Visigenic VisiBroker ORBs for Java and C++. Developers can create distributed applications with the bundled single-user development license for the Visigenic developer tools. In addition, the VisiBroker for Java product has also been integrated into Netscape Communicator, eliminating the necessity for downloading Java ORB classes when loading and running a CORBA based applet, or "orblet".

The integration of VisiBroker into the Netscape Enterprise Server has made CORBA nearly ubiquitous on the Internet. Netscape and Visigenic are hoping to make CORBA and the Internet Inter-ORB Protocol (IIOP) as ubiquitous as HTML and HTTP, making Internet-based services as widely available as Internet-based content is today. [3]

2. Reuse Repositories

A problem that remains is the integrators ability to identify components that provide the functionality and exhibit the correct set of system characteristics required for integration into a system. Reuse repositories have proven inadequate for identifying and reusing components for a number of reasons:

1. Centralized repository: in a traditional reuse repository all qualified software components are kept under lock and key at a central repository by a single authority. Users of the repository are often required to get an account, and possibly pay for the use of the service. Software that finds its way into a repository has most likely been disregarded by its developer and is no longer current or supported. All these conditions serve as inhibitors to the use of these repositories.
2. Costly indexing schemes: Traditional reuse repositories require a manual process of submitting components along with some level of analysis of the submitted component. The repository authority, using a multifaceted classification scheme, creates an index of components. This classification is either performed by the vendor, which is suspect, or by expert third party analysis that is extremely time consuming and costly.
An example of this approach is the JavaBeans directory maintained by JavaSoft [4]. Company, product name, keyword and category classify JavaBeans. All Java Developers and service providers are invited to complete a submission form. The submission form is approved or contact is made via email for questions to be answered in 3-5 working days. Once the submission form process is completed and approved, the information goes into the Java Solutions Guide within 10 working days.
3. Quality assurance: Traditional reuse repositories provide some level of quality assurance (QA). QA is necessary to provide a "set of papers" for the component. Providing qualified components allows the user of the repository to know, with some degree of certainty, that the component does in fact provide the advertised functionality. Qualifying components is a costly process when performed by an independent third party but is necessary to prevent the repository from being characterized as "junk yards".
This approach also leaves the repository authority as the sole arbiter of which components are allowed into the repository. In the case of the JavaBeans directory, Sun Microsystems alone decides which components are approved for inclusion.

4. Conflicting design assumptions: Possibly the most ingrained and irradicable problem with the integration of software components is conflicting assumptions between the developer of a component and the system integrator, or amongst component developers. An example of the latter case are GUI controls developed by different companies, each of which has a "width" attribute. This attribute may be used by the system integrator to determine where to position these controls on a display. A problem can occur if the developers of these controls have different assumptions about what a "width" consists of. One vendor may include the width of the border, while another may treat this as a separate attribute. Conflicting assumptions by the vendors could easily lead to intractable problems faced by the system integrator.

For a component industry to be successful there has to be a large number of components being developed, and these components need to be constantly evolving. The manual effort required in maintaining traditional reuse libraries prevent them from being complete, current and correspondingly useful. What is required is a means of automatically identifying and cataloging components so that a system integrator can quickly match a component to the functional requirements of a system.

3. Goals and Objectives

The goal of an ORB Walker is to apply the search engine model to the problem of identifying candidate components for integration into a system. Until recently, surfing was a typical approach for finding information on the Web. Surfing is unstructured and serendipitous browsing. Search engines enable information published on the Web to be searched and discovered more effectively. Well-known search engines include Webcrawler, Lycos [5], and InfoSeek.

Search engines use indexes that are automatically compiled by computer programs, such as robots and spiders that go out over the Internet to discover and collect Internet resources. Searchers can connect to a search engine site and enter keywords to query the index. Web pages and other Internet resources that satisfy the query are identified and listed. [6]

The Internet provides a widely available infrastructure that is used to maintain information stored in the form of HTML pages. Similarly, the Internet can be used to provide the infrastructure for maintaining a world-wide component repository where software components do not reside in a centralized reuse repository, as in traditional models, but are maintained as active servers at the vendor's site. This eliminates the problems associated with maintaining a centralized repository and associated access issues. Components are updated directly by the vendor when new versions become available, or additional transitional services are brought on line.

In place of traditional, costly indexing schemes, the ORB Walker automatically compiles indexes by going out over the Internet and discovering and collecting information about software components. The ORB Walker does this in a non-judgmental manner, so the problem of having a sole arbiter decide what does and does not belong in the repository is eliminated. Components are classified by the component model implemented (it is hoped that the ORB Walker will eventually span multiple component models), interface complexity, and keywords derived from method or operation names and parameters.

Quality assurance in this model is caveat emptor. There is potential to provide some automatic testing by wiring the ORB Walker to a test harness, but this is limited (by definition) to testing that can be automated. Component databases need to be, at first, free and inclusive. Value added industries such as consumer reports, and underwriter labs can add value by providing independent, quality assurance of popular components. This will help ensure that candidate components are identified and not simply eliminated based on the criteria of the company maintaining the repository. The system integrator or consumer may, in fact, have significantly different criteria.

Integration of components is simplified because the components in the ORB Walker database are implemented according to an existing component model and are classified based on that model. The ORB provides interoperability between applications on different machines in heterogeneous distributed environments. Component models such as COM and JavaBeans, and eventually, CORBABeans, add semantic definition to a components methods. This leaves more time to concentrate on the difficult problem of resolving conflicting design assumptions.

4. Implementation

An initial implementation of the ORB Walker will look solely for CORBA servers. A Web crawler approach will be used to identify candidate hosts. The ORB Walker can then bind to the interface repository (if present) and invoke its methods.

The CORBA interface repository (IR) enables clients to learn about interface descriptions at runtime. An IR is a database of CORBA object interface information. The information in an IR is equivalent to the information in an IDL file but it is represented in a way that is easier for clients to use.

An interface library contains hierarchies of objects whose methods divulge information about interfaces. An IR can contain information about modules, interface definitions, and operations (methods) as well as exceptions, attributes, parameters and other IDL constructs. An interface repository also contains typecodes that are used to encode and decode instances of the CORBA any type. The ORB Walker retrieves this interface information from each host. Tokens are parsed into separate terms based on common naming conventions such as internal capitalization, underscores and hyphens and stored in a database. ORB references are converted into IIOP format Uniform Resource Identifiers (URIs), similar to the URL Naming Service supported by Visigenic [7] and stored with each database entry.

The end user is now able to query the ORB Walker database. A list of URIs matching the search criteria is returned to the user. The user may then select an IIOP URI to access a full description of the interface. The user can then invoke an operation by providing the necessary parameters then issuing the command. Operational results are then presented to the end user. This provides the system integrator with a mechanism for manually testing the component before integrating it into the system under development.

5. Summary and Conclusions

ORB Walker has the potential to impact the way system integrators locate components on the Internet equivalent to the impact text based Web crawlers has had on the way researchers find information on World Wide Web. Components can be quickly located and evaluated as candidates for integration, eliminating an inhibitor for component-based.