Hello WorldHello World
First Hello World application
Home > Books > Tutorials and Training Guides > Getting Started > Hello World

Rate this page:
Really useful
Satisfactory
Not helpful
Confusing
Incorrect
Unsure
Extra comments:


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.

© 2003-2007, 1060 Research Limited. 1060 registered trademark, NetKernel trademark of 1060 Research Limited.