Hello World!
Your first application in NetKernel is very simple.
It returns a text document with the content "Hello World!" to your browser.
Run it by requesting this URL
http://localhost:8080/workbench/helloworld/helloworld.idoc
.
Note: If you are behind a corporate firewall you may need to set your proxy settings here
since
the Hello World text is actually being requested from a remote web server.
What is happening? It might not look like it but the response you saw was generated by executing a script.
NetKernel comes with a pre-installed directory you can use to experiment in. The
directory is called the workbench and it is physically located
at [install]/modules/workbench where [install] is the file path where
you installed NetKernel. The workbench is configured so that scripts and other
code will run when they are requested with a browser request - just like, for example, PHP scripts in Apache or IIS.
The workbench can be accessed with your web browser by making requests below the path
http://localhost:8080/workbench/. Sub-directories in the workbench are part of the URL path.
For this first example the URL has a sub-path /helloworld/helloworld.idoc. If
you look in the workbench directory you will see a sub-directory helloworld which contains a
script helloworld.idoc. This is the script that you just ran.
Next, let's see how the helloworld.idoc script works.
helloworld.idoc
The helloworld.idoc script is shown below. It may look strange at first because of the XML syntax:
<idoc>
<seq>
<comment>
***********
An instruction to SOURCE the uri and return it as the response of this script
***********
</comment>
<instr>
<type>source</type>
<uri>http://www.1060.org/tutorial/helloWorld.txt</uri>
<target>this:response</target>
</instr>
</seq>
</idoc>
In fact, it is quite straight forward. It has one instruction which is requesting
a resource from a specific URL and returning that resource as the response of the script.
Stripping away the XML syntax, you are left with a source
request for a specific resource identified by the uri. The resource
is then set as the script's response by setting this:response as the target for the instruction.
The script's response is returned to your browser and so you see the hello world
text.
To see that this is a live script try editing the script and change the URI of the
resource to be sourced. Try a file: URI to a text file on your hard disk - on Windows this would
be something like, file:///C:\something.txt and on Unix, file:/home/user/something.txt
What happens if you use a relative URI? Try setting the URI to just helloworld.txt
Though it is very simple, this helloworld script is revealing quite a lot about how NetKernel works.
NetKernel is an environment in which all resources, both local and remote, are located by URI. You
will see in a moment, even executable code is called by making URI requests.
Hello Active URI
NetKernel enables URIs to be used to call executable services. URIs which invoke
services are called active URIs. Lets try an active URI. Look at the script helloactive.idoc
in the workbench directory...
<idoc>
<seq>
<instr>
<type>source</type>
<uri>active:toUpper+operand@http://www.1060.org/tutorial/helloWorld.txt</uri>
<target>this:response</target>
</instr>
</seq>
</idoc>
You can run this script with the following URL
http://localhost:8080/workbench/helloworld/helloactive.idoc
This script is nearly the same as helloworld.idoc, it is sourcing a URI and setting the response for the browser. However this time the script sources an active URI.
Sourcing this active URI invokes the toUpper service, which applies an
uppercase transformation to text.
Active URIs consist of a base part which identifies a service, in this case active:toUpper
followed by any number of named arguments. Named arguments are delimited by plus signs '+'. Here the active URI has one named argument called operand - it is separated
from its value by an at sign '@'. The value of a named argument is also a URI, in this case it is the URL you requested earlier: http://www.1060.org/tutorial/helloWorld.txt
Try changing the value of the operand argument to the file:/ URI you tried in the previous exercise.
In summary, active URIs can be used to execute services. NetKernel comes with many service libraries and active URIs are used to dynamically link these
services into solutions. However you might be thinking active URIs are verbose and not something
you'd want to write by hand but help is at hand...
Hello DPML Language
So far you have had to take on trust what the idoc scripts have been doing. In fact these scripts are written in the DPML language.
which is a simple language for constructing and issuing active URI requests. Each instruction <instr>
is translated to an active URI request. To see this examine the hellodpml.idoc in the helloworld directory...
<idoc>
<seq>
<instr>
<type>toUpper</type>
<operand>http://www.1060.org/tutorial/helloREST.txt</operand>
<target>this:response</target>
</instr>
</seq>
</idoc>
You can run this script with the following URL
http://localhost:8080/workbench/helloworld/hellodpml.idoc
This script make the same active URI request as in the previous example. You can see that the type element corresponds with base-part active: URI service.
Each additional element provides a named argument on the active URI. The value of the named argument is the URI contained in its element.
Try changing the value of the <operand> to the file: URI you used previously.
You will see that DPML is one of a choice of languages and that active URIs can be issued from all
scripting languages on NetKernel.
Hello REST
The picture that is emerging is one in which URI addressable
services and resources can be scripted to form solutions. The URI requests are apparently magically
resolved by NetKernel - in fact there is no mystery, NetKernel implements an operating environment
which generalizes and extends the foundational principles of the Web architecture.
NetKernel implements a resource oriented processing system which extends the
REST architecture
.
All resources on NetKernel, even executable code, are located by URI.
In doing so, software solutions on NetKernel acquire the same properties of scalability and adaptability
as the Web itself.