E-speak Fundamentals.

E-speak Fundamentals

The Essential Difference
Hardware + Software Tell the computer how to do the job Services Tell the computer what job you want done The problem with thinking about computing as the hardware you buy and the software you install on it is that you’re always telling the computer how to do your job. “Go to this print server, use that driver, rear drawer, plain paper …” If you think about computing as a set of services you enlist as you need them, you say “Print this file as color transparencies in this building by 11:30”. This is what e-speak enables.

Overview What the "big picture" for e-speak is
What the various modules of e-speak are How service providers and consumers interact How to identify projects that are a good fit with the e-speak technology

Systems Evolution Monolithic, proprietary systems Open systems
2-tier client-server systems Open data (Web) 3-tier, 4-tier, … systems Proprietary, one-off services (Amazon.com, Expedia, eBay, …) Well, we’re not in the world of ubiquitous e-services. In fact, we’re facing quite a mess. I contend that the problem is bad assumptions. Back at the dawn of computing, all work was done on large machines kept in glass enclosed rooms. You’d hand in your deck of cards and a couple of hours later get back some print out that showed you had forgotten a parenthesis in your Fortran program. As we moved to 2-tier, open systems, propelled in part by HP’s early adoption of Unix and RISC technlogy, we carried the mainframe assumptions with us. One was the assumption of a shared pool of resources. Since the assumption wasn’t valid, people fixed the individual problems. Network File System is an example of such a fix, a point solution. When we moved to the internet, we also carried assumptions forward. For example, in the 2-tier world, the machines might be distributed widely, but they were all under the physical control of the enterprise. Since that assumption is false, we see many attempts to solve this problem. Another point solution. When we started this project at HP Labs, we decided to start with a clean slate. Open services (E-speak) Dynamic n-tier systems Service composition & Customization

E-speak - the Technology Goal
Do for services what the Web has done for data. Make it as simple to create, compose, deploy, manage, personalize, and access services as it is to publish and access data on the Web.

Technology Platform for Open Services
What is E-speak ? Technology Platform for Open Services E-speak (services) Web (data) Internet (connectivity)

What does E-speak do ? What is it ?
In a world made up of electronic services, (being provided and consumed on the intranet or internet) e-speak helps to solve the problems of developing, deploying, advertising, securing and managing those electronic services. E-speak is a platform for services This slide makes an initial assumption - that the party considering using e-speak is already convinced that the world of e-services is one they wish to operate in. Given that business decision, the questions of how the services will be created, how will their lifetime be controlled, how will access to them be allowed or denied to various parties, how will they be deployed, come up. E-speak provides a large part of the answers to these questions by introducing a technology platform that has the basis for configuring each of these and an approach to development of new services that is already in use. E-speak allows the newcomer to e-services to get started quickly by providing the basis on which service provision or service consumption will rest.

Services on Tap Appliance E-speak Service Provider A
Service Provider B Service Provider C 1. User needs application on the appliance 2. Appliance connects to e-speak and asks it to find the "best" provider 3. Service provider runs the application 4. E-speak mediates the interaction 5. Data store can be on appliance, in service provider B, or elsewhere in the system. 6. Consumer and service provider may remain mutually anonymous One can think of the e-service as an application, managed by one company and used by another company, over the internet. This model bears some similarity to the Application Service Provider (ASP) model of “renting” applications on the internet. E-speak differs from the ASP model in the following : - a collection of service providers is available from multiple sources - there is no lock-in; - the level of granularity of the e-service is fine-grained (down to a single object or method in the extreme case) - e-speak generalises the security and monitoring policies across different providers - e-speak does not influence the internal workings of the application or e-service

An E-service in E-speak terms
has an interface (programmatic or document based) can be described using attributes can be found using an attribute-based description can be managed by a party other than the user is available for use on a distributed basis

Reducing the barrier to new, competitive services
Services Framework Reducing the barrier to new, competitive services As soon as you start thinking about computing as a set of services that you enlist as you need them, interesting things start to happen. I like to call this my “Nobody knows how to make a pencil” slide. Someone knows how to make the graphite; someone else the eraser; a third party makes the little metal band; and there’s someone to cut the wood. But nobody knows how to make a pencil. With e-speak we can reach a world where we can say that “Nobody knows how to do financial services”. I’ll just identify someone to do payroll, tax preparation, and cash management. The aggregator will describe the workflow and advertise the service. A customer can find the service, form a contract with the provider, and invoke the service. The fact that the aggregator doesn’t know how to do any of the steps is irrelevant. The customer gets the desired service. In this example, this man’s product is investment reports for day traders. When a request comes in, he inserts data from an on-line database into some boiler plate text and prints the report. Without e-speak, he’d have to know a good deal about each customer’s environment, or the customer would have to do a lot of work to customize the application. With e-speak, the proper components are enlisted as needed because they’ve been described as individual services.

Open Services Marketplace
New services and service compositions, New service providers Cache Bill Locate Monitor Discover Utility Manage Distribute Convert Negotiate Meter Int**net Mirror QoS Verify People are putting up services on the Internet every day. Here’s a guy with a good idea. Before he can get his business up and running, he has to solve a number of problems - advertising, billing, distribution, security - to name a few. Here’s a businesswoman looking for someone to fill a business need of hers. She, too, has a number of problems to solve - discovery, monitoring, security - to name a few. Today, everyone must solve this common set of problems. Because they’re solved individually, they’re solved slightly differently, making interoperability difficult. E-speak is a platform that addresses these issues. It provides a programming interface for service providers and service users to express their policies. These policies will then be enforced in a uniform way using the mechanisms that I’ll be describing in this talk. Isolate New customers

E-Speak: The Big Picture
ERP Printing Service N … Health Monitoring Data Storage Data Mining Procurement Service Framework Document Exchange Model The e-speak service engine has an interface, called the Application Binary Interface (ABI). It is possible to use the ABI to communicate directly with the service engine. The main value of the ABI, however, is that it allows the e-speak API library to be ported to any programming language without changing the service engine. Some of the service components -- Web Access and Advertising (a directory service) -- are included with the distribution of the service engine. HP is building a brokering service as a product, which will be sold separately from the e-speak service engine. The platforms currently supported by e-speak are Microsoft NT 4.0, Linux (Red Hat 5.2 and above) and HP-UX 11.x. E-speak API (J-ESI) Network Object Model E-speak Service Engine

Assumptions and Implications
Large number of machines No centralized anything, forget consistency Dynamic Deal with failures, new services Heterogeneous Different hardware, OS, capability Hostile environment Security is critical Different fiefdoms Never look inside another machine First we said that we had to deal with a million machines. We now know that this number is orders of magnitude too small, but it focused our attention. E-speak has no centralized anything, it becomes a bottleneck. Also, it does not rely on data consistency, because you’ll always be waiting for the changes to propagate. 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. The world is getting more heterogeneous, not less, despite what Microsoft and Intel would have you believe. For example, a Saab has 50MB of software, a network, and 12 operating systems. Your electric shaver has 8KB and an operating system. The environment is hostile. There are bad people out there; there are careless people out there. E-speak started with a security model. In fact, the first two machines we connected each ran a script called “malicious”, attempting to get the other machine to do something it shouldn’t. There are different fiefdoms. The fact that your security is based on classifications, such as secret and top secret, and mine is based on compartmentalization should not prevent us from cooperating. E-speak addresses this problem by never looking inside another machine.

E-speak Resource Model
E-speak System Attribute Descriptions Naming Permissions Interfaces Communication Virtual Resource Abstraction Vocabularies Authorization Transports Repositories Basic Services Resource Access LDAP DCOM/CORBA Java Platform HTTP Basic Services Interrupt Handling Scheduling Memory Management Timer Services Legacy OS Legacy Resource Abstraction (eg: NTFS) Look at it this way. When you access a resource on a conventional OS, you express the request in terms of an OS abstraction. The OS uses lower level services to satisfy your request. E-speak does the same thing. It, too, uses lower level services to present the e-speak abstractions. Should the request be for a legacy resource, such as a file, e-speak uses the OS abstractions to access the resource. Looking at it this way, you can see that e-speak is sort of like an operating system. It presents its own resource abstractions; it provides access control as you’d expect form an OS; it deals with naming as you’d expect from an OS. E-speak is not a real OS for two reasons. It doesn’t have any device drivers to talk to the hardware, and a “sort-of” OS doesn’t have to do everything. If you’ve built a real OS, and some important operation is too slow, you’ve got a slow OS. If you’ve built a “sort-of” OS like e-speak, you can choose not to offer that abstraction, relying on the native OS of the machine you’re using.

The E-speak Engine’s Three Main Functions
Managing a repository of service descriptions for the purposes of allowing others to find those services Message routing (to services or to other engines) Name handling (allowing users to create name hierarchies) There are other functions of the e-speak engine, which have to do with “Core managed” services. These are made up of vocabularies, contracts and repository views. These are entities (resources) whose lifetime is managed by the engine itself. Only when an entity wishes to access these core managed resources, then the engine participates in security checking Each message has 2 parts. The envelope contains information of interest to the Core; the payload carries the application specific information. The Core never looks at the payload. A task sends a request to the Core by putting the message in its outbox. The Core processes the message, constructs a new message consisting of a rewritten envelope and the original payload, and puts it into the recipient’s inbox.

Architecture - Scenario 1
Federation of autonomous engines Asynchronous, message-passing between engines Service mediation Naming, monitoring, service location independence A Simplified View of an Architecture An e-speak system is a federation of logical machines. Each logical machine has an active entity we call the Core, to distinguish it from an OS kernel. The Core has a passive component called the Repository that holds all the metadata. Communication between users/providers of services and the Core is via messages put into mailboxes. This model is conceptual only. Actual messaging need not be used. The owner of a service registers it with the Core, providing the metadata. The Core records this information in the Repository and assigns the metadata a repository handle that is unique to this Repository. Repository handles are never reused. A task may have a name bound to this repository handle. The only way the task can refer to the resource is by this name. There is no way to present a repository handle to the core. When a task specifies a name, the Core uses the repository handle associated with this name to determine which metadata should be referenced. Service Provider Service Consumer E-speak engine E-speak engine

Look up a service in one engine Get a reference to a second engine (or the web access part of the second engine) Use the service via the second engine Service Provider Service Consumer 2. Use the service 1. find a service E-speak engine E-speak engine

Look up a service in one engine Get a reference to the service Use the service directly (no engine intervention) This is the web access model (check documentation for more information) Service Provider Service Consumer What I’ve just described is pass by reference semantics. E-speak also supports pass by value. The essential point is that we never look inside the other machine. The proxy takes a request in the E-speak Intermachine Protocol. It doesn’t know what kind of machine it is talking to; it doesn’t know what OS the other machine is running; it doesn’t even know if the other machine is running a Core at all. All it needs to know is that the request was expressed in the right language, ESIP. Handling things this way gives developers a lot of freedom. A big server can run a Core and all its component. A small machine might run only the Core or even only a subset of the Core. A device like a beeper might run only an application that can speak on the wire in ESIP. 2. Use the service 1. find the service E-speak engine

Traditional Middleware
E-speak vs.Traditional Middleware Traditional Middleware Directory Server Client Directory lookup Direct access to service No mediation No virtualization Virtual service intermediation Uniform services model Attribute-based lookup Individual name spaces Capability-based security Proxies e-speak Core Client application Advertising service Service We can now see the essential difference between traditional middleware and e-speak. With traditional middleware, the client goes to a directory service and gets back contact information for the service provider. It then uses this handle to invoke operations on the service. Jini works this way, for example. The problem is that, if the owner of the service wants access control, billing, management, etc., it’s got to be done by the service provider. Is this really what we want to do when the service provider is a device like a printer? With e-speak, the client gets a name binding, either from a lookup in the local repository or by going to an external advertising service. Here, however, the request is mediated by one or more Cores. They can provide the access control and generate the management and billing events instead of putting the code into every service provider. Here’s another example of e-speak separating service semantics from service metadata.

J-ESI and E-speak WebAccess
J-ESI: (Java E-service Interface - the engine API) fast, relatively close coupling (programmatic interface must be shared by service provider and service consumer) intense and small grained interactions feasible more suited to intranet uses WebAccess: piercing of firewalls simpler, use of services on the internet, B2B larger overhead (parsing of XML documents, WebServer, servlet time consumption) per message larger grained messages (e.g. one XML document contains all information) standard message content, loose coupling of service provider to consumer

XML and e-speak The e-speak J-ESI currently supports XML for the following vocabulary descriptions service descriptions queries XML will also be used to interact with the e-speak core and e-speak components XML can be used as the encoding for the payload of your service interface You must provide your own parsing for the message payload as part of your service provider and service consumer code This use of XML is independent of the e-speak engine; the engine does not interpret the payload of messages.

Technology Innovations
Dynamic discovery of services Security Model Meta-data Model

The E-speak Network Object Model How Service Providers and Service Consumers Interact

The E-speak Engine’s Network Object Model
service consumer resource handler resource A resource is anything that can be described to e-speak using attributes and their values client library client library The Client Utility is based on the concept of a Logical Machine which consists of an active engine and a passive Repository. Tasks request access to resources by sending messages to the engine. This messaging metaphor does not mean that actual messages are sent. The actual communications mechanism is part of the implementation on a given platform. engine

Interfaces are defined between components
service consumer resource handler resource J-ESI J-ESI client library client library The ESI is the E-speak Service Interface. The ABI is the e-speak Application Binary Interface, which provides a set of low-level data formats and interactions with the e-speak engine. ABI ABI ABI - Application Binary Interface - a set of structured messages between the engine and the client library engine

E-speak’s Network Object Model
service consumer resource handler Developer writes this Developer writes this resource J-ESI J-ESI E-speak provides these client library client library ABI ABI engine

Q: How does a task use a resource from another e-speak engine?
E-speak’s Network Object Model Q: How does a task use a resource from another e-speak engine? A: The same way it uses a resource on its own engine. One key feature of the Client Utility is that the engine is never aware of another machine. When a resource request is made, the engine forwards the request to the resource handler. If the resource is remote, this handler is a proxy for the machine owning the resource.

A Single engine View service consumer resource handler resource client
library client library engine

A Multiple-Engine View
service consumer resource handler resource client library client library ABI ABI Engine A Engine B ABI

service consumer resource handler resource J-ESI J-ESI client library client library ABI ABI engine engine ABI E-speak

Q: How can e-speak handle the great variety of potential services?
A: E-speak is concerned with service metadata and access control. Consider a new kind of resource, an audio format that plays through the computer’s bell. We don’t need to wait for a new release of the operating system. We don’t even need to reboot. All we need is an application that knows how to use the new resource type and act as a resource proxy for it.

Metadata Description (attributes with values)
Vocabulary (one or more, in which the service is described) Contract (the interface provided by the service) Access Control (handled by the security subsystem) Since the engine will be executing the matching rules, we can’t define a grammar in terms of code supplied by the client. Instead, the engine provides a toolkit that includes all the pieces needed to build a vocabulary.

Show me what happens when a consumer makes use of an e-service.
A simple example Show me what happens when a consumer makes use of an e-service.

service provider provider systems 1. service provider registers with the local engine. J-ESI client library engine B

service consumer service provider 2. Consumer does a “find” on its local engine (using a J-ESI API call) to discover one or more suitable service providers. J-ESI client library More detail on this “discovery” later. engine A engine B

service consumer service provider 3. Consumer sends message to service provider via its local engine. J-ESI client library engine A engine B

service consumer service provider 4. Security library checks access. 5. engine A knows that this message should be sent to engine B, (since it received internal e-speak data from engine B earlier, which told it so). engine A engine B

service consumer service provider 6. engine A sends the message to engine B. (Engines communicate using ABI compatible messages) engine A engine B

service consumer service provider 7. engine B forwards the message to the service provider. 8. Library checks that the request is allowed. J-ESI client library Engine A Engine B

Q: How are new e-services made available to others?
A: E-services are registered by a service provider. Attribute-based lookups discover registered services.

YOU Dynamic Discovery reservation e-service weather e-service SERVICE
PROVIDER travel e-service travel e-service SERVICE PROVIDER airline booking e-service travel e-service hotel booking e-service YOU hotel booking e-service hotel booking e-service airline booking e-service

Discovery options 1. Obtain reference to a service from a local repository “find” call 2. Receive a reference from someone else (e.g., an advertising service) Both of these actions are done by the service finder “find” API (see the ESServiceFinder class document online). 3. A reference may be loaded from persistent store

Advertising and finding
e-service Advertising services are standard services attached to engines (often as default options). They have their own service description repositories. 1. advertise service provider engine

advertising e-service 1. advertise 2. find service provider service
When a service consumer executes a “find” or “findAll” J-ESI API call, as illistrated in point 2. above, searching for a service fitting a particular description, then the engine’s local repository is searched first (iI.e. the repository on the engine identified by the current consumer’s connection - the API user must give this connection as a parameter in an API we will see later). If this “find” fails to find any service descriptions matching the requirement, then the search is carried on again in the repository maintained by the advertising service attached to that engine. The request is sent out to all advertising services, on all engines that have previously located each other. The advertising service keeps a list of such “contactable” other advertising services. The request is therefore being handled in parallel by all advertising services which have received it. In the simple case, these advertising services belong to one named “group” (a term we will see later). service provider service consumer engine engine

3. engine location information
advertising e-service 3. engine location information 1. advertise 2. find Should the advertising service find a service description fitting the requirement, then it passes back the J-ESI library the identification of the engine where the service is registered and advertised. service provider service consumer engine engine

advertising e-service 3. engine location information 1. advertise 2. find service provider service consumer 4. service access engine engine

advertising e-service 3. engine location information 1. advertise 2. find service provider service consumer 4. service access engine engine 5. service result

Where is E-speak a good fit in projects?
Dynamic discovery of services, based on attribute matching, in a set of growing services, either from one or many providers (openness to new services) Establishing communities of use for a set of services Mediation of access to services (access control) Creating a trusted third party between pairs of unfamiliar parties (provider and consumer of service) Comparing services against others Composing services from other services Monitoring of service use Negotiation between services

E-speak Terminology

A Network Object Model Programmer’s Viewpoint
Utility/Community ESConnection ESConnection ESConnection is the J-ESI class that allows any “client” of an e-speak engine to connect to it. “Client” is used in the e-speak documentation to refer to any entity which has a connection to an engine, whether it be a provider or consumer of service, or both. ESService is the base interface for all stubs to remote services. This type is the return type of a “find()” or “findAll()” API and is frequently downcast to the type of the service we want. All service interfaces, as described to the e-speak IDL compiler, seen later, will extend this interface. ESServiceElement is a class which is used to encapsulate the description of a service (An ESServiceDescription instance is used to initialize the ESServiceElement instance) such that it can be registered, advertised and started or stopped. It provides a an anchor or contact point to the engine for the service. Simple management of the service’s lifecycle may be done through this class, such as starting and stopping the service. The curved line between the “service consumer” and “service provider” items in the picture indicate the access through ESService from consumer to provider. Service Consumer ESServiceElement. register() ESService from ESServiceFinder. find() Service Provider

Start of a Request engine Repository (Metadata) Event Subscriber
Service Provider Service Consumer ResourceHandler engine Events Naming Name Space Name Space Router Actions 1. Message created 2. Message Delivered to engine Repository (Metadata)

Name Manager engine Repository (Metadata) Event Subscriber
Service Provider Service Consumer Resource Handler engine Events Naming Name Space Name Space Router Action: Application Names mapped to engine handles via Repository Lookup. Message is then delivered. Repository (Metadata)

Resource Access Control
This is handled outside the engine by the security library The engine does not protect access to any resources that are not “its own” data, that is the service metadata. Protection in e-speak is between two endpoints that manage access rights independently of the engine.

Each connected party has an account
An account contains Folders Compendium of mappings of application-specific names to resources/services Provides complete configurability of application-visible names

E-speak - What is in the download ?
The E-speak “engine”, a platform for mediated access to services, for management and monitoring of services A set of Java APIs that allow the E-speak engine to be used Advertising and event services Security service Management services (Process, Service management) Tools for manipulating the services above Contributed applications (samples, VFS)

Design Principles Uniform representation for resources/services
E-speak engine manages/manipulates representation of resources Resource Identity can be established through attribute descriptions URL’s are also available as Resource/Service identifiers ESAccessor is the way in which programmers identify a service - look at Service ID for security reasons Resource addressability through names - separate from identity Reasoning about Contracts and Attribute Models “Reasoning about Contracts and Attribute Models” means that the service requestor may ask the engine about the various interfaces that a service supports and get to know the methods contained in those interfaces. It may also find out what vocabularies have been used to register the service, what the attributes of those vocabularies are, and, through the ESAccessor class, what the values of such attributes are for a particular registration.

E-speak Terminology Resource Resource Handler
An entity which can be described and used by others The fundamental building block in E-speak technology Used to represent a service Described using attributes Resource Handler A service provider - an active piece of code that registers a service and handles calls to that service

E-speak Terminology Account Contract Vocabulary
Equivalent to a user account or “protection domain” in operating systems; Encapsulation of an active-entity’s environment Has a mapping of the application’s private names to resources/services handles (which are maintained by engines) Every connection to an engine has its own environment Contract Protocol or interface between service consumer and service provider (sometimes referred to as the API of the service) Vocabulary Description of a service in terms of attributes

Service Development using J-ESI

Outline Overview of the e-speak J-ESI APIs
The steps for writing a simple service A first look at the J-ESI APIs for ESConnection ESServiceDescription ESServiceElement e-speak IDL How to describe a service’s interface How to compile an ESIDL file

Using the e-speak J-ESI API
Service providers connect to the e-speak engine describe their service using a vocabulary and a contract (interface definition) create a service, provide an implementation of the contract (interface) register the service (with the engine) start the service Service consumers find the service they want to use by formulating a query in a vocabulary use the service according to its interface

Key API Concepts The engine provides 4 first-order abstractions:
Service Vocabulary Contract View For each of these, the engine offers the following mechanisms: Description -- a way to describe the service, vocabulary or contract Element -- a way to register it Finder -- a way to find it A means of delivering the stub for the resource/service so that it can be used remotely.

Class Diagram: Descriptions
ESBaseDescription addAttribute() getAttributes() getVocabulary() ESServiceDescription ESVocabularyDescription ESContractDescription ESViewDescription equals(...) toString() addStringProperty(...) addIntegerProperty() setInterfaceDefinition(..)

Class Diagram: Element Classes
ESAbstractElement advertise() unadvertise() unregister() update(…) alreadyExists(…) ESServiceElement ESVocabularyElement ESContractElement ESViewElement getAccessor() getAttributes() register() setImplementation(..) start() . . . register() register() register()

Class Diagram: Finders
ESAbstractFinder ESServiceFinder ESVocabularyFinder ESContractFinder ESViewFinder find(ESQuery q) findAll(ESQuery q) getMaxToFind() setMaxToFind(…) find(ESQuery q) findAll(ESQuery q) find(ESQuery q) findAll(ESQuery q) find(ESQuery q) findAll(ESQuery q)

Base Interfaces for All Services - used by the Stubs classes
ESBaseService ESService ESVocabulary ESContract ESView An object of class ESServiceStub, which implements this interface is the return type from ESServiceFinder.find() getProperties() getInterfaceDefinition(…) getInterfaceName(…) add() clear() contains() remove()

Other Interesting Classes
ESQuery ESConnection ESIceptor addConstraint() close() getBaseVocabulary() getDefaultPublisher() getHomeFolder() getSecurityContext() Intercept messages between the J-ESI library and the engine ESXMLQuery ESXMLFile ESCommunity Load into memory and parse an e-speak compatible XML file add(...) listGroupServers() Load into memory and parse an e-speak compatible XML file containing a “find()” constraint

Creating a Service with e-speak

Using the e-speak J-ESI API
Service providers do the following create an interface definition using esidl create an implementation class that does the real work create a “main program” class that drives the registration and implements the startup for the service

The Anatomy of a Service
Service S specifies the implementation for a service describes the service using a vocabulary; AND allows a service to be found by a consumer service description service element The service implementor writes these. SIntf.esidl describes the interface S.java deploys the service; provides description and contract to engine SImpl.java implements the interface (the actual service code)

Writing a Service "S" Create the interface file: SIntf.esidl
Run the esidl compiler Produces SIntf.java, SStub.java and SIntfMessageRegistry.java Create SImpl.java Contains the actual implementation of the service tasks Create S.java Contains the main program for the service Describes a service Ensures that the description for the service is registered Provides a backend implementation of the service (SImpl.java) to the engine Starts the service

SIntf.esidl package x; //choose an appropriate package name - optional
import net.espeak.jesi.*; import net.espeak.infra.cci.exception.ESInvocationException; // Import other packages/classes as needed public interface SIntf extends ESService { // define the methods for the service with appropriate return // types and parameters public void invokeService() throws ESInvocationException; }

E-speak IDL Compiler A set of classes provided with e-speak
Takes an interface definition file and generates a stub for the service from it (along with marshalling code in a registry file) %JRE% /cp:p "%CLASSPATH%;%ESPEAK_CLASSPATH%;lib" net.espeak.util.esidl.IDLCompiler src/HelloServiceIntf.esidl OR java net.espeak.util.esidl.IDLCompiler -classpath %CLASSPATH%;%ESPEAK_CLASSPATH%;lib" src/HelloServiceIntf.esidl (In our lab, the utility file, idlcompile.bat, requires the .esidl file extension)

SImpl.java package x; // optional package name
import net.espeak.infra.cci.exception.ESInvocationException; public class SImpl implements SIntf { // write the methods for the service as declared in SIntf public void invokeService() throws ESInvocationException // method code goes here }

S.java package x; // optional import net.espeak.jesi.*;
import net.espeak.infra.cci.exception.*; public class S { public static void main (String[] args) try // Connect to the e-speak engine (see the following slide) // Register and start the service with the engine } catch (Exception e) { // do whatever you want with exceptions System.err.println(e); } } }

Connect to the e-speak engine
// Connect to the e-speak engine using a property file ESConnection connection = new ESConnection(propFileName); OR // Connect to the e-speak engine using a java.util.Properties object ESConnection connection = new ESConnection(properties); The null constructor ESConnection() has been deprecated, but still works in E-speak 3.01.

ESConnection represents the connection from a client to the engine
has the following properties username password esurl [specifies the communication path to the engine, e.g. tcp:machine.cup.hp.com:12346] protocol hostname portnumber [these properties are an alternative to esurl] accountname

ESConnection interface
ESConnection(propertyFileName) propertyFileName is the name of a file that specifies the parameters for the connection if an user account is specified in the property file, it will be used in the connection (and created if it does not exist) if no account is specified, a transient guest account is used

Create a service description
ESServiceDescription servDesc = new ESServiceDescription (); // Add the attributes of the service to the description // using the base vocabulary servDesc.addAttribute("Name", "service name for S"); Here, we are using the Base Vocabulary to create a description. The attribute “Name” belongs to this Base Vocabulary. Later, we will use domain-specific vocabularies, and see how to use XML to build the service description.

Service Description Attribute Set - Name-value pair that describes resource Preferred notion of finding services in the system Attribute Vocabulary - understands grammar of description Keywords, order of attributes etc. Contract - represents the API of the Service Contracts and vocabularies are covered in detail in module 6 In J-ESI, the contract is a Java-style interface.

Create, Register & Start the Service
// Create a service element, which represents this service to the engine ESServiceElement servElement = new ESServiceElement (connection, servDesc); // Create the implementation and tell the engine where to find it servElement.setImplementation(new SImpl()); // Register the service servElement.register(); // Start the service servElement.start(); This calls a constructor for the implementation class. We may use any of the constructors in SImpl.java

Example: A Classified Ad Service
ClassifiedIntf.esidl Classified.java In this example, an electronic classified advertising service allows you to: place an ad retrieve the list of advertising categories read the ads in a particular category defines the interface for the service: placeAd(String text) getCategories() readAds(String category) the handler for the service registers and starts the service with the engine ClassifiedIntf.java created by the esidl compiler ClassifiedImpl.java implements the interface ClassifiedIntf contains the actual service code

Write ClassifiedIntf.esidl
import net.espeak.jesi.*; import net.espeak.infra.cci.exception.ESInvocationException; public interface ClassifiedIntf extends ESService { public void placeAd(String text) throws ESInvocationException; public String[] getCategories() public String[] readAds(String category) }

Compile the esidl %JRE% /cp:p "%CLASSPATH%;%ESPEAK_CLASSPATH%;lib" esidl.IDLCompiler ClassifiedIntf.esidl OR java -classpath "%CLASSPATH%;%ESPEAK_CLASSPATH%;lib" esidl.IDLCompiler ClassifiedIntf.esidl ClassifiedIntf.esidl These files are generated by the esidl compiler ClassifiedIntf.java ClassifiedStub.java ClassifiedIntfMessageRegistry.java

Write ClassifiedImpl.java
import net.espeak.infra.cci.exception.ESInvocationException; public class ClassifiedImpl implements ClassifiedIntf { public void placeAd(String text) throws ESInvocationException { /* write the code to place an advertisement here */ } public String[] getCategories() { /* write the code to get the categories here */} public String[] readAds(String category) { /* write the code to read the advertisements here */ } } Note that you may want to write one or more constructors for ClassifiedImpl

Write Classified.java import net.espeak.jesi.*;
import net.espeak.infra.cci.exception.*; public class Classified { public static void main (String[] args) { try { ESConnection conn = new ESConnection(propFileName); ESServiceDescription sDesc = new ESServiceDescription (); sDesc.addAttribute("Name", "Classified"); ESServiceElement sElem = new ESServiceElement (conn, sDesc); sElem.setImplementation(new ClassifiedImpl()); sElem.register(); sElem.start(); } catch (Exception e) { System.err.println(e); } } }

Compile and Run the Service
Compile the files: %JVC% /cp:p %CLASSPATH%;%ESPEAK_CLASSPATH%;. ClassifiedIntf.java ClassifiedImpl.java Classified.java ClassifiedIntfMessageRegistry.java ClassifiedStub.java Run the service %JRE% /cp:p "%CLASSPATH%;%ESPEAK_CLASSPATH%;." Classified or java -classpath "%CLASSPATH%;%ESPEAK_CLASSPATH%;." Classified Note : You should have the e-speak engine up and running before running this service

Service Provider Summary
Connect to engine Create service description (in a particular vocabulary) Register the service with engine Start the Service Wait for request Process request Send reply

Setting the CLASSPATH variable
set CLASSPATH=C:\E-speak\lib\escore.jar; C:\E-speak\lib\esclient.jar; C:\e-speak\lib\swingall.jar; C:\e-speak\extern\cryptix\cryptix.jar; C:\e-speak\extern\parser\xerces.jar; C:\jsdk2.0\lib\jsdk.jar (servlet developers kit) escore.jar ~ 408 classes esclient.jar ~ 1378 classes

Using a Service

In this module, you will learn
How to build a service consumer that uses the e-speak API to connect to the e-speak engine find a service by formulating a query in a vocabulary use the service according to its interface

The Anatomy of a Consumer
Developer writes this and uses the interface below Consumer C.java contains the code that uses one or more services The consumer does not register with the e-speak engine. It connects to the engine and uses services -- so it has to know how to find the services, and how to use the interfaces that the services support. SIntf.esidl describes the interface uses generates SIntf.java SStub.java SIntfMessageRegistry.java

Writing a Consumer "C" Obtain the interface file: SIntf.esidl
May be published by a service provider or consortium Could be retrieved by writing the code to find the contract (as we will see in the Vocabularies and Contracts section) Run the esidl compiler Produces SIntf.java, SStub.java and SIntfMessageRegistry.java Create C.java Contains the main program for the consumer Uses the e-speak engine to locate a service that provides the desired interface and matches the desired attributes Uses the service by invoking its methods Compile and run the consumer

C.java import net.espeak.jesi.*;
import net.espeak.infra.cci.exception.*; public class C { public static void main (String[] args) try { // Connect to the e-speak engine (just like the provider code) ESConnection myConn = new ESConnection(propertyFileName); // Find the service // Use the service } catch (Exception e) { // do whatever you want with exceptions e.printStackTrace(); } } }

Finding a service // Create a “finder” object to perform the search for a service. // The second parameter filters so that only services that have the // specified interface will be considered String interfaceName = SIntf.class.getName(); ESServiceFinder servFinder = new ESServiceFinder (myConn, interfaceName); // Create a query object to specify the attributes of the service. You may // search using any attributes you wish ESQuery query = new ESQuery ("Name == 'service name for S'"); // Get the service from the finder, using the query SIntf myServiceObj = (SIntf) servFinder.find(query); If the service was described in a vocabulary other than the Base Vocabulary, you would first need to find the vocabulary and use it to formulate the query.

Using a Service // Use the service myServiceObj.invokeService();

Compiling the Service Consumer code
Compile the files: %JVC% /cp:p %CLASSPATH%;%ESPEAK_CLASSPATH%;. ClassifiedIntf.java Consumer.java ClassifiedIntfMessageRegistry.java ClassifiedIntfStub.java or javac -classpath %CLASSPATH%;%ESPEAK_CLASSPATH%;. ClassifiedIntf.java Consumer.java ClassifiedIntfMessageRegistry.java ClassifiedIntfStub.java Run the service consumer the e-speak engine must be up and running the service should also be registered and running %JRE% /cp:p "%CLASSPATH%;%ESPEAK_CLASSPATH%;." Consumer OR java -classpath "%CLASSPATH%;%ESPEAK_CLASSPATH%;." Consumer

Service Consumer code In the next piece of code, we will be using an
ESVocabularyFinder object, which allows us to find a vocabulary, in the same way we used an ESServiceFinder object to find a service previously (using an attribute-based query) Assumption : we know how to use this vocabulary

Service Consumer Example
import net.espeak.jesi.*; import net.espeak.infra.cci.exception.*; public class Advertiser { public static void main (String[] args) { try { ESConnection conn = new ESConnection(propFileName); try { // Find the vocabulary ESQuery vQuery = new ESQuery("Name == 'AdvertVocab'"); ESVocabularyFinder findVocab = new ESVocabularyFinder(conn); ESVocabulary myVocab = findVocab.find(vQuery); } catch (LookupFailedException lfe) { throw lfe; } continued on next page . . .

Service Consumer Example, continued
// Find the service String interfaceName = ClassifiedIntf.class.getName(); ESServiceFinder servFinder = new ESServiceFinder (connection, interfaceName); // note that this query is created to use the Classified vocabulary ESQuery query = new ESQuery(myVocab, "PublicationName == 'Weekly Planet'"); // Constraint ClassifiedIntf myPaper = (ClassifiedIntf) servFinder.find(query); // Use the service to get the classified ads for cars String theAdds = myPaper.readAds("car"); } catch (Exception e) { // do whatever you want with exceptions e.printStackTrace(); } } }

Service Consumer Summary
Connect to engine Find service Invoke service Handle response from service Now that we have seen both service provider and service consumer sides of the code, we may also have the case where the service describer/advertiser is a completely separate entity (such as a standards body). We can separate the code for description/advertising from the service implementation, if we choose to.

E-speak Fundamentals.

Similar presentations

Presentation on theme: "E-speak Fundamentals."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

E-speak Fundamentals.

Similar presentations

Presentation on theme: "E-speak Fundamentals."— Presentation transcript:

Similar presentations

About project

Feedback