|
NetKernel News Volume 5 Issue 15
December 5th 2014
- Repository Updates
- modules.d/ @devmode
- Prag Pub - ROC Special Issue
- Just how old are Micro-Services?
- NEW: Quick Start
Repository Updates
The following updates are available in the NKSE and NKEE repositories...
- layer0-1.110.1
- Added @devmode to modules.d/ module daemon to support dynamic reload of a complete collection (see below)
- hds-g2 1.5.1
- Improved thread safety when concurrently accessing a key()
modules.d/ @devmode
The file must have a .xml extension and have the same format as the master [INSTALL]etc/modules.xml, so something like this...
<module>...file:/ URI of the module to load...</module> ... as many modules as you like...
</modules>
I use modules.d/ to manage all my collections of modules.
The beauty of modules.d/ is that you can deploy a collection by adding the file and very easily undeploy the collection just by changing the file extension.
For example, say I have a collection of modules for a portal solution then I might have a file:
etc/modules.d/portal.xml
when I want to decommission the set, I just rename its file extension to .xml.hide
etc/modules.d/portal.xml.hide
As soon as the file loses its .xml extension then the complete collection of modules it references are decommissioned by the modules.d/ daemon.
Dynamic Commissioning
When you point to a module that is expanded (ie not in a jar file) then provided you've marked it as <dynamic/> then NetKernel will automatically recommission it whenever the module.xml file changes, or there are new class files detected.
This means that, if you set up your IDE to compile its build products to the same location as the source code, you will instantly see your changes reflected into the live system.
Continuous development with "zero shutter lag".
Unfortunately development tools are not generally designed to expect this instantaneous deployment - they create build/ directories and worse still they often produce a static jar file as their result.
For reasons to do with limitations in Java, you can't dynamically and continuously deploy jar files. So if you're developing using tools like gradle or maven then the resulting jar file will be static and you'll need to manually tell NetKernel to reload it.
One way you can do this is to give it a new version number. Another is to temporarily hide and then reveal your modules.d/ file that has the declaration pointing to your built module jar file.
But neither of these is a very satisfactory solution!!
So today we've added an update to the modules daemon that enables a "developer mode". If you add an attribute @devmode="true" to your <modules> tag...
<module>...file:/ uri of the module to load...</module> ... as many modules as you like...
</modules>
then the daemon will consider that any change to that declarative collection's file is an indication to recommission the complete set of modules referenced by it. For example, say I have my portal modules in...
etc/modules.d/portal.xml
then with @devmode enabled, I can simply change the timestamp of the file...
touch portal.xml
and the complete set of modules will be decommissioned and recommissioned as a set.
So its now pretty easy to make your build tool (whatever you prefer) touch the collection (or just overwrite the daemon managed file) at build time and regain something close to the continuous deployment you get if you have an unjarred module with src/ and build/ products co-located.
Gradle Plugin
If you use the gradle plugin, we've updated the deployModuleXXX task to use @devmode by default.
You might also like to know that the gradle plugin (unlike most development tools) always builds a "live expanded" copy, as well as a jarred copy of any module.
So, say you have a module built using the gradle plugin with uri "urn:org:netkernel:foo" and version "1.1.1" then
gradle build
Will create a full expanded module in the local build folder...
build/urn.org.netkernel.foo-1.1.1/
You can point your NetKernel modules.d/ entry to this and NetKernel will treat it as a live continuously deployed module. So now a "gradle build" is instantly deployed - zero shutter lag!
Prag Pub - ROC Special Issue
We're very pleased to report that this month's issue of Prag Pub has a cover feature on Resource Oriented Computing. Here's their announcement...
"This issue focuses on Resource Oriented Computing, an approach to software development that makes your apps work like the Web. Brian Sletten, Ron Hitchens, and Tom Guerdens will get you up to speed on the philosophy, principles, goals, and practice of ROC."
The articles by Ron, Brian and Tom provide an excellent perspective on how we have arrived where we are.
The articles range from highlighting the limitations of Object Oriented (the first article: "Your object model sucks" - glad you didn't go with a provocative title Ron!), through why "Micro-services is not the answer" (further provocation by Brian to encourage people to step away from APIs and understand that with services its not about Code its about the Resources!).
Thankfully, to calm things down, Tom has provided an introductory article with some first steps to exploring NetKernel and ROC.
Prag Pub's editor, Michael Swaine, offers his own thoughts in his editorial...
For half a century, we’ve been building software that makes certain broad assumptions about operating systems versus applications and data versus code. For the past quarter of a century, we’ve been deploying a lot of that code in a space that makes its own, somewhat different, assumptions: the World Wide Web. Yet the code underlying today’s web apps usually doesn’t look all that different from the earliest C code that Dennis Ritchie wrote.
It’s not that there haven’t been new and empowering paradigms. Object Oriented Programming burst on the scene with some deep and powerful ideas about messaging... but then, because people took its name too seriously, it became all about objects and classes.
Resource Oriented Computing grew from that same root, but kept the focus on messaging. The result is that, in Resource Oriented Computing, the relationship between code and data becomes more balanced and respectful, and distinctions like application program versus operating system become academic.
Resource Oriented Computing takes its inspiration from that extremely long-running and infinitely scalable and incomparably successful software project, the World Wide Web. It is a new/old paradigm that asks the question: shouldn’t your app work the way the Web does?
If the answer to that last question is affirmative, then ROC is where you arrive when you consistently (self-consistently even) stick to the path where "Everything is a resource..."
Please grab a copy, to show thanks to Prag Pub for their great support and interest in ROC...
http://theprosegarden.com/contents-of-recent-issues/#12-14
OK Brian, I never actually said it, but hell I will now...
Just how old are Micro-Services?
Tom Mueck pointed out a little historical nugget...
Here is a video of a much younger version of me talking about NetKernel at Web Services Edge in February 2005. Coming up for ten years ago!
Take a look at this slide, especially the first bullet point...
"Software components are micro-web-services addressed by URI".
Back to the Future indeed...
NEW: Quick Start
We've put together a new quick start Github project as a way for developers to get set up really fast, here's how its described on the main site...
The GitHub getting-started project provides everything you need to get going really fast. Clone it and follow the 3-steps outlined in the readme...
- Build a getting started module
- Use gradle to install a copy of NetKernel, deploy the module and start NetKernel
- Set up an Eclipse project and start playing
Requirements:
You don't need to download NetKernel in advance. All you need is a copy of Gradle and a Java JDK installation.
In one minute you'll have built your first module, installed NetKernel and be playing with the code in Eclipse...
In fact its even simpler than that, if you clone the project and change directory to module/urn.org.netkernel.helloworld/ then this one liner:
gradle installNK startNK build deployModuleNK eclipse
Does the following...
- Downloads and install's a fresh copy NetKernel
- Start NetKernel for continuous deployment
- Build the hello world module
- Deploy it as a dynamic deployment to NetKernel
- Create all the boilerplate for Eclipse ready to "Import an Existing Project..."
- You can now edit the code in Eclipse and it will be instantly deployed to NetKernel
Please give it a try and let us know if you have other ideas for ways we can utilize the power of the gradle plugin to smooth the learning curve.
Have a great weekend! I'm off to put some trash in the "Mr Fusion"...
Comments
Please feel free to comment on the NetKernel Forum
Follow on Twitter:
@pjr1060 for day-to-day NK/ROC updates
@netkernel for announcements
@tab1060 for the hard-core stuff
To subscribe for news and alerts
Join the NetKernel Portal to get news, announcements and extra features.
NetKernel will ROC your world
 |