Access to Enterprise Data
The difference between Web initiatives that succeed and fail is access to enterprise data. Over two years ago, the Forrester Group was warning subscribers that putting up the equivalent of electronic billboards on the information highway would lead to a "dead Web;" whereas interaction would lead to new forms of trade, commerce and prospects of on-line revenue. And one of the best ways to create interaction on the Web is to connect a database to it. Instead of a page in two dimensions, depth is presented as a container which captures inquiries, orders, requests and business opportunities of all imaginable kinds. This can make all the difference between a Web presence as a new world order cost of doing business and a Web business profit center for gathering leads, serving customers and closing sales. One of the things making the Web come alive and creating interaction is Java.
But Java is not just a desktop phenomenon. With the addition of JDBC, Java becomes the fulcrum, the hinge of the lever, with which the developer can move the enterprise. Where Java shines is as an enterprise infrastructure builder. The need, as James Gosling, the chief engineer at Sun Microsystems, has suggested, "...is to move quanta of behavior around the network" (here "behavior" means "executable code"). Promising new and actual applications include code distribution, distributed network management (with the Internet itself as the ultimate proof of concept for distributed system), scalable application servers and ontology editors for describing and managing class hierarchies, as well as mundane and essential customer service and inquiry. Many tasks in knowledge configuration and management, which today can only be performed manually and are labor intensive, invite the employment of migrating code that, upon arrival and authorization, accomplishes and performs a job.
The Web: The Ultimate Data Store
A breakthrough is provided to Web-based business initiatives in securely connecting to enterprise data about products, customers and history. In a sense, the Web is the ultimate database, whose defining schema, however, is constantly being transformed by the loosely coupled network of servers constantly entering and exiting. In the context of the vast distributed computing landscape of the Internet, clients may not always be able to rely on the convenience of executable content or the pre-established harmony of push technology's publish-and-subscribe model.
New models of computing are useful and indeed required to navigate, manage and engage in meaningful work in such an environment. These include the capacity to take the initiative, be proactive within a defined context and make decisions based on specified criteria. When these features have been built into software components, then we are dealing with software agents. This has profound implications, since agents end up behaving like delegates, proxies and the type of beings who represent others--that is, agents.
The progression from executable content to customized push technology based on a client profile leads inexorably in the direction of increasing agency. Here "agency" means "autonomy"--literally, being governed by internal rule or law, self-rule.
Although "agents" is a dynamic word, capable of taking on many meanings, the meaning here is precise and limited. Features of agency that go over and above the necessary minimal level of autonomy (self-rule) include mobility, adaptability and personal relevance. Many examples of software agents rely on personal profiling. Is shopping the killer application for which we need agents? So-called "collaborative filtering" has received favorable press by providing customers with recommendations of music, books and movies based on shared, overlapping interests (www.firefly.com). This approach has also been criticized as a powerful method of delivering the insignificant. But what about knowledge management, network monitoring and mission-critical infrastructure automation? Sometimes the application that makes a technology popular is not the one for which it is most needed by the enterprise. That is likely the case here.
When the environment is complex enough, any coherent software with good basic if-then-else logic can simulate some aspects of agency. This is done by bringing order and predictability to the behavior of a set of variables too large for any human being to survey intelligently or comprehend. Thus, a good scheduling tool which tracks the dependencies and execution of batch jobs in an enterprise server presents the possibilities of "lights out" operations. Those are operations without human intervention after initial setup. Full-blown agency in the sense of autonomy, however, is lacking.
A Short History of Agents
The 18th century philosopher Gottfried Leibniz, best know as the inventor of integral calculus and methods of symbolic logic, developed the concept of the agent to a deep level. Thus, there is nothing new under the sun. What is new are the implementations. Before silicon tools to automate computing methods existed, he found agents in nature and called them "monads." On the basis of logical analysis, designed to bring clarity to the monad's internal state, knowledge was brought into being. Thus, Leibniz was the original knowledge manager. He was the last person on the planet to know everything there was to know in his time. Leibniz claimed that bringing a concept to experience and organizing experience into a structure as represented in symbols (what we call "documents") gave us knowledge. That definition remains as true today as it was then. Since we interact with people all the time, exchanging messages and tasks and agreements, most people find the metaphor of an agent to be friendly, comfortable and intuitively understandable. We intuitively understand delegating tasks to agents and receiving knowledge back.
Fast Forward to Today
Today the idea of agency is being implemented in frameworks using Java. As of late 1997, the main agent frameworks written in pure Java included: IBM's Aglets (IBM calls its Java agents "aglets" by analogy with applets), General Magic's Odyssey and ObjectSpace's Voyager (www.trl.ibm.co.jp/aglets/index.html; www.genmagic.com/agents; www.objectspace.com/Voyager).As indicated, the network orientation of Java includes downloading executable code in a manner that is machine independent. Executable content points in the direction of increasing agency. So it is no accident that leading agent frameworks (called "ontologies" since they bring agents into being) are all written in 100 percent pure Java. But agents require more than downloading code. They require the ability to move program STATE around the network. Program state implies the program itself is jumping around, deciding where to go next based on calculations made internally. That is bound to be a challenging thing in a Web environment based on a protocol (hypertext transport protocol--http) proud of its statelessness.
This article is not intended to be a product overview or comparison but a discussion of how agent software may affect our understanding of data management in the context of Web computing.
What agents in all of these systems have in common is that they:
- Require a mechanism capable of moving code from one server to another;
- Include class libraries for communicating with remote agents as they migrate from one location to another on the network;
- Provide a way of simulating the transportation of program state from one location to another; and
- Provide an agent server and the equivalent of an agent sandbox.
In general, agents replace conversations. Instead of a long-distance call, an agent is sent at virtually the speed of light to conduct negotiations on site. That is, if the conversation is long and complex enough, then, from a performance point of view, it makes sense to incur the overhead of sending an intelligent messenger, the agent, who then makes up the overhead by conducting a high-performance conversation at the remote location and reports back the result. Further instructions are then issued to close or abort the deal. It is a two-phase commit protocol with the difference that the decision point does not require the continuous connection of all the parties.
Most agent systems provide a context within which agents are created, executed, managed, transferred and terminated. In general, the place is a gateway between agents visiting a host and the host's resources. The sorts of things that agents might want to do are nicely abstracted in the Java class library supplied. For example, General Magic's Odyssey includes tickets, specifying how and where an agent travels; petition, who an agent wants to communicate with; and process related functionality. By default Odyssey uses Java's Remote Method Invocation (RMI) as the transport mechanism to move an agent from one location to another. That means that Odyssey works with any browser that supports JDK 1.1, which at this date is only Sun's HotJava.
Since the function of the agent server will be to listen for requests coming off the network from remote locations, a well-known socket number can be assigned to the host. The itineraries of roving agents can be registered in an associated light-weight database where agents can be made persistent by being stored. For example, with the Voyager product when the moveTo( ) function is encountered, remotely enabled Java class which is the agent (messenger) is loaded into the destination server by the Voyager network class loader automatically. A callback function is then executed to restore the code to the state in which it was executing at the point where it quiesced and moved. This is the mechanism used to simulate the direct transmission of internal program state. A virtual reference allows communication between address spaces. Because the universe is the total address space of the Internet, a 16-byte globally unique identifier (GUID) is assigned at the time of construction. (In this sense, the solution seems inspired by and related to Active-X.)
From Applets to Aglets
IBM's Tokyo Research Lab has extended the applet metaphor in the direction of agents by coining the term "aglet." Their Aglet Work Bench provides many of these extended capabilities. The atp daemon is the server that listens for incoming aglets over the network. Instead of virtual references, an agent transfer protocol (atp) is invoked to move code between contexts. The server context provides all aglets with a uniform environment within which initialization and execution of the code base occurs. Special functions that are invoked when the agent "wakes up" at the remote location are used to determine the initial and continuing state based on the messaging and retrieval of auxiliary variables. The code base provides the base URL of the directory that contains the aglet's compiled class code.
Notice that not all of the code specified in the Java's class path can move along with the aglet when it is dispatched or migrated. For example, an aglet may be using JDBC to access a local database. Transmitting that JDBC code really does not make any sense, since that depends on the type of database accessed which, at the remote location, may be different. Instead the context will provide the version of JDBC appropriate to the remote location.
In summary, agent systems provide a context in which agents are created, executed, managed, transferred and terminated. Context is a gateway between agents visiting a host and host resources. Other agent technology metaphors extend to agent travel, ticketing and requests. But most important, the context provides an agent sandbox. This is a transfer of the metaphor of the Java applet security metaphor in the direction of agency. When agents arrive, by definition, they are untrusted and quarantined. To be sure, even untrusted agents can make offers and requests, subject to subsequent verification. Those agents which have previously registered with the Web administrator and provide their digital signature to prove it, become eligible for additional access, services, and transactions. Naturally, the entire spectrum of scheduling applications (airlines, restaurants, concerts), collaborative design in electronics, engineering and menu planning as well as big ticket shopping (real estate, autos, appliances) opens up. While examples of software agents rely on personal profiling, the betting money is shopping is more an intuitive and engaging example than a killer application of agents, the authentic domain of which lies in knowledge management, network monitoring and mission-critical infrastructure automation.
Active-X: Microsoft's proposal for downloading (moving) executable content around the network and turning one million VB 5.0 programmers into Internet developers. Although this component model is not restricted to VB (for example, Java can be used to develop Active-X controls), it relies on a close coupling with the Windows or NT operating system on the client.
Aglets: A Java-based agent model from IBM based on the idea of applets, implemented by means of Java classes. Promises the same machine independence, "write once, execute anywhere," and sandbox security mechanism as classical client-based Java applets.Applet: Literally, a "little application," written in Java, able to be downloaded as machine independent byte code from the server to the Web browser-enabled client and distinct for its being connected to a Web HTML page by means of a tag
Register or login for access to this item and much more
All Information Management content is archived after seven days.
Community members receive:
- All recent and archived articles
- Conference offers and updates
- A full menu of enewsletter options
- Web seminars, white papers, ebooks
Already have an account? Log In
Don't have an account? Register for Free Unlimited Access