NetKernel News Volume 1 Issue 37

July 23rd 2010

What's new this week?

• NTLM proxy testing updates.
• Updates to WiNK wiki application.
• ROC "demo1" available.
• Migrating from NK3 to NK4.
• Last chance to register for Skillsmatter talk, download preview of the presentation material.

Repository Updates

http-client: Thanks to feedback from Kevin Ansberry, we're working through teething issues with NTLM proxy support. An updated http-client can be installed via apposite.

But this is a chicken and egg situation, so if you're behind an NTLM proxy then apposite won't work and you'll need to install the updated client by hand. Download the module here...

http://resources.1060research.com/packages/2010/7/urn.org.netkernel.client.http-1.7.12.jar

...and place it in [ install ]/modules/ then edit [ install ]/etc/modules.xml and change the entry for http-client to point to the new 1.7.12 jar.

wink: The WiNK wiki application has been refined. It now features full text search. We also changed the way it deals with SVG's so that legacy javascript doesn't get bamboozled by the previous strict XHTML mode. [As a side topic - I predict that strict XHTML javascript will forever remain completely unusable].

The change away from strict XHTML conformance was necessary to enable general javascript AJAX based macro libraries. Of which, we'll soon be sharing, a Slidy macro extension module that enables you to create and extend Slidy presentations inside the managed/searchable WiNK wiki (for details see http://www.w3.org/Talks/Tools/Slidy/#%281%29 ).

demo1: This is a new demo that allows you to show ROC concepts by issuing simple resource requests into a prepared demo playground. For example you can access the upper case set of all web resources (such as google) with

active:toUpper+operand@http://www.google.com

The demo framework could easily be adapted to import your own spaces etc.

NK3 to NK4 conversion notes

With NK4 nearly a year old and in stable daily production and with NKEE having one foot out of the door, we know that a number of existing NK3 sites are looking at migration. I was asked this week if we have a porting guide. Well here's a quick set of rules of thumb and notes for how we've migrated previous NK3 modules to NK4.

First thing to note with NK4 is that the power and capability for architecting the module address space is much richer than NK3. Spend some time playing with NK4's module.xml and make sure to read the logical development guide.

NK3 had an essentially static fixed spacial architecture consisting of an optional set of rewrite rules at the edge of the address space, followed by accessor's and imports. All resolution and request transformation was done with regular expressions including the binding of accessors into the address space.

In NK4 the hard-coded architecture of NK3's module.xml is now much richer but is still readily implementable as an architectural pattern. You can exactly replicate NK3's spacial architecture with a rootspace containing a single mapper. The mapper having inside it a space with your accessors and imports.

Instead of regex's you now use the NK4 Grammar language for writing request resolution bindings. And instead of a rewrite you can use the mapper to construct mapped requests into the inner space - using the declarative request syntax.

Replicating the NK3 spacial architecture is relatively straightforward, but you may find you don't even need this and can place your accessors straight into the NK4 rootspace. You'll also find that NK3's convoluted recursive rewrite nesting that was required to create functional style accessor sequences (for example wrapping requests with sessions etc) are now much simpler with NK4's overlay technology.

You'll also need to know about the differences at the physical API level. For the most part, the conceptual model and design of the NKF API is the same. However we have done a lot of tidying up and refactoring of the interfaces - generally just syntactic changes to aid the conceptual relationship with the ROC abstraction.

So here's a rule of thumb process that we went through in migrating NK3 libraries to NK4...

1. Accessors now use the grammar technology to be bound into the address space rather than a regex. The <active> grammar is usually what you'll want to use for most NK3 accessors that used default active URI request processing. 2. To convert an NKF Accessor from NKF3 to NKF4 change the base class to extend

org.netkernel.module.standard.endpoint.StandardAccessorImpl

and work through IDE errors - these will mostly be syntax changes. The key thing is that processRequest () is replaced by onXXXX events for each verb.

INKFRequestContext is the new name for the NKFConvenienceHelper - but it is essentially the same (though enhanced). It gives access to the incoming request, can constuct and issue sub-requests, creates and manages return of response.

Here's a very simple worked example with differences described in the comments ...

/**Old NKF3 Code*/
//Old imports not shown for clarity
public class JSONToXML extends NKFAccessorImpl
{

       /** Creates a new instance of JSONFromXML */
       public JSONToXML()
       {    super(false, INKFRequestReadOnly.RQT_SOURCE);
       }

       public void processRequest(INKFConvenienceHelper context) throws Exception
       {    IAspectJSON ja=(IAspectJSON)context.sourceAspect("this:param:operand", IAspectJSON.class);
           String jx=XML.toString((JSONObject)ja.getJSONObject());
           StringAspect sa=new StringAspect(jx);
           INKFResponse resp=context.createResponseFrom(sa);
           resp.setMimeType("text/xml");
       }

}

//**New NKF4 Code*/
import org.netkernel.module.standard.endpoint.StandardAccessorImpl

public class JSONToXML extends StandardAccessorImpl
{
       /** Creates a new instance of JSONFromXML */
       public JSONToXML()
       {    //super(false, INKFRequestReadOnly.RQT_SOURCE);  this is now redundent
           //Verbs are detected from the onXXXX methods of base class
           //Threadsafety etc is declared with the declareXXXX() methods eg
           this.declareThreadSafe(true);
       }


       //processRequest redundant - should now override verb specific events
       //public void processRequest(INKFConvenienceHelper context) throws Exception

       public void onSource(INKFRequestContext context) throws Exception
       {    //INKFRequestContext has same basic model as old ConvHelper

           //Arguments are now dereferenced from the request using "arg:xxxx"
           //Aspects and Representations are no longer necessary - can use POJOs
           //But old Aspects can be retained if you want
           JSON ja=context.source("arg:operand", JSON.class);

           //Some imple code...
           String jx=XML.toString((JSONObject)ja.getJSONObject());

           //StringAspect sa=new StringAspect(jx);  //no need can return POJO
           INKFResponse resp=context.createResponseFrom(jx);
           resp.setMimeType("text/xml");
       }
}

Notice that the actual physical implementation logic is usually completely portable between NK3 and NK4. The only thing of difference is that NK4 no longer demands that representations be wrapped in IURAspect and instead allows POJO representations. You do need to take care that the POJO is immutable, or at least, only used in read-only ways by your other endpoints.

Converting Transreptors follow a similar pattern. But now it is much easier to handle the to/from class comparison since these can be declared in the constructor with

this.declareFromRepresentation(xxx.class); this.declareToRepresentation(yyy.class);

As a rough estimate of effort, when you've done one or two and got the feel for it we find it takes about 10 minutes to convert an NK3 accessor to NK4.

Of course directly porting NK3 modules to NK4 will not exploit the full richness of the new abstraction and the enhanced capabilities of NK4. To go beyond simply replicating what you have, then book some training and we'll get you fast tracked over to NK4's general ROC abstraction.

If you need help getting your old systems migrated let us know. And, of course, for a modest fee we're happy to provide a professional conversion service!

NetKernel and the Resource Oriented Cloud

A reminder that I'll be presenting the latest on NK, the NK Protocol and ROC at SkillsMatter in London this coming Monday, the 26th July. Its a free evening event, but you need to book your place:

http://skillsmatter.com/event/cloud-grid/netkernel-and-the-resource-oriented-cloud

A copy of the slides I'll use are available here (for those that came to the web run-through, these are updated with better diagrams of the NKP demo architectures I discuss)...

http://resources.1060research.com/docs/2010/07/NetKernel-NKP-ROC-Cloud.pdf

You can play with the basic ROC request demo, which I use during the scene-setting first part, by installing "demo1" using apposite.

Summer Special Training Offer

The 33% training discount is still available...

If not now, with all the fabulous things you can do with NK clouds /via NKP, then when will be the right time to get your black-belt in NK? It takes just 2-3 days of instructor-led training for an existing Java developer /architect to get fully productive building scalable ROC solutions on NetKernel. So, to give you a leg up the learning curve, we're offering a Summer Special 33% discount on training.

Ping an email titled "NetKernel Summer Special" to services@1060research.com if you want to find out more

Have a great weekend.