E-speak started with a very modest goal—simply to change the way the world thinks about computing. Today, we think about computing as the hardware we buy and the software we install on it. E-speak is all about thinking of computing as a set of services we enlist as we need them. The essential difference is that when thinking about hardware plus software, we’re always telling the computer how to do the job. “Go to that server. Use this printer. The paper I want is in the upper tray not the lower one.” These are facts I may not know if I’ve just walked into someone else’s office and I want to print a file. If printing is a service, I say instead “I need a printout of this document, here, in color, by 10 A.M.” I don’t care how the job gets done. Maybe the print shop at the corner did the job and delivered the output.
We can see from this simple example that e-speak’s goal is to make it as simple, transparent, and safe to use an e-service as it is to access a Web page using a browser. There is no need to know where the service is, how it is implemented, what kind of machine is used. I’m not putting myself at serious risk of attack or virus infection by using the service. However, adding computation to data delivery complicates the process of service creation. That’s where e-speak comes in.
Following the idea of services to its logical conclusion leads us to the concept of an open marketplace. However, there’s a problem. Look at the poor souls in Figure 1. The man has a great idea for an e-service, but before he can offer it, he has to solve a number of problems, including advertising, billing, security, and so on. The woman could make more money if she used this service; her customers could have a better experience. However, before using the e-service, she, too, has a number of problems to solve, finding the service, monitoring its use, security of her system, among others.
The problem is that today, they each solve these problems independently. It’s a terrible waste of time and money. However, there’s an even more serious problem. Because they’ve solved these problems independently, they’ve solved them slightly differently, making it difficult for them to interoperate.
E-speak is a layer of software running on collections of equipment that provides a set of mechanisms for solving this common set of problems. Because the mechanisms are the same for everyone, it’s easier for the two parties to interoperate. E-speak also provides a language for specifying a variety of policies. It is this combination of a platform providing the common set of mechanisms and the language for setting policy that makes e-speak a critical part of the open services marketplace. If this is all you understand about e-speak, you’ve captured the essence of what it does.
Service Composition
Nobody knows how to make a pencil [12]. One person shapes the graphite; someone else produces the eraser. A third party makes the little metal band that goes around the top. Very interesting, but what’s this got to do with e-speak? Simple. E-speak encourages the same kind of service composition that goes into the making of a pencil.
Say that I want to go into a business with several components, none of which I know how to do. Integrated financial management, for example, might include payroll, tax preparation, and cash management. With e-speak, I can easily enter this business as long as each piece is available to me as an e-speak service.
Figure 2 illustrates the process. First, I describe the business logic of my new service. I’ll also describe my policies, such as billing, authentication, and the like. Once that’s done, I can advertise the service on the Internet or an intranet. E-speak doesn’t have to be everywhere; you can benefit if you just use it to streamline your intra-enterprise applications. Once the service has been advertised, a customer can discover it and use it. There’s something significant about this process. You’ll notice the service doesn’t need to be configured to run specifically in the customer’s environment. That’s because the service provider told the system what job to do, not how to do it. Not “Use this specific computer.” Instead, “Use a computer with these attributes.” As long as the customer environment has a computer with the right attributes, the job runs. No need for the developer to configure the software for each installation; no need for the customer to go through six reboots.
What if the customer doesn’t have a computer with the right attributes in her environment? That’s the real beauty of thinking e-speak. It doesn’t matter. As long as someone is willing to provide as a service a computer that can do the job, the service will still run correctly. The developer didn’t need to do anything special to make the application work; the e-speak platform took care of it.
The E-speak Stack
E-speak addresses the key problems of the open services marketplace—naming, discovery, management, security, programming, and interoperability—in a single, coherent architecture. It is a complete platform as shown in Figure 3.
At the bottom of the stack is the transport layer. The transport is not part of the e-speak architecture, only its interfaces are. It should be simple to provide for transports, such as infrared, in addition to TCP and HTTP. At the top of the stack are the services—they are not part of the e-speak architecture either.
The rest of the stack is defined by e-speak. The engine provides the operating platform on which the other parts ride. It handles the basic abstractions of naming, discovery, management, and access control. The engine also mediates all requests, providing virtualization and generating the proper management events. Three programming models are built on this base, direct messaging, exchange of XML documents, and network objects (NOM), a style similar to CORBA or Java RMI. Next comes the business logic. E-speak does not mandate the way business logic is described. Instead, it provides a framework for using any available system.
The most important part of the stack, the part that makes dynamic composition of Web services a reality, is the service bus. The bus itself doesn’t exist as an entity any more than the Web is a physical entity. Instead, like the Web, the e-speak service bus consists of pieces of services that implement its interfaces. It exists so that any compliant service can be used as a building block of higher-level services without a human reading documentation and implement interfaces. It includes specifications for advertising, discovery, introspection of both interfaces and protocols, negotiation and contract formation, and service invocation. The service bus is defined in terms of a set of XML documents that can be communicated over the Web on a universally available transport, HTTP [6]. Thus, using an e-speak service can be as simple as filling in the blanks in a form.
The e-speak platform reduces the barriers to producing e-services, but there are also infrastructure services that almost any business needs, like billing, credit management, authentication, and authorization. The service bus specifies the interfaces for each of these infrastructure services.
Assumption and Implications
When we started the research on e-speak in 1995, we realized we had a unique opportunity, a chance to design a distributed system from the ground up knowing the Internet was a commercial plat form. Had we started a year earlier, we might not have realized that business could be conducted on the Internet. After all, through its early life, the Internet was a means to deliver data, not services. None of the earlier designers could have known what we knew; those that followed would be working against long-established patterns. This knowledge led to a design based on the following assumptions.
E-speak is an environment that brings a number of advantages to providers of Web services and their users.
Large scale. We assumed we would deal with 1,000,000 machines. We now know how ridiculous a number it is—ridiculously small, that is. We realized we could not have a centralized anything; not a database, not a control point, not an authenticator. Any such a thing would eventually become a bottleneck. A very large number of machines also means you must give up the idea of keeping data consistent.
Dynamic. With a million machines, someone is always tripping over a power cord. New services are appearing; old ones are going away. E-speak is built to work in a dynamic environment like the Internet. Every part of the system—from naming to invocation and replies—has special properties for dealing with this world.
Heterogeneous. The world is heterogeneous and getting more so, not less, as some would have you believe. Almost everything, from cars to electric shavers, has computers with specialized operating systems. The heterogeneity is not just in the hardware platform or operating system. It is also in functionality. E-speak was designed to work on devices ranging from supercomputers to pagers.
Hostile. The Internet environment is hostile. Security is difficult to do, so difficult that system designers often leave it for last. Unfortunately, if you try to add security later, it is very difficult to block all the ways around the mechanisms. The design of e-speak started with a way to control access to resources, and security is fundamental to the architecture.
Many domains of control. There are different fiefdoms. The fact your security is based on classifications, such as secret and top secret, and mine is based on compartmentalization should not prevent us from cooperating. You should be able to manage your system any way you like; I should be able to do the same with mine. We recognized this when designing e-speak.
Design Principles
These assumptions led us to a number of design principles. Remarkably, the abstractions we developed early in the project survived the test of time, and we were able to use them repeatedly.
E-speak was designed to deal with technological advances. In order to deal with a dynamic environment like the Internet, e-speak has to be seamless, flexible, and to allow for dynamic evolution, able to deal with current and future requirements. That word “future” is very important. There is no need to wait for the next release of the software, no need to shut down the system and restart, even for a kind of thing invented after the system started running.
E-speak is designed to be scalable, manageable, and secure. Designed to operate on the Internet or Intranet, e-speak avoids bottlenecks such as centralized databases and a reliance on data consistency. Its mechanisms provide the hooks necessary to manage and secure the system without forcing everything be done a specific way.
E-speak has no special cases. Any special case needs very strong justification, and none passed our test. Each is an architectural nightmare, a development nightmare, a maintenance nightmare. Every time a special case was proposed we would lock ourselves in a conference room until we figured out how to do without it. Doing the work in a research environment gave us the luxury of taking this time, but its benefits contributed to the speed with which the product was produced.
E-speak has a completely uniform access model. E-speak makes no distinction between a service, such as a billing service, and a resource, such as a transaction to that billing service. Even though people normally think of a service as being active and a resource passive, e-speak’s mechanisms are the same for both.
E-speak deals only with service control information, not service semantics. If you say “open a file,” and permission is granted, your file gets opened. If you say, “open a butterfly,” and permission is granted, the butterfly opens its wings. The important thing is that e-speak does the exact same thing in each case. E-speak makes no attempt to understand the semantics of your service. That’s why it can deal with a new kind of thing; e-speak doesn’t even try to understand an old kind of thing.
E-speak mediates and virtualizes every request. In a dynamic world, things change rapidly. E-speak must be able to deal with such occurrences without breaking the application. Mediation lets e-speak keep management informed, and virtualization lets e-speak hide the changes from the application.
E-speak is built on industry standards wherever possible. There is no need to reinvent what the industry has adopted. E-speak leverages transports such as TCP/IP and HTTP, invocation with SOAP, interface specifications with WSDL, business logic with XML, and standard ways of encrypting and authenticating.
The goal of e-speak is to reduce the time from idea to market to two hours.
Technology
E-speak is a single, coherent architecture that deals with the four key problems of distributed computing:
Naming. Most distributed systems give the problem of naming short shrift, relying on URLs or something similar. As simple as a Universal Resource Locator sounds, it is not sufficient in a dynamic environment like the Internet. First of all, you must know the name to use the service. Secondly, the dynamic nature of the Internet means the service you’re requesting may have been renamed, may not be available, or even offered at all. E-speak provides a layer of indirection to shield the application from these problems by keeping a mapping between the references used and service instances.
Discovery. Naming a specific service falls into the category of telling how to do the job; finding a suitable provider is telling the system what job you want done. E-speak provides powerful mechanisms for discovering service providers, including the ability to set the context for a search by specifying a vocabulary. While standard vocabularies can be used, e-speak allows anyone to define a vocabulary at any time. Each vocabulary is an e-speak resource like any other and can be discovered if it is advertised in another vocabulary.
E-speak also includes a means to discover services on other machines using an advertising service. The advertising service is also used to form communities—groups of cooperating e-speak systems. In general, you can find any service offered by any e-speak machine in one of the communities you belong to.
Security. E-speak access control is based on three important concepts—fine granularity, dynamic roles, and explicit authority. Fine granularity means individual operations of e-speak services can be controlled independently of any others. Dynamic roles recognize the fact that who I am is often less important than what job I’m doing. Sometimes I’m an engineer; sometimes I’m a daddy. If I change jobs, my access rights as an engineer should go to my replacement; the right to discipline my child should not. Explicit authority allows me to decide which of my access rights a process acting on my behalf may use.
Manageability. E-speak mediates every request. There is a cost in latency, but a tremendous gain in manageability. Since the e-speak engine sees each request, we can rely on it to generate the appropriate management events. There is no need to build this piece into every application, verify the implementation is correct, and make sure that everything gets updated for every new version.
E-speak provides the tools necessary to convert these low-level events into those appropriate for high-level management systems. Equally important is that e-speak events are carried as e-speak messages. Since e-speak messages can cross firewalls, so can management events. This feature opens up the possibility of outsourcing system management. It is even possible to have different contractors manage different aspects of a single system.
Summary
The Internet and Web browsers have brought us to the brink of a new way of doing business. The picture has not been complete, though, preventing us from moving to the next level. Various projects and products have attempted to address parts of the problem. Examples include Microsoft’s Biztalk [10]; HP’s Praesidium [7]; Sun’s Jini [2]; and Web services with SOAP, WSDL, and UDDI [11]. E-speak provides a more complete framework in a single, coherent architecture [1].
E-speak is an environment that brings a number of advantages to providers of Web services and their users. Figure 4 shows how the pieces fit together. The central part is the e-speak engine and the intermachine communication. There is also a high-level library for Java programmers and a set of XML schemas that each provide abstractions suitable for creating e-services. The e-speak service bus and infrastructure services are key to making it easier to bring the next layer of applications and services to market.
The e-speak adapter was originally developed so that e-speak services could be provided and used solely through the exchange of XML documents. In fact, we can provide services to clients who have nothing but a standard browser, one without so much as an e-speak plug-in, by taking HTML from them, translating it into XML, and feeding it through the adapter.
Once we have the idea of an adapter, it’s not difficult to envision bringing complementary solutions into the e-speak world. Prototype code has been written that allows any Jini-enabled device or Enterprise Java Bean to be an e-speak service without any modification. The effect is that the Jini device or bean can be discovered, managed, and secured using the full power of e-speak. They also benefit from the language independence of e-speak and its ability to work on the Internet, including across firewalls.
In summary, what is e-speak?
E-speak is an operating environment for the Internet that reduces the barriers to creating e-services.
How much does it reduce the barriers? Well, our first customer built an early version of its e-service in three months in mid-1999, in spite of our changing interfaces between the Beta 1.0 and Beta 2.0 releases. Our next customer took only two weeks in early 2000. Even more impressive was the company that called to say that they downloaded the open source material, studied it for a couple of weeks, and produced a working prototype of their service in only two days.
That’s not good enough. The stated goal of e-speak is to reduce the time from idea to market to two hours. How is that possible? Think of a tool that will allow a business planner to describe the business’s logic in a UML diagram [5], something taught in the business schools today. If every node in that diagram is an e-speak service, the job is done.
E-speak is no longer supported by Hewlett-Packard. Instead the company has decided to adopt Web services technologies [11]. The complete, open source e-speak distribution at ftp.hp.com/pub/linux/espeak is provided as-is, with no support from Hewlett-Packard.
Join the Discussion (0)
Become a Member or Sign In to Post a Comment