1060 NetKernel adds JMS connectivity


News: 1060 NetKernel adds JMS connectivity

  1. 1060 NetKernel adds JMS connectivity (10 messages)

    1060 Research have posted an updated NetKernel v2.0.1 distribution which provides a new JMS connectivity module.

    There are several new architectural patterns which this enables. NetKernel can be used as a primary message dispatcher server - aggregating and pre-processing transport intiated events and sending them out as messages to a JMS bus. Equally NetKernel can be a highly scaled JMS peer - listening on topics and queues and executing message-driven-services.

    1060 NetKernel is a general-purpose Java-based software infrastructure. The NetKernel microkernel uses a REST-like addressing model combined with foundational concepts from Unix to enable composition of software applications and pipelines from internal URI addressable software components.

    For more information, including open-source download please visit http://www.1060research.com

    Threaded Messages (10)

  2. Forget SOA, forget ESB, forget the grids. The new buzzword is ... JMS! Definitely!
  3. Forget SOA, forget ESB, forget the grids. The new buzzword is ... JMS! Definitely!

    Andreas, once again first to comment and once again you fail to add anything useful what so ever. I don't know what you actually do at SwiftMQ, other than sitting waiting for TSS postings, but it would help if you read the articles before you comment.
    I saw the NetKernel a few months ago and didn't take the time to read through the details of what it is. I've now just done that and it looks interesting enough to download it (which I've just done).

    Has anyone used this yet? If so what for? It looks pretty flexible but I wonder if it's not a solution looking for a problem, a rather neat solution though. I hope people have some interesting problems this can be applied to.

    I'd be interested to know if there are any "problems" where this is a obvious fit i.e. are there cases where this is an obvious choice over alternatives.

  4. Andreas, once again first to comment and once again you fail to add anything useful what so ever. I don't know what you actually do at SwiftMQ, other than sitting waiting for TSS postings, but it would help if you read the articles before you comment

    Hmm, rather it seems that you're waiting that I post to comment on it. I did 2 postings the last month. You may compare it to your own posting history.

    I don't remember that I heard anything useful from you guy. All you do is ass-kissing the B-proms here and begging for a beer and of course shameless self promotion to get out of your poor tutor job. So don't comment on my postings, buddy. Just don't read it. You will not get a beer from me and I'm not interested to have you in my ass.
  5. You will not get a beer from me and I'm not interested to have you in my ass.

    This is *not* what I come up to TSS to read. I'm beginning to think less and less of this site. Can't we just stick to topics of interest here? Sheesh.
  6. This is *not* what I come up to TSS to read. I'm beginning to think less and less of this site. Can't we just stick to topics of interest here? Sheesh.

       You're right, apologies for being part of this, the second part of my posting was a question aimed at serious readers of this thread.

    Can anyone give me some interesting uses/examples for the 1060 NetKernel, it does look quite interesting.

  7. 1060 NetKernel adds JMS connectivity[ Go to top ]

    I doubt there are many people on TSS who have direct experience of using NetKernel yet - basically because before the 2.0 release it betrayed its origins and was heavily oriented towards declarative XML processes. 2.0 is now a general-purpose operating environment and we're seeing a growing number of customers using it in some pretty diverse applications. A bit of history might help...

    NK started out in HP as a research project to develop an XML processing infrastructure - around '99 we were beginning to understand that whilst we could develop application specific XML message processing systems (irrespective of external application protocol etc) the solutions weren't economically viable - the proliferation of XML object models and APIs meant we ended up with very tightly-bound systems - this was a problem, because the X in XML stands for 'extensible' but it meant 'change' (to the backend processing system and data models). So we were aiming for an infrastructure that could be dynamically reconfigured to cope with the realities of the dynamics of business data encapsulated in XML.

    We started off building a very XML-centric system - it worked OK but wasn't as general as we'd hoped. Over the last few years we've thrown 3 away, always trying to generalize the fundamental driver for a dynamically reconfigurable infrastructure.

    We eventually realised an architecture in which software components are URI addressed services - higher-order applications and services are composed from lower-level services and abstracted behind their own URI interfaces. So software systems in this model acquire similar properties to the WWW - dynamically reconfigurable, horizontal and vertical scaling, cacheability. Probably most significant was emergent robustness and tolerance to change - though we were really surprised by what happens to performance in a REST-based computation system.

    Because every service can be described by a URI (we have developed an extensible URI syntax called the active URI which allows a URI to be a functional program) it is a unique vector to the result, be it computed or cached - this scales so that as one service uses another the composite is still a URI vector to the result. In short you end up with a processing system where the minimal computational cost to process a resource is almost guaranteed - kind of systemmic optimisation.

    At the heart of this is a REST microkernel - it doesn't matter that it's REST, this isn't a religious thing - basically the NK kernel provides a Web addressing system married to Unix-like processes.

    All sounds extremely academic and complicated right? Well in practice you don't have to care about the low-level details of how the kernel works - apps are written in a wide range of languages from Java, through dynamic languages (Beanshell, Groovy, Javascript, Python) and we have some simple declarative languages for sequencing components (kind of like a declarative shell).

    Sorry for the length of this, back to the original question. What can you do with it?

    As you'd expect given the history, it is very simple to create adaptive XML processing systems. Trimondo - a JV between Lufthansa and Deutsche Poste are using it as the message processing engine in their B2B portal.

    NK is a transport-neutral peer so we have another customer using it for a global P2P food tracking system - this integrates bar-code scanners and wireless networks with custom messaging and the JXTA P2P protocol.

    Other customers are doing: multi-lingual XML integration systems, facilities risk-management in the oil industry, VoIP soft-switches etc.

    Of course because it has a web addressing model at its heart, its pretty seamless to create web-applications.

    Sorry for such a long answer - it looks sad when you provide your own testimonials but wer'e at an early stage, I'd be sceptical too and want to know these things especially given the usual industry marketing hysteria over new technologies. The best answer to your question is to suspend disbelief for an hour, kick the tyres and see if the model makes sense to you.


    Pete Rodgers
    Architect 1006 NetKernel

    PS For those who're interested in some technical detail - the Jetty folks just posted a case-study on the NK architecture and the Jetty HTTP transport: http://jetty.mortbay.com/
  8. 1060 License[ Go to top ]

    I think that a viral license would fit better an application than an application server. I think your concepts are interesting, but I would never be able to convince my company to release an application with an os license.
    This would prevent a lot of people from working with your technology and I don't think this would be any good.
    Your choice, BTW, I just wanted to raise the matter.
  9. 1060 License[ Go to top ]

    That's a fair comment. We thought long and hard about our license and our business model - in essence there are three ways to operate an open-source infrastructure software business.

    1. Give away the code but tightly control the knowledge of how to build and distribute a system. User pays for the system and maintenance as an ongoing service cost. This is the linux distro's model.
    2. Give away the code but restrict the documentation and/or detailed knowledge of administration. User pays for
    the system knowledge and maintenance as an ongoing service cost. This is JBoss' model.
    3. Virally propogate your license to the end-users code. User pays for commercial license or subscription to alleviate OS obligations. This is the MySQL, Sleepycat model.

    We created a license that virally propogates for changes to the core system but allows the end-user to select their prefered OSI license for their own code - kind of a liberal GPL. Basically we request you to open-source your code if it runs on NetKernel but you can choose your prefered OSI license. The OS community get an unrestricted free and open product with no restrictions on system knowledge or documentation.

    Commercial realities dictate that many organisations will want to retain control of their code - this is reasonable since code embodies business rules and relationships - it'd be naive to think companies can expose this in public, the world doesn't work like that. For these cases we offer flexible commercial licensing or subscriptions and offer reasonable rates - our model works by reputation, so we're not going to try to gouge anyone.

    Everyone gets an open infrastructure with increasing value as more open applications appear on it. Open users get to have fun and play for free. Commercial users get the sureity that the product is robust, defect-free and has no enforced upgrades or product obselence. We get to make a living. Win, win, win.

    Well that was our thinking anyway ;-) So far, with our early adopters, its working very well with a good cross-section of open, closed and mixed licensing.


  10. 1060 NetKernel adds JMS connectivity[ Go to top ]

       Thanks for your detailed reply, I've just had a bit of a play using XML and XSL and I like it, some very interesting ideas and features and quick to use. I still have reservations about everything being a REST-based but I'm warming to it.


  11. 1060 NetKernel adds JMS connectivity[ Go to top ]

    I think I should have made something clear earlier - when we say 'REST-based' we don't mean HTTP with GET,POST,PUT etc. The NetKernel microkernel uses a transport-independent generalization of REST to provide a URI-based abstraction for invoking *internal* software components.

    One way to think of this is that NK provides a simplification of JMX - there are many valuable consequences of the URI addressing model like scale invariance, dynamic reconfigurability, multiply-locatable interfaces and intrinsic dependency-based caching.

    However this is all the internal architecture of the kernel - you can build reconfigurable software applications
    without any knowledge of how the internal execution takes place.

    The thing about internal service-based application composition is that you can very easily expose any part of the application to an external application protocol/transport (eg SOAP, REST, Mail, JMS etc) and at any level of granularity - so you end-up with applications that are intrinisically adaptive to your distributed system's architecture.

    You could summarize it as, whilst the industry has been concentrating on defining an external distributed SOA
    technology stack, NetKernel has applied the broad principles inwards to provide a transport-neutral internal SOA software infrastructure which makes handling the messages a whole lot more adaptive and which you can put behind your prefered distribution architecture.