Novell Scripting Options and Future Strategy
Articles and Tips: article
Net2000 RAD/Scripting Manager
Developer Technologies Group
01 Mar 1998
Introduction
High level development tools such as scripting languages, visual builder tools and CASE tools have gained a great deal of popularity in recent years. The number of programmers using such tools vastly exceeds the Java programming community, and will continue to do so. A major appeal of such tools is that very little programming knowledge is required in order to be productive: no object-oriented techniques have to be learned, and many environments don't require type declaration and the other rigors of more formal programming languages.
The whole experience of developing such a program should be easy - the tool helps fledgling programmers debug their mistakes in a perfectly safe and constrained environment. Performance is usually less of an issue to the high-level programmer. Frequently scripts and visually constructed applications are merely used as the "glue code" that integrates pre-built software components written in other more formal languages.
Though tools such as Visual Basic have traditionally had a questionable image in terms of performance, the latest versions support native compilation techniques. There are also a series of new tools in this market space that aim to provide "high performance" rapid application development in C++ without compromising on ease of use.
The most successful tools are also backed up by a large library of off-the-shelf software components that allow the novice to quickly and easily buy the required functionality - than having to build it from scratch. Another frontier that is being explored is that of allowing end-users to become programmers. The market for enlivened web content is enormous, and many of the people who wish to put their content into the web have no computing knowledge whatsoever. This could mean that tools such as Java Studio which expose a purely visual style of logic construction could have a potentially huge marketplace.
Whatever the future holds for visual programming tools, the need for scripting languages is unlikely to disappear. Today, a large number of scripting tools can be used for a wide variety of tasks from automation of repetitive jobs to writing CGI scripts and putting intelligence into web pages that are interpreted in a browser.
Finally, the industry already has several commonly used scripting environments. Some have been built to run on every conceivable platform (such as Perl, Rexx and TCL), whereas others are customized to a particular vendors' platform. It is unlikely that the "Java phenomenon" can be repeated in this market, since several widely used cross platform interoperable scripting languages already exist - is nothing new to this space!
Scripting on IntranetWare Today
Several scripting language engines are available ready to run IntranetWare. As shipped in the Novell "red box", there are actually two languages built into the product: NetBasic and Perl 5.
|
Name of product
|
Script Language
|
Can writeCGI?
|
Can useservices?
|
Comes withNetWare?
|
Comments
|
|
HiTecSoft NetBasic |
Basic |
Yes |
Yes |
Yes |
Different dialect of Basic. |
|
Novell Perl 5 |
Perl |
Yes |
No |
Yes |
Not all functions areimplemented. |
|
Nombas ScriptEase |
ScriptEase |
Yes |
No |
Third Party |
Very much like JavaScript. |
|
SimWareRexxWare |
Rexx |
Yes |
Yes |
Third Party |
Strong focus on task automation. |
|
IBM NetRexx |
Rexx |
No |
No |
Third Party |
Compiles to Java bytecode.Free! |
None of the language engines that run on our platform, other than NetRexx, currently support any real type of object-oriented programming concepts. Similarly, no language is really capable of consuming Java classes or JavaBean components at this time - the majority of the language engines are not even running in the JVM environment.
There is no standard way to consume Novell services within a scripting language on our platform. The two products that currently integrate with NLM-based programs do so in a largely proprietary way. NetBasic introduced the concept of the re-useable NMX scripting library several years ago - acceptance of this paradigm has not been widespread.
The Future of Novell Scripting
Novell's goal is to provide services for mid-tier web development. Competitive offerings in this area allow developers to create applications that run on the server, emit dynamically-created HTML, and integrate security, a full document model, and database connectivity. To compete in this area, Novell will make all of our existing network services (File, Print, Directory, Email, Telephony, Management etc.) easy to consume and build into Internet and Intranet solutions. We will also offer open standards-based solutions to our customers' problems.
The following new planned features are aimed at addressing the high level developers' needs on our platform:
"Freedom of Choice" in Scripting Language. Rather than attempting to impose our arbitrary choice of scripting language on our customers, we will endeavor to provide a choice of possible scripting languages. Obviously, Novell cannot afford to implement every conceivable language for its products - the need to partner with third parties.
Basic and Perl are provided with IntranetWare today, and these will continue as a part of Novell's offering into the future. JavaScript will be provided by Novonyx as a part of their FastTrack web server product. This covers the most commonly needed options.
In addition we will actively seek to partner with third-party scripting language vendors to ensure coverage of other less popular languages. At little or no cost, we should be able to maintain and enhance Rexx, TCL/Tk, ScriptEase, and other language implementations once we have demonstrated the viability of our platform as a mid-tier. Note that there are also several language variants that will run in the Java Virtual Machine environment.
Universal Component System. To provide easy access to all of our network services through all of the scripting languages on our platform, it is necessary to provide a common component architecture that is useable both inside and outside of the Java Virtual Machine. Since JavaBeans is our centerline component model on the IntranetWare platform, we plan to build the new scripting architecture around both Java classes and JavaBeans - that script languages can become one of the primary consumption environments for such components on our platform. This also has the side benefit of providing Java programmers with an easy way to wire up their server logic into a web server based application using all the existing technologies.
In addition, it is intended that Universal Component System should allow high-level programmers to write their own business logic components directly in the scripting language of choice. Obviously, only languages that support definition of object based semantics can be used in this way (e.g., O-REXX, VBA, Perl, Python, etc.).On other platforms, the Universal Component System will always expose the "native" component model.
Distributed Scripting with UCS. Writing scripts that work in a distributed environment is an interesting challenge. Several products can already do this - the programmer is forced into that particular tool's semantics of operation. The aim of Universal Component System is to offer the customer a universal publish-and-subscribe model for consumption of scripts and scriptable software components around the network.
To achieve this functionality, the UCS model uses a simple publish-and- subscribe metaphor with a directory service as the common cross platform registration mechanism. When a given script or component is published, its existence and interface semantics are published in the network directory as a new type of NDS object known as an "Oblet." The information stored in an oblet includes a full description of that software components' type, events, properties, methods and potentially its implementation too (in the case of Java bytecode based components).
Subscribing to an Oblet component is simply a matter of picking from a list of software components available for your use as advertised in the network directory. As client-side programmers subscribe to a component, the necessary proxy code is generated for them - if it were a local object.
Note that this publish-and-subscribe metaphor is completely symmetrical - example a JavaBean on IntranetWare can be called from a Macintosh client, and a script executing on IntranetWare might choose to use an off-the- shelf software component on a Win95 machine. Distribution of requests and security will be handled by whatever the standard Novell transport ends up being. In the absence of anything else, we will experiment with RMI during the prototyping phase of the project.
Integration with Database Access. Virtually every business solution available today employs some type of persistent data store within its implementation. Today the vast majority of data stores in use are based on the relational model; however, over time it is likely that object databases will gain popularity.
On the IntranetWare platform today, database access is limited to the use of proprietary APIs, and there is no generic connectivity layer from our "mid-tier" to databases located on other systems. To solve this, DTG has initiated a project to port JDBC and ODBC technologies onto our platform.
However, just integrating these database APIs and remoting facilities onto the platform will not solve all our problems. It will be necessary to provide a high-level software component interface to access any SQL database. In the Windows space, such components are known as ADO, RDO, DAO, etc., depending upon which particular development tool you are using. There is a very similar story in the JavaBean builder space.
The NDO (NetWare Data Object) component will fill this niche on the IntranetWare platform, providing an easy-to-use front end onto any ODBC /JDBC data source. The programmer will merely have to specify the database name and an SQL query statement in order to have instant access to the fields within a given database - local or remote.
NetPages Web Development Metaphor. In an attempt to address the threat posed by the Active Server Pages development environment, Novell will enhance the CGI gateway programs and, if necessary, the web server itself in order to provide an easy-to-use server side programming model for dynamic HTML and consumption of Novell services. The solution must address security issues and handle cookies correctly. The NetPages document format is likely to be XML or HTML with embedded script snippets that can be written in any supported language.
VBScript-compatible Version of NetBasic. The NetBasic product currently does not support the de-facto industry standard dialect of Basic scripting - Visual Basic script. This effectively prohibits developers from making an investment in NetBasic if all of their code is non-portable to the NT platform.
In order to appeal to a much broader audience of programmers, the NetBasic product will be brought into full compliance with the Microsoft VBScript language standard. However, unlike its Windows counterpart, the NetBasic 7 product will seamlessly integrate with Java classes and non-visual JavaBean software components. On Windows, Java integration is done through ActiveX technologies - in the IntranetWare scripting environment there will be no need for a middleman.
Current Issues
The Enterprise Java Beans specification proposes a fully distributed development environment employing Java Beans as the software components. This is a complementary technology that we can embrace once it becomes available. In the meantime, it is highly likely that we can emulate much of this functionality by leveraging WebLogics' "Jumping Beans" technology--or writing our own object-based RPC using RMI or CORBA as the distribution mechanism. Sun Microsystems is interested in mounting an industry wide Scripting Initiative in an attempt to position TCL/Tk as the new scripting language of choice for the Internet. Novell will support Sun's efforts to establish this standard.
The CORBA Scripting Language and Component Model RFPs propose a new software component model for use in CORBA applications, and also a standard scripting language. Since the RFPs will not be generating any real implementations until the middle of 1998, it is highly unlikely that this effort can result in any significant change within the industry. Since Netscape is involved, it is possible that this model may be pushed into their next generation browser/web server programming environments.
In the long term, Novell will define areas where it can lead. Distributed scripting and the Universal Component System will present such an opportunity for us to add real value around our customers' existing networks without requiring the adoption of new development tools and languages.
* 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.