Transreptor DevelopmentTransreptor Development
A guide to developing universal resource transreptors
Home > Books > NetKernel Extensions > Transreptor Development

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


Transreptor - What and Why?

When an accessor services a SOURCE request it will return a representation of a resource with an associated aspect that may be of any type that is convenient to it. If the requestor has specified a specific aspect in the request then NetKernel attempts to locate a transreptor that can take the available representation and transrepresent it into a representation that includes the specified aspect.

One very important point is that transreptors never transform or alter the information contained by a resource, they only change the interface that provides access to the information of the resource: a transrepted resource still has the same URI as the original and may be transrepted again in the future.

Invocation

Transreptors may be invoked in one of the following ways:

  • Explicitly from a TRANSREPRESENT request. This is an explicit request to locate a transreptor that can take a given representation and transrepresent it.
  • Implicitly from a SOURCE request. When a representation for a URI is located (either from an accessor or from cache) and it does not have the required aspect available to it, an implicit TRANSREPT request is initiated.
  • Chained where one transreptor may initiate another.

Resolution

Transreptors are resolved within the context of the module which initiated the request. First all transreptors within this module are tested to see if they are suitable, then all imported modules are tested recursively. If no transreptor is found then the resolution process steps up the request call stack. If no transreptor is found an No Transreptor Found exception is raised.

Development

The class org.ten60.netkernel.layer1.nkf.impl.NKFTransreptorImpl is provided as a superclass for transreptor development. The transreptor implementation subclass must provide implementations for the following methods:
methoddescription
boolean supports(IURRepresentation aFrom, Class aTo) Returns true if this transreptor can return a representation with the given aTo aspect if presented with the given representation aFrom.
void transrepresent(INKCovenienceHelper context) throws Exception Perform the transrepresentation - described in detail below.

Implementation

The implementation logic for the transrepresent() method generally follows these steps:

  • Get the source aspect from the request. A TRANSREPRESENT request always passes the aspect to be transrepted on the request with the system URI (INKFRequestReadOnly.URI_SYSTEM).
  • Create the alternate aspect result using data from the primary aspect.
  • Create a response using the new aspect
    INKFResponse resp=context.createResponseFrom(result);
  • Set any metadata on the response, for example:
    resp.setCreationCost(12);
  • Set the response back on the context
    context.setResponse(resp);

Issuing subrequests

While generally not necessary, transreptors may issue sub-request (for example, to perform some validation or to have access to some configuration data).

The context object may be used to source resources and issue sub-requests in exactly the same way as with Java Active Accessor development. Requests will be issued into the module address space of the module hosting the transreptor.

Supplied Transreptors

NetKernel ships with many transreptors. Their source code is provided in the hosting modules.

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