AccessorAccessor
Home > Books > Getting Started > Quick Introduction > Code First > Accessor

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


Code First - Accessor

As we just mentioned, a NetKernel Accessor is similar to a Java J2EE Servlet. However, there is one crucial difference. A servlet operates completely within the physical world of objects while an accessor resides within a logical address space.

In the following diagram notice that each accessor is physically connected to only the internal microkernel. There are no physical connections between accessors. However, since each accessor is mapped to one or more logical addresses, there are logical connections. One accessor may call on the services of another by issuing a sub-request for a logical resource mapped to that accessor.

In the next code example we expand on our HelloWorld accessor and show a server-client pattern in the accessor HelloWorldSubRequest. While this accessor acts as a server for the in-bound request it acts as a client when it issues a logical sub-request to get necessary information to fulfill its operation.

In the full HelloWorldSubRequest accessor class that follows we see that when it receives a request, the first thing it does is construct and issue a sub-request for the resource located at the address ffcpl:/src/helloworld.txt. It then combines the text from this resource with a local message to create a new String object. This new composite resource is returned as the accessor's resource representation in the response. Run this example: http://localhost:8080/tutorial/helloworld-java.

import org.ten60.netkernel.layer1.nkf.INKFConvenienceHelper;
import org.ten60.netkernel.layer1.nkf.INKFRequestReadOnly;
import org.ten60.netkernel.layer1.nkf.INKFResponse;
import org.ten60.netkernel.layer1.nkf.impl.NKFAccessorImpl;

import com.ten60.netkernel.urii.IURAspect;
import com.ten60.netkernel.urii.aspect.StringAspect;

public class HelloWorldSubRequest extends NKFAccessorImpl
{
  // Call super class constructor and indicate that this
  // accessor is threadsafe and will only accept SOURCE requests
  public HelloWorld()
  { super(SAFE_FOR_CONCURRENT_USE, INKFRequestReadOnly.RQT_SOURCE);
  }

  public void processRequest(INKFConvenienceHelper context) throws Exception
  {
    // Create a sub-request to obtain a portion of the message
    INKFRequest subrequest = context.createSubRequest();

    // Set the logical address of the message resource
    subrequest.setURI("ffcpl:/src/helloworld.txt");

    // Set the type of resource representation desired
    subrequest.setAspectClass(StringAspect.class);

    // Issue the request into the logical address space
    IURAspect aspect = context.issueSubRequestForAspect(subrequest);

    // Unwrap the text message
    String message = ((StringAspect)aspect).getString();

    // Append our portion of the final message
    message = message.concat(" from Java");

    // Create an immutable StringAspect wrapper for our text message
    aspect = new StringAspect(message);

    // Create a response object containing the StringAspect
    INKFResponse response = context.createResponseFrom(aspect);

    // Set metadata indicating the MIME type of the response
    response.setMimeType("text/plain");

    // Tell NetKernel that this can be kept in the internal cache
    response.setCacheable();
  }
}

While we have not yet explained how the logical request issued by a browser is routed to our code, this example does show physical code suspended in (or located in) a logical address space. To illustrate that we are not limited to the local address space, change the accessor code to direct the sub-request to retrieve a remote resource:

// Set the logical address of the message resource
subrequest.setURI("http://1060.org/upload/helloworld.txt");

and reissue the request that runs the code. You can see how, unlike a servlet or a restlet, a NetKernel accessor is both a client and server within its logical address space.

The HelloWorld accessor class resides in a module. A NetKernel module is the fundamental unit of resource and code management. From a Java code perspective a module is a container which uses a custom classloader. As mentioned earlier, the tutorial module is located in the directory [install]/modules/tutorial/.

Because the tutorial module is marked <dynamic/> NetKernel will detect changes in Java files and then will decommission the module, reload the module, compile any changed Java files, create a new classloader for the module and reload and run the requested code. While NetKernel does this hot restart it continues to accept requests so this process is transparent to clients. In a production 24x7 installation NetKernel can update modules while a system is in operation. NetKernel keeps track of module versions and can simultaneously run different versions so that legacy code can run next to updated code seamlessly

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