Telescript® technology gives the computer user the chance to use agents to do their network traipsing for them while they disconnect from the net and go about other business. An agent is a self-contained program that can travel from location to location on the net. It looks for information and transacts business for the user, and can return to the user when it's finished to report on its success or failure and then deliver any requested information.
A user can, for example, log into a network access service and turn loose an agent to look up local concert dates for the St. Paul Chamber Orchestra and then buy tickets from an online ticket service if the dates are acceptable. The user, after submitting the request to an agent, logs off to enjoy a hike in the hills while the agent performs its network footwork. After the hike, the user logs on again to get an email message from the agent that reports on dates and tickets bought or not bought.
Telescript technology gives programmers the ability to provide network agent technology in their programs or web sites. The Telescript language is a rich networking language that can be used as a network-programming adjunct to other languages such as C or C++, much as the PostScript® language is used as a print- and display-programming adjunct to programs.
Because the Telescript language is designed for networking, it simplifies network programming by handling network transmission protocols in a way that's transparent to the programmer. Its agent technology allows you to get the best results from network transactions with the least use of network resources, an especially important consideration if your program must deal with slow network transmission rates. Telescript technology turns the network into a single platform in which your program can do its work.
The Telescript language is object-oriented to provide the extensibility of classes and objects (described later in this book). The Telescript classes allow you to easily create new programs by building on your earlier work. And Telescript's objects allow you to create your programs using real-world models.
In this chapter, we take a first look at Telescript technology: what it is, how it does its work, and how it can help you create better web pages and networking applications.
A typical Telescript programmer can safely ignore the underlying components of Telescript technology and concentrate on the core of that technology: the Telescript language.
Objects range from the simple (an integer, for example) to the complex (an agent, for example). You can combine two or more objects to create a more complex object. And once you create objects in a Telescript program, Telescript technology provides mechanisms that allow the objects to interact with each other.
Telescript objects are all defined by classes. Creating an object is a simple matter of asking for an instance of a class--a convention that means you don't have to define each object anew as you create it, but simply base each object on the blueprint already provided by a class. You can define new classes by adding to the specifications already provided by existing classes. This makes Telescript an extensible language: you can customize it to create types of objects that fit precisely the tasks you're trying to accomplish.
Telescript's object-oriented nature fits its networking environment well. Because each object encapsulates its data--that is, it prohibits another object from directly reading or writing its data--Telescript binds data and action into discrete units that help enforce security and privacy in the Telescript environment.
If the whole concept of an object-oriented language sounds a little confusing to you now, the next chapter explains it in much more detail and gives you the specifics of Telescript's object-oriented nature.
Telescript is not a low-level networking language. It doesn't concern itself with the mechanics of how information is sent from place to place over the network--you won't use it to send packets through a router or determine an IP address. Telescript focuses instead on high-level network interactions: how one self-executing program (called a process) can exchange information with another process.
When an agent (a traveling process) travels in the Telescript environment, Telescript provides built-in security that ensures that the agent can't take actions harmful to the system and resources of another process. It protects data privacy and it limits actions of a visiting agent to those actons that are granted by permission of a location's owner. To help determine billing for services rendered and to prohibit excessive use of resources, Telescript provides a mechanism that monitors a process's resource use. And Telescript provides a mechanism that can efficiently broadcast information simultaneously to a large number of processes instead of depending on individual process-to-process information exchanges.
The Telescript language is not meant to be a standalone environment. It's designed to provide an efficient tool for carrying out network transactions within an application. A stock-market-monitoring application may, for example, be written in C to display market information on a computer monitor, accept user commands, and store data on a hard disk. When it needs to check stock prices on the network, however, it uses the Telescript language to create processes that carry out its orders on the network. This is much the way that the PostScript language is used within an application to carry out a printing or page-display task. In both cases, the work the language does is invisible to the end user, but it greatly enhances the end results.
As an example of RPC, consider a mailing list client that wants to delete delinquent subscribers from a mailing list stored by a server. It calls once to retrieve a list of subscribers and their last recorded subscription payment. It determines which are at least two months overdue with payment, and then calls once to delete each overdue subscriber from the server's mailing list.
This back and forth exchange of call and result (shown in Figure 1-1) continues over the network until the client is finished with its business. If there are 2000 delinquent subscribers, the client must make 2001 procedure calls to delete those subscribers. This transaction requires extensive use of network communications, and--if the connections are slow--is considerably bogged down by the connection speed.
Figure 1-1 : A procedure using remote procedure calls to work with a remote resource uses many network communications to accomplish a single job.
Remote programming, provided by Telescript technology, gets rid of the back-and-forth nature of remote procedure calls by sending the client process itself--not its procedure calls--to the server location as an agent. Once there, the agent can perform the same transactions with the server (as shown in Figure 1-2) without using network connections. The number of network communications is cut to a fraction of those used for the same work accomplished by RPC. To accomplish the same task described in the previous example, the transaction requires a single communication: sending the process to the server. Compare that to the 2001 communications necessary for the same work accomplished by RPC, and you can see that remote programming saves network use and time--especially if network connections are slow.
Figure 1-2 : A procedure using remote programming to work with a remote resource need use only a single network communication to accomplish the same job.
A Telescript engine can run on any number of different platforms--different flavors of UNIX workstations, for example. A single computer can run more then one Telescript engine if desired (and if the computer supports multitasking). Each engine uses the computer's underlying operating system, hardware, and network connections for its work, but makes their use completely transparent to any Telescript processes executing on the engine. An agent that asks its host engine to send it to a new location, for example, has no idea how the engine will transport it there. It simply knows that the engine will execute the transport whether it has to use a modem, an Ethernet connection, or any other connection technology.
All Telescript code executed on an engine is interpreted. The engine accepts each element of code (called a token) and, when it interprets the token, carries out the action the token specifies. The engine uses whatever platform resources are necessary to carry out that action. Because Telescript code is interpreted, a Telescript process never has direct access to any of the platform's physical resources. Any work it does must go through the engine, which provides a substantial level of security to the underlying resources of any computer that hosts Telescript processes on an engine.
A Telescript engine provides preemptive multitasking--it can, and usually does, run many processes simultaneously. To ensure that those processes won't die an unnatural death if the platform or the engine crashes, the engine constantly backs up its state, which includes the state of all running processes. When an engine is restarted after a crash, it restarts each saved process at its last saved state. This feature is called persistence, a safeguard that ensures that an agent or any other process won't simply disappear without a trace on its travels around the Telescript universe.
Figure 1-3 shows a very simple view of the steps it takes to write and execute a program in the Telescript language. The figure assumes a perfect world, neatly avoiding bothersome programming details such as linking, debugging, and managing source code files.
Figure 1-3 : An HTS script is compiled into LTS code which is interpreted by a Telescript engine.
High Telescript is a compiled language; Low Telescript is interpreted. An HTS script cannot be directly interpreted by a Telescript engine. It must first pass through a Telescript compiler that turns it into LTS code. LTS code is interpreted directly by the Telescript engine.
Low Telescript is completely transparent to Telescript programmers, an intermediate step created by the compiler and read by the Telescript engine. There's no need for Telescript programmers to program directly in Low Telescript. It may, in fact, be risky to write code in LTS because the syntax and structure of Low Telescript may change from release to release with no notification to Telescript programmers.
Because Low Telescript is strictly the affair of compiler and engine, this book describes Telescript solely through the syntax of High Telescript. Whenever you read the word "Telescript" here, you can safely assume that it means High Telescript. If this book discusses Low Telescript, it calls it directly by name or by its acronym LTS.
(Note that in the current release of Telescript, HTS does not yet completely cover all the features of LTS. There are rare occasions when you'll have to add sections of LTS code to an HTS script to get precisely the results you want. This book will point out those occasions.)
Each Telescript process has a telename. That telename is an integral part of the process, and can't be changed or deleted by the process. The telename includes an authority for the process. The authority identifies the individual or organization for whom the process executes. For example, an agent process might execute under the authority of Ozo Benton while collecting stock prices from various locations in the telesphere. That authority is part of the agent's telename, and is visible to any other object with which it interacts. Authority ensures that a process can't misrepresent itself to other objects. Ozo Benton's agent will never be able to pretend that it's running under the authority of Dow Jones to get restricted stock information from a Dow Jones server.
One process may interact with another process when they are in the same location, exchanging information and requesting actions of each other. The Telescript engine imposes strict rules on the way two processes interact. Processes can interact only if both processes agree to the interaction. One process can't ask a second process to do something that the first process isn't authorized to do.
The Telescript language defines two kinds of processes: places and agents.
A place can contain other processes--agents or other places. When one place contains other places, those places are said to be nested within the first place. Nested places can have more places nested within themselves, so it's possible to have places within places within places and so on into an infinite number of places (limited by the computing resources available to support those places, of course). Figure 1-4 shows an example of nested places.
Figure 1-4 : One place can contain other places nested within. Any one of those places can contain agents. (The rectangles in the figure are places; the circles are agents.)
Every Telescript engine contains an engine place. The engine place is the outermost place on an engine: it contains all other places that run on that engine. Each engine has only one engine place.
The location of a process (the place it occupies) determines what other processes it can work with. Two agents can't work with each other unless they both occupy the same place. An agent can't work with a place unless it occupies that place directly. And a place can only work with the place it occupies.
The mechanism of place segregates process interactions into distinct arenas of activity. This is a convenient way to let an agent choose the type of activities it wants to indulge in. If an agent wants to buy tickets to a concert, it goes to a ticket-selling place. If it wants to negotiate used car prices with other agents, it goes to a used-car-market place.
When an agent travels, it uses a ticket, an object that specifies a destination place. A ticket contains the place's teleaddress (among other information) and recommends ways to get to that place. The agent uses its go operation (every agent has a go operation) to tell the engine that it wants transport to the place specified by the ticket. The engine suspends the agent's execution and saves the agent's state. If the agent is going to a destination place that isn't on the same engine, the engine encodes the agent for network transmission. The engine then uses the best means available to transmit the agent to its destination place.
When the traveling agent arrives at its destination place, the engine there decodes the agent and presents it to its intended destination place. If the agent doesn't have the proper credentials (its authority isn't accepted, for example), the place can refuse entry. If the agent is accepted, it resumes execution within the destination place. Execution resumes from the state that was saved before traveling, so the net effect for the agent is of going to sleep in one place and awakening in a new place.
Every process (both agent and place) has a permit that delimits the process's life and actions. The permit states the maximum length of the process's life, the amount of computing resources it can use, possible actions it can take, and so forth. When an agent enters a place, the place can put further restrictions on the agent's permit while the agent is in that place so the agent can't perform actions that the place doesn't want performed.
When an agent enters a place, it can meet with other agents occupying that place. A meeting between two agents starts with one agent preparing a petition, an object that specifies a second agent by telename, by class, or by both telename and class. The agent presents the petition to the place. The place looks for an agent that matches the petition's requirements, and--if it finds a match--notifies the found agent that another agent requests a meeting. If the second agent agrees to the meeting, the place puts the two agents in touch, and they can then work directly with each other, exchanging data and requesting actions. Agents can, of course, decline a petition, so agents can only meet and work with each other if both agents desire the meeting.
A place set up for business typically creates one or more resident agents to do business, agents that don't leave the place where they were created. These agents are there to meet with visiting agents and transact different aspects of business. Having more than one resident agent per place allows a business to segregate different types of transactions. In a real-estate place, for example, one resident agent may supply the names of mortgage brokers, another resident agent may provide a listing of houses in a specified area and price range, and another agent may make appointments for visits to selling houses.
Many resident agents in a single place also provide concurrency. Because the resident agents can execute in parallel, they can handle many more visiting agents at a time than a single place can--the Telescript equivalent of having more cashiers at the supermarket.
A place doesn't have to have a resident agent to do business; visiting agents can work directly with the place if the place is set up to do so.
A genealogy firm decides to set up a web page where users can ask for genealogical research. Clients connect to the page using a web browser, which exchanges information with the page server using HTTP. The web page presents buttons and fields with which the client can work to request a service: searching for the birth records of an ancestor, checking lineage for a particular branch of a family, and so forth. This is not information that the genealogy firm has on hand, so the client won't get immediate results from the server. Instead, the request information they've left is used to start a genealogical search that--thanks to Telescript technology--continues to work after the client has disconnected from the web page.
Underlying the web page is a Telescript engine where agents and places can live. Once a client makes a research request, the server creates an agent of the client's authority that stays at work in the engine after the client has disconnected. The agent first goes to work on information that the server already has, and may then use remote resources to finish its work.
Say, for example, that a client--one Kevin Backe--asks for the genealogy of his unmarried maternal aunt, a woman named Vrinda O'Malley. He enters her name and birth statistics using the controls on the web page. His agent first checks information on the server about the aunt's surname and finds three different genealogical archives where that surname will most likely be found. One archive, in Des Moines, has a genealogical database attached to a Telescript engine; that archive is in the agent's telesphere. The second archive, in New York City, is on the net but it isn't attached to a Telescript engine; it presents its archived information through an HTTP process. The third archive, in the parish records of a small Irish town, isn't even on the net; a human has to call the archive by phone to have an archivist page through birth records there and report what they can find.
Kevin's agent handles each of these archives in a different way. For the Telescript-enabled archive, the agent creates a second agent that also acts under Kevin's authority. That agent travels to the archive place in Des Moines, where it uses public operations to request to see records that might relate to Vrinda O'Malley. The place retrieves what it was asked for. The travelling agent looks through the returned records to sift out pertinent records, and asks for more records if necessary. Once it's finished with its search, it returns to its origin, where it meets with Kevin's primary agent and gives it the Des Moines records. The primary agent puts that information into an email message that it sends to Kevin.
For the archive in New York City that's on the net but isn't Telescript-enabled, Kevin's primary agent establishes an http connection to the archive so it can search through the html text there for pertinent information. Because the genealogical firm uses this archive often, it has customized agents that can work directly with the New York City archive's web page, using controls there to search for the desired information. The client's agent does so, and retrieves more information about Vrinda O'Malley. It puts the information into a second email message that it sends back to Kevin.
For the archive in Ireland, the agent knows that it needs human intervention. It generates an email message to a research specialist at the genealogy firm. It then puts itself to sleep while it waits for results. (This avoids using computing resources while waiting around.) The specialist, diligently checking her email, receives the agent's request along with the phone number and person to contact at the Irish archive. She calls and asks for records. The Irish clerk, a day later, calls back with more information about the Vrinda O'Malley family line. The specialist then enters that information in her computer, asking the Telescript engine to awaken Kevin's agent and present it with the information. The agent sends the information, once again via email, to the client. Because this message completes the work requested by the client, it also includes a list of the work accomplished by the firm and the amount charged to the client's credit card. That amount is established, in part, by work records maintained by Kevin's agent.
As you can see in this example, Telescript is flexible enough to handle a wide range of network resources, low-tech or high-tech. A user can take advantage of Telescript technology through a variety of sources, in this case a common web page. When resources are available in the telesphere, agents can travel to use them directly. When resources aren't available in the telesphere, a process can reach outside the Telescript environment (through net connections and mechanisms provided by the engine) to use them.
Telescript agents offer more advantages than simple mobility. Once launched on their business, they act on their own volition in the interest of their user, even when the user has switched off his computer. Agents can sleep while waiting for results, so they don't overtax computer resources. Because Telescript is an object-oriented language, agents can be customized to the work at hand--in this example, the agents were customized to handle the protocol of a non-Telescript-enabled remote resource.
This book concentrates strictly on the Telescript language--High Telescript syntax, the classes that come with the language, and the concepts you'll need to work successfully with both of these components. The classes that are directly defined by the Telescript language are called built-in classes. (Any classes derived from these built-in classes--library classes, for example, or classes that you might create yourself--are called custom classes.) You'll see in this book just how Telescript's built-in classes work together. But first, you need to know more about classes and how they're defined in the Telescript language. And for that, you need to turn the page and start reading the next chapter.
Generated with Harlequin WebMaker