nk4um

Glad to know the ROC basics tutorial helped.  For sure I am very aware that there is no "what comes next book" that shows how to progress to building stuff yourself.

I''m currently working on a book that uses the WiNK application as the basis to provide just what you''re after.  As soon as I have something presentable I''d really appreciate it if you can give it an early review to make sure it bridges the gap.

Watch this space - later this week (or the week after worst case) it''ll be there!

Cheers,

Peter

I''m an idiot.  This section of the docs does a beautiful job of explaining the exact example I gave of giving a name to part of what the grammar matches and using that as an argument inside the java code:

http://localhost:1060/book/view/book:gettingstarted/doc:gettingstarted:codefirst:request-processing

Seriously the new ROC Basics tutorial in NK4 was a huge help to me, but I have to admit it seems like when I step away from those pre-packaged examples I''m still pretty quickly getting lost.

I''m figuring I need to knuckle down and poor over more of the provided examples that are beyond the "Hello World" stage.

A book that walked the reader through a dissection of such examples would be fantastic.  NetKernel in Action. :)

Otherwise off the top of my head I can say as a newbie the APIs surrounding issuing requests and dealing with arguments and sending responses using the context etc. seem central to things, but there''s enough variations on the types and the methods in the javadocs that if such a book clarified that it would be a huge help to me...

And then yesterday I decided I wanted to give a name to a part of the url (the end of the path), like I saw in the tutorial examples, so I could easily get just that part in my accessor, when suddenly I realized the tutorial example was doing it in an "<endpoint>" whereas I was needing to do it in an "<accessor>".  At which point it dawned on me I wasn''t 100% clear on the difference, and what was/wasn''t valid to be doing in the module XML.  And I''m not sure where in the docs I''d find that.

So yeah I need a book or a tutor or something.  I tell myself there was a time when I didn''t know the servlet APIs either so I shouldn''t expect this to come overnight...  but a book would definitely help. :)

     

Darren,

I read about your NetKernel Adventure and I sort of put a big ''Amen'' next to it. I went through the same Adventure (well, I still am going through it, as I haven''t been able to get NK accepted in my company yet) and it is true that when doing it on your own, the learning curve of NK3 is steep.

On the one hand I keep badgering (is that the correct word ?) Peter that he needs to demystify  NetKernel a lot more. On the other hand there''s of course the fact that there''s a lot of technologies covered. Within one application you may need HTML, CSS, XML, JSON, XSLT, <your favorite development language>,(performant) database access, Ajax ... and hey, that''s only for a standalone application, so why not add some RPC, queueing, jobscheduling, ... Mastering all that is no mean task either.

Keep up the good fight !
Regards,
Tom

Okay message received - no more NK3 it''s NK4 from here on out... 

(I''m lucky right I don''t have to switch like some people I just start with the latest and greatest I gotcha...).

Thanks again,

Darren

The new tutorial is for NetKernel 4.

I would strongly encourage a switch to NetKernel 4.

NetKernel 4, even in preview, is capable of supporting a production application now. We are using it in production. The NetKernel 4 kernel has already gone through more functional and stress testing than the NetKernel 3 kernel has. With our rate of progress, I speculate NetKernel 4 Standard Edition (SE) will be released as a final product in time to support a production application for your company.

-- Randy

Tutorial is for NK4.

NK4 is production ready now.  We''ve given the green light to our existing customers and are supporting them now.

FYI the development of NK4 is now well into its 4th year.  We''ve been in internal production on the kernel for more than 2 years.

So the core platform is stable.  All that''s happening now is we''re pushing hard on making sure the documentation is all aligned etc.  We''re also migrating over the last few of the more obscure NK3 modules to ensure we have equivalent tool set.

The only significant missing feature is the DPML language runtime.  We actually have a declarative sequence language but it is a full functional programming language and we feel it might be overkill for many simple pipeline processing tasks.  So within the next month or so we will be providing both the full functional and a simple sequencing language.

I think/hope you''ll find the learning curve is much lower on NK4 - mainly due to the refinement and self-consistency we''ve introduced throughout.

But we''re here to help and there are plenty of folk in the community who''ve walked the same path before you.  So don''t worry about asking for help.

Peter

Thanks Peter I''ll watch for the new tutorial.

(wasn''t sure if that was for NK3 or NK4 btw.  at the moment I''m doing my little prototype under NK3 thinking NK4 won''t be production ready in time for my company''s needs?).

Thanks Darren - its great to get open honest feedback.

Some of the things you suggest are definitely spot on - we can provide more concrete step-by-step "physical" examples.  Other stuff, like aliasing stuff, is completely possible (see below).  Other stuff is natural to suggest but I hope as you learn more you''ll see is based on trying to bring over the old world to the new.

Anyway, there will be an ROC building blocks tutorial available at the end of the week - it''d be fantastic if you can hold fire till its out and then go all guns blazing at that!

Cheers,

Peter

Thanks Randy.

I had heard about the new DPML in NK4 btw - and I have downloaded the NK4 preview - but I''ve yet to stumble on any examples?  I''m curious to see what the new syntax is like...

Since this is the feedback forum maybe I should step back and say that I''ve just been learning NetKernel in my spare time the last couple weeks, evaluating it for possible use at my company, where it''s dependency cache mechanism could be an improvement over our current Cocoon based system.

In my case, in order for it to be used at my company, I have to be a bit of a salesman in that there are so many tools out there and all of the architects and engineers have their own pet ones and it becomes very political to get something new introduced.  And I will likely be the only one in the company who''s even heard of NetKernel.

So I''m doing a little prototype on my own with it, hoping to demonstrate functionality but also getting a sense of the learning curve for myself, seeing if I feel I can understand things well enough to articulate the benefits of the tool, as well as to become a bit of a teacher explaining examples to the other engineers, etc.

Right now if I were to give some honest feedback just for me personally, I remain excited about the NK''s approach to SOA - I think potentially it could really save time/money/reduce complexity over Cocoon and SOAP etc. at my company.  But if I''m 100% honest, the learning curve for me so far has not been trivial and I''m concerned it might not be for others at my company either. 

At the heart of that, I''m excited and see the potential of NK and I''m confident if I apply myself I''ll get the hang of it, but the other engineers aren''t necessarily seeing it the same way and won''t necessarily be as motivated to push thru the learning curve.

My DSL comments spoke to part of this feeling - in that for me the NK3 DPML tutorial examples sometimes seem very angle bracket laden (e.g. even though I do XSL I''m really not a fan of xml syntax for languages - I do it under duress :).  I think the NK example of invoking Unix commands is an example of that - it''s at the heart a single Unix command line exploded into a lot of XML that makes it hard to read and follow.

It sounds like what''s planned for NK4 changes this but I guess in terms of feedback I just wanted to emphasize that this "learning curve" question for me is truly a very big deal.  It appears to me the way NK is architected could possibly mean it''s a game changer - a Ruby on Rails or an AJAX or whatever - a *big* deal.

My feedback would be that NK is different enough though that I''ve found it a little hard to pick up - at least so far, but I am still a beginner...

As I read the NK4 stuff with the new diagrams explaining "spaces" and "endpoints", etc. I felt like I/others would benefit from some diagrams that were more concrete - i.e. show boxes illustrating the machines that are talking to one another, show the "transports" near the edges of the machines connected to the "accessors" within bubble representing the NetKernel process, etc.

For me right now, I''ve yet to fully "grok" exactly what these concepts mean and therefore precisely what NetKernel is.  I described it as a "service orchestration language" to a coworker the other day.  From a more techie perspective, I guess it''s a (multi-threaded) process that can asynchronously invoke urls on the net, run JVM based "active URI" commands within it''s own process, or exec out and run OS commands.  The idea that all these things focus on generating "representations" of "resources" that you can pipeline together and transform brings the REST ideas together with the philosophy of Unix of combining little building blocks together in a chain. 

Anyway now I''m rambling but it''s this basic question of understandability that I see as the greatest challenge for NK even as I see it''s potential brilliance as "the next big thing". :)

For me my most honest feedback/suggestions for NK4 would be to reduce the learning curve by a.  being super careful about using names that are as easy for people to understand as possible (i.e. "accessor", "endpoint", "space", "transreptor" - all seem fine but maybe newbies would better understand "converter" or something than "transreptor"), b. having really good docs esp. for beginners with diagrams that concretely clarify those names and clarify that "this http request went off to one of Amazon''s servers, and this other http request went to a server that was also running NetKernel as a "symmetric peer", but this active URI invoked a java function right on this machine''s NetKernel, and c.  As we spoke of for DPML, but maybe to some degree even more broadly, trying to make the syntax of everything as short/sweet/simple as it can be.

Regarding the last point, I found the syntax for the "active URI" hard to read for some reason, with the plus signs and at signs and URIs able to be nested as operands of other URIs.  But the xml representation of the same seemed rather long.  And though it''s not addressing anything fundamental, I wondered well could there/should there be a way to define a simple name/alias to such a thing, on the idea that you hide this complexity behind a name, and having added that, couldn''t these simple alias/names be used in a syntax that truly could look much like a Unix shell script with named commands/resources and pipe symbols connecting them?  Maybe just as you "cat" a file in Unix, maybe in NK you "source" a "resource" (which can be indicated by it''s alias "name" or it''s URI directly).

Whew I wrote too much those are all my idealistic thoughts/feedback/suggestions for NK.  I feel like royalty. :)  I want it like this and this and oh by the way please have it done by Monday. :)

Seriously though I do think NK is cool it seems to make possible some things I wanted to do for a long time but thought would take too much time, plus it''s helping me to see/understand certain ideas I''ve had more clearly.  For example for some time I''ve been frustrated by our use of database tables at my company for what is really "read only configuration" data, and the trouble it''s led to esp. because we don''t have any way to "promote" such configurations from Dev to Int to Cert to Prod environments.  And I''d felt for a long time we would be better served by simply storing this information in files, and I''d thought since we use XML so much we might as well use XML files, which led to the thought that I should be able to read those files as a "service" from the Prod environment even if I''m testing code against it in my Dev environment.  NK helps me to see that all of that thinking was very much in the spirit of REST, and NK has the hooks for me (potentially) to do exactly what I''m thinking with a lot less heartache than if I was trying to "roll my own" solution for the same.

If I can get myself up to speed that is. :)

You are not alone! I and others have also been thinking along these lines. (Maybe they will contribute to this thread).

What I believe you are seeing is the opportunity to introduce a light-weight scripting / composition language that ties in well with the logical level ROC abstraction. This is the role that DPML will play in NetKernel 4. We have a prototype version of DPML for NetKernel 4 that was written quite a while ago. We have not included it in the preview distributions because it deserves what the rest of NetKernel has received - a comprehensive review and possibly a fresh implementation - before release as a preview. (I believe this is near the top of Tony''s list of tasks).

Some in the community built DSLs for their application domains in NetKernel 3 (Groovy, JavaScript and maybe another language was used for this) and found them very useful and productive. I anticipate they will think about doing the same in NetKernel 4.

If you have a strong preference for a particular language, I suggest you post a question about developing DSLs on NetKernel 4 in that language to the forum and see if some of the NetKernel 3 DSL developers respond. See what progress you can make and when DPML is released for NetKernel 4 you could compare your results with that language as you will have a strong base of comparison. If you post your thoughts and findings on the forum, I''ll monitor and respond with my thoughts and suggestions.

Thank you for your posts!

-- Randy

Possibly this belongs in the wacky idea file, and I should take a little more time to refine this thought, but FWIW when I first saw a Groovy example for NK like the following:

main()
{
  req = context.createSubRequest("active:fetch-customers");
  customers = context.issueSubRequest(req);

  req = context.createSubRequest("active:xslt");
  req.addArgument("operator", "ffcpl:/scripts/style.xsl");
  req.addArgument("operand", customers);
  output = context.issueSubRequest(req);

  response = context.createResponseFrom(output);
  context.setResponse(response);
}

I thought there''s a great opportunity to streamline things via something like a "domain specific language"/"DSL", operator overloading, or possibly using what they call the "Builder Pattern", etc.

Haven''t looked at such things closely in a while but I think it may be possible to make the above code look something more like the following:

resp = new NKResponseBuilder(context) {

   customers = active:fetch-customers();

   active:xslt(operator: "ffcpl:/script/style.xsl",
               operand: customers);
}

I believe the colon in "active:fetch-customers" or "active:xslt" might be a problem - it could be some compromises would be required like changing them to dots.

But I just noticed I''ve been inconsistent in treating "ffcpl:/script/style.xsl" as a quoted string whereas active:xslt and active:fetch-customers are playing the role of (missing) method invocations.  That''s inconsistent so probably not right...

Another tack would be less of a "builder" and more of a true DSL - maybe something like:

resp = context.do {
  customers = request active.fetch-customers
  output = xsl.apply ffcpl."/scripts/style.xsl" to customers
}

Truthfully I know how to do DSLs (with Groovy) just enough to be dangerous I''m sure there''s others who could clarify better what is/isn''t possible with the above, but I do know that things somewhat like the above are possible.

And Ruby does have similar capabilities though the implementation is a bit different.

Interesting to think that even DPML might have taken an approach similar to this?  i.e. Not a special DPML language but simply DSLs built atop Groovy or Ruby?

With the comparisons made between NetKernel to Unix pipes - maybe a DSL could be created overloading the pipe symbol and/or the << or >> symbols ala C++ streams?  i.e. To take the Unix pipes/streams analogy to the max! :)

Just a thought...