About The Ninja Paths Package
The Ninja Paths Package was developed during Fall '99 by Sirish Chandrasekran, Mihut Ionescu, and Sam Madden as a part of CS262A at UC Berkeley. The Ninja Project is an effort underway at Berkeley to produce a platform for Internet services which provides service authors with reliability of data, high availability of services, and a common infrastructure for communication and composition of services.
Paths fill the latter part of this description by providing a way to compose arbitrary services. Service authors provide an XML based description of their operators, write a small amount of code, and register them with a central operator registry. Paths clients specify an endpoint operator they wish to talk to and a short description of their own output type. The paths package returns a sequence of operators (a "path") which convert that client's output into a format the specified endpoint can understand. The client can obtain a stream from this path, which, when written to in the specified input format, is guaranteed to produce data the endpoint can understand. Similarly, clients can build paths from a specified producer of data to themselves, such that they can understand the data some service produces.
Some examples will clarify:
Imagine that operators exist to convert between French text and English text. Also, imagine that there exist operators which can convert between French speech and French text and English speech and English text. Let's say Bill speaks English, and Jacques speech French, but Bill desperately needs to send Jacques a message. Bill has his cell-phone with him, and knows Jacques email address. So, Bill requests a path from a speech digitizer listening to his cell phone into his SMTP server, which knows how to relay a text message to Jaques, and is indifferent to the language of the message. He specifies that the source of that path (at the digitizer) is English speech, and that the desitination (at the SMTP server), is French text. The Ninja Paths Package locates the English speech-to-text operator, composes it with the English text to French text operator, and returns a path which accepts English speech and outputs French text. When Bill speaks into his phone, French text is fed into the SMTP server, which forwards his message on to Jacques in French.
It's important to note that the Path's package doesn't provide translation services such as this, but provides the infrastructure upon which such services should be built. Service authors aren't required to write complex pieces of code to manage setting up and tearing down of I/O ports or to locate and evaluate their own compatibility with other operators -- the Ninja Path's package handles this automatically. More importantly, service authors aren't required to offer the complete space of data types their service might understand or produce: they describe their service in terms of its native input and output formats and rely on other translation and conversion operators running in operator-space to provide connection-enabling conversion and translation services.
Let's consider another application of paths: imagine you have a PDA with a wireless connection to the Internet. This PDA is capable of receiving and sendingTCP/IP packets, but the OS authors have failed to provide a full-fledged web-browser: you're only allowed to connect to sites which they have specifically formatted for display on the PDA. Perhaps there is a stock-quote service which you particularly like that you don't have access to -- instead of trying to write a native web browser for your PDA, you can use Ninja paths. You request a path from the HTML based stock-service to text formatted for your PDA, which can be displayed via a simple built-in terminal interface. The Paths package locates an operator which can convert HTML to plain-text, and then an operator which knows how to format that text for your PDA and the specifics of its terminal emulator.
How do you query the Ninja Paths service from a device such as a PDA which may not have a Ninja capable Java environment running on it? Use an active proxy -- a software interface which understands and translates simple requests from the PDA into Ninja RMI. As a Paths client, you may have to write such a proxy if your device has never been connected to Ninja before, but doing so will allow you to take full advantage of all Ninja services.
Installing the Ninja Paths Package
Before installing Ninja Paths, you need to have the base Ninja v1.5 package installed. The Paths package relies heavily on iSpace, SDS, and XSet, so you will benefit from familiarilty with these services before continuing. In particular, you will need to have access to or set up an insecure SDS. You can find directions on setting up and using an SDS server as a part of the SDS package, in {ninja-root}/classpath/ninja/sds/help/index.htm.
If you're setting up your own insecure server, pay particular attention to the advertisement interval parameters (we suggest settings sds.server.ServerAnnounceRate to at least 60 seconds) and make sure that you've specified a certificates directory or copied the demo certs directory to the root level of the account which is to run the SDS. We've compiled a brief SDS and Paths Troubleshooting Guide which may help if you still can't get things to work.
The good news is that setting up an SDS server is by far the hardest part of the installation. Here's what's left:
You should now be all set to go. There are a couple of demonstration services --
The first is in the .../path/sample/ directory. It is a very simple demonstration service which converts a sequence of characters from lower to upper case. To run it, do the following:
Verified an ekey!!!!!!!",
followed by a bunch of "getService: ..."
messages.
This tries to build a path from the source operator, which generates lowercase characters, to the destination operator, which accepts upper case characters. If all goes as planned, it will do this by building a path through UpperCaseOperator.
You should messages like the following in Window 1:
Created new UpperCaseOperator thread,
id = 128.32.46.233:949025187438
Read: a
Write: A
Read:
Write:
Read: A
RESULT: A
Read: b
Write: B
Read:
Write:
Read: B
RESULT: B
Read: c
Write: C
Read:
Write:
Read: C
RESULT: C
Read: d
Write: D
Read:
Write:
Read: D
RESULT: D
Read: e
Write: E
Read:
Write:
Read: E
RESULT: E
And messages like the following in Window 2:
SDS system is using 226.125.6.78:6778
for server announcement channel
Looping through an element.
Looping through an element.
Instantiating
Looping through an element.
classURL: http://www.cs.berkeley.edu/~madden/connectors/TCPConnector.class
TestAPCOp: Writing bytes:a
TestAPCOp: sleeping.
TestAPCOp: looping: i = 4
TestAPCOp: Writing bytes:b
TestAPCOp: sleeping.
TestAPCOp: looping: i = 3
TestAPCOp: Writing bytes:c
TestAPCOp: sleeping.
TestAPCOp: looping: i = 2
TestAPCOp: Writing bytes:d
TestAPCOp: sleeping.
TestAPCOp: looping: i = 1
TestAPCOp: Writing bytes:e
TestAPCOp: sleeping.
TestAPCOp: looping: i = 0
What's going on here? Most of the status messages are turned off so it's a bit hard to see, but the TestAPCOp is a simple operator which builds a path to the DestOp (which is writing "RESULT" in Window 1). Since the DestOp only accepts upper-case characters (according to its type description in DestOp.xml), the UpperCaseOperator (which is producing the "Read:", "Write:" pairs in Window 1) is interposed to translate TestAPCOp's lower case output into upper-case.
Notice that it's perfectly legitmate for any of these operators to be running on a remote machine, as long as that machine can advertise its services on the SDS (which requires being within multicast range).
See "Using the Ninja Paths Package" for a complete description of how a service like this works.
Using the Ninja Paths Package
Clients of Ninja paths will want to know how take advantage of several features:
More Documentation
This page created and maintained by madden@cs.berkeley.edu. Last updated 1.30.00.