The JavaScript Language

JavaScript is a compact, object-based scripting; language for developing client and server Internet applications. Netscape Navigator 2.0 interprets JavaScript statements embedded directly in an HTML page, and LiveWire enables you to create server-based applications similar to common gateway interface (CGI) programs.

In a client application for Navigator, JavaScript statements embedded in an HTML page can recognise and respond to user events such as mouse clicks, form input, and page navigation.

The JavaScript language resembles Java, but without Java's static typing and strong type checking. JavaScript supports most of Java's expression syntax and basic control flow constructs, In contrast to Java's compile-time system of classes built by declarations, JavaScript supports a runtime system based on a small number of data types representing numeric, Boolean, and string values. JavaScript has a simple instance-based object model that still provides significant capabilities

JavaScript also supports functions, again without any special declarative requirements. Functions can be properties of objects, executing as loosely typed methods.

JavaScript complements Java by exposing useful properties of Java applets to script authors. JavaScript statements can get and set exposed properties to query the state or alter the performance of an applet or plug-in.

Java is an extension language designed, in particular, for fast execution and type safety. Type safety is reflected by being unable to cast a Java int into an object reference or to get at private memory by corrupting Java bytecodes.

Java programs consist exclusively of classes and their methods. Java's requirements for declaring classes, writing methods, and ensuring type safety make programming more complex than JavaScript authoring. Java's inheritance and strong typing also tend to require tightly coupled object hierarchies.

In contrast, JavaScript descends in spirit from a line of smaller, dynamically typed languages like HyperTalk and dBase. These scripting languages offer programming tools to a much wider audience because of their easier

syntax, specialised built-in functionality, and minimal requirements for object creation.

VII. Заполнив таблицу, сравните JavaScript и Java.

JavaScript	Java
…	…

VIII. На основе прочитанного текста составьте план сообщения о сетях.

7. Read and translate the following text, use all knowledge you've got during the course of English. Good luck!

Networking Objects with corba

The evolution of object and network technologies is bearing fruit in the form of broader system interconnectivity and more modular application architectures. Central to this evolutionary process is distributed object computing (DOC), a model for application development that promises to revolutionize how systems are conceived and implemented. Much has been written about DOC over the last couple of years, but only recently have developers made use of DOC-based tools such as NeXT's Portable Distributed Objects (PDO), IBM's System Object Model (SOM), and Iona's Orbix. (The latter two are implementations of the Object Management Croup's Common Object Request Broker Architecture – CORBA – specification.) Before long, we're told, Microsoft will make available distributed versions of its Component Object Model (COM) technology. Still, the benefits of distributed-object computing are not clearly understood. Consequently, in this article a CORBA-based architecture designed to support a typical business – a virtual bookshop is presented. This project not only demonstrates the technologies underlying distributed objects, but also the Internet technologies with which DOC must work to reach a reasonable number of users.

Fig. 9 is a model of how a business like virtual bookshop might operate. The shop is ''located'' in a cluster of host machines attached to the Internet backbone through a dedicated line to a local service provider. By virtue of

Fig. 9. A virtual bookshop on the global TCP/IP Internet.

the Internet's IP packet-switching protocol, each of these hosts is uniquely addressable among all other connected machines worldwide. Customers ¹¹ arrive" at the shop by connecting to the Internet and executing an interface application. One benefit of using DOC as the underlying architecture of the business is that your services can have various interfaces. Some clients might use an HTML browser, while others might run an application that uses distributed binary objects directly. You might even have to provide a shell interface suitable for a terminal connection. The architecture accommodates all these models of access, as well as those that may be required in the future. How will customers pay for their purchases? There are currently a number of proposals for secure, electronic financial transactions, including "DigiCash", "CyberCash", and "NetCash". In this discussion, the security technology is assumed to exist which allow credit-card numbers to be transmitted in privacy.

A DOC Backgrounder

Before diving into the bookshop's architecture and connection model, it's important to consider just what objects are being distributed and how they

Fig. 10. Simple object model for virtual-bookshop application.

support the business. Fig. 10 illustrates a simple object model. Obviously, to track what you have and what you've sold, you need a Book class. This would be best derived from a more generalized inventory item class. In addition to Book, the domain layer of the application contains Customer, CreditAuth, Order, Service, and Session objects. The Customer and Order classes are self-descriptive. CreditAuth encapsulates a connection to a credit-authorization network to which credit-card purchases are submitted for approval. Service is a\:lass of objects that lets clients send you e-mail, browse a company directory, and perform other customer-service-related tasks. Session is attached to a Customer object on entry to the system; It captures the state of the system for one user over one connection and can be used to allow restart in cases of disconnection, for example.

Clearly, a number of databases are also necessary, at least for inventory, customer, and order information. There will probably be an e-mail database and a short-term-storage database for session information. Whether you think of the distributed objects as interfaces to the databases or the databases as persistence for the distributed objects doesn't much matter. The important point is that the technology allows you a great deal of freedom in choosing these components. When you're done, clients won't depend on the database architecture, the networking model, the platforms used to support the implementation, or even the interfaces of the distributed objects themselves. This is the key benefit of DOC technology – it takes the core object-oriented concept of encapsulation to its logical conclusion. Where object-oriented languages allow encapsulation of state and behavior

at the syntax level, DOC allows physical encapsulation. When an object is linked into an application at the binary level, it brings with it a host of dependencies that make it difficult to reuse. The monolithic applications created on a binary-linkage model become littered with these dependencies and grow more difficult to maintain and extend.

By contrast, a distributed object (the Customer class, for example) is implemented once in a running process that is developed and maintained locally, but available globally. It is available via a call-level synchronous interface in which calls to remote resources look exactly like calls to local objects and procedures. The actual implementation details are not complex from a system-programming perspective, and the end result is well worth it. Application developers can be presented with neatly packaged components that export simple interfaces to distributed services. This borders upon the self-supporting community of component developers and utilizes that has been the promise of object technology since its beginning. The immediate benefit is simpler, more-robust applications. Rather (ban encompassing all of the business rules within its own source, an application evolves into a controller and coordinator of distributed objects. To achieve the benefits of this mode] and apply it to the sample business, you need two key facilities – networking and object distribution.

TCP/IP Networking

Originally the language of interconnection between the nation's large civilian and military research and engineering institutions, the TCP/IP protocol has exploded in usage along with Internet. The catalyst behind this expansion has been the development of efficient serial-line protocols that carry TCP/IP traffic, enabling low-cost dial-up connections to the net. Principle among these is Point-to-Point Protocol (PPP). It is an efficient protocol for wide-area interconnectivity of a variety of small systems connected to a variety of networks.

Fortunately, in addition to being the lingua franca of modern networking, TCP/IP is also preferred language of most Object Request Brokers, the central component, of a distributed-object computing technology.

IP packet switching allows you uniquely address and send packets to literally millions of machines.

TCP provides a safe, stream-oriented interface which packetizes a flow of data, delivers it to IP for transport to the remote system, and there reassembles the stream, guaranteeing packet order and integrity.

Pretty impressive technology, but the devil is in the details – what's in all those little packets of data? TCP/IP is a network-level protocol, actually a set of protocols called a ''stack". When an application uses TCP/IP to deliver data to a remote machine, it has to decide what to put in one end, and what it all means on the other. This constitutes a requirement for an application-level protocol. Early Internet applications were e-mail and file-copy utilities, each supported by its own protocol. E-mail and file transfer remain the Internet's primary uses, but other application protocols have emerged. A recent addition is the HyperText Transport Protocol (HTTP), the river that carries the World Wide Web. This protocol uses TCP/IP to transmit hypertext HTML documents rendered by a browser.