DataNucleus AccessPlatform 3.1.0 released

Sky-Tiger

To meet the new features of cloud computing available soon in Java EE7 and particularly that of multitenancy (sharing an application by several entities called tenants), JOnAS proposes to deploy an instance of the application per tenant in the server. This feature is available in the current SNAPSHOT of JOnAS 5.3.0 M7.

Thus, it will be possible to deploy several instances of the same application in the same JOnAS application server. Each instance is associated to a tenant identified by a unique ID. Application data will be customized per tenant whithout any changes in the application. This allows to isolate tenants in the application server but also in the management console where each administrator has access to the data of its tenant.

Sky-Tiger

While some developers have found that using Node.js simplifies their code and adds significant time and cost-savings to their ongoing projects, other developers say "Node.js is stupid."It stands to reason that if a programming language is loved by some and hated by others that it probably does some things very well and other things very poorly. The trick for senior developers and software architects is to understand which projects will benefit from a new system like Node.js.

To learn more about the best use cases for Node.js, we talked with software development guru James Strachan. Please enjoy this short video. A full transcript of the video is included below, for your convenience, as well as a brief biographical statement about Strachan.

Sky-Tiger

Javascript has been such a success story that some have asked "Why just on the client? Why not use JavaScript on the Server?"

I think a lot of us old Java guys have to get out of the habit that everything's on the server now – in many ways – everything is on the client. In our day, there wasn't really that much on the client. Well – going way back everything was on the client – but then it moved over to the server and now it's sort of coming back to the client again – or most things are.

The server side is becoming thinner and thinner. The server side might just be Amazon Simple DB or Mongo DB or something; there might not be much of a three-tier architecture anymore. But the client side is becoming bigger and more and more complex; it's real-time now, everyone's doing Ajax, real-time updates, and people are doing lots of single-page applications – which is one Web page starts up and the entire app is in there. There's lots of models, containers, relationships and persistence and yada-yada. So JavaScript is really where the action is in terms of the platform.

In many ways the browsers won. Almost every mobile platform has Web capabilities inside it – Android, iPhone, iOS all have Web browsers and so forth. So the Web has kind of won, but most browsers use JavaScript and HTML 5. Silverlight's dead, Flash is kind of dying, user interfaces now and going forward – the browser is really where it's at with HTML and JavaScript.

Tangent to this is, everyone is compiling JavaScript to something else – even the JavaScript programmers. Nobody writes JavaScript and deploys it into production. You compile it into something. In development, even if you're using JavaScript, you combine it into a minified, combined single java script file. You might have a hundred JavaScript files and libraries and modules and you compile it all into one minified file. So everyone's compiling their JavaScript, even the JavaScript folks, right?

Sky-Tiger

Minified?

Minified. Or encoded or what-have-you – you've got to use JSLint because JavaScript also has bad parts – and so forth. A really good alternative to raw JavaScript is CoffeeScript which really is a pretty beautiful language. It's dynamically typed. But apart from that, it's a really nice language.

Personally – if you're doing a smallish implementation, dynamic typing is kind of fine, but when you get into huge scale – I'm a static typing kind of guy. When I'm working on a big application/project/code base, I find that the benefits of static typing and navigation and refactoring add a huge amount of benefits to maintain the software.

So the question I'd like to ask is – now I'm envisioning an application development manager that has a great development rock star come in and the rock star wants to do Node.js for the server-side thing – how does that manager figure out if it's wise or not?

If you're writing lots of JavaScript on the client, then using JavaScript on the server makes total sense. Node.js makes total sense to me; it allows you to do lots and lots of JavaScript on the client, reuse it on the server, the server is often fairly small because all the work is being done on the client. You're often doing all your templating and rendering on the client side because it's Ajax, it's all realtime now, so the client is doing templates and rendering, but sometimes you do some on the server, although not so much these days. So it makes total sense.

Sky-Tiger

There are various factors that can be considered when selecting an appropriate collection for a particular problem. These factors are:

Ordering - Some sort of ordering in the elements. For example, sorted order, insertion order or no specific ordering.
Duplicates - May or may not want to allow duplicate elements in a collection.
Thread Safe - Ensure the safety of the elements in a collections in case there are multiple threads accessing it.
Key-Value pair - Store in key-value pairs.
Blocking operations - Wait for the collection to become non-empty when retrieving an element.
Random Access - Instant retrieval of an element.
Upper Bounds - To limit the maximum number of elements a collection can hold.
There are also other factors like priority, delay etc..

Sky-Tiger

The main type of collections are:

Sets
Lists
Queues
Maps
Maps are not an integral part of the Collection framework, but they are still considered as Collection because of their capability to store and manipulate data as collection of objects.

Sorted Sets and Sorted Maps are basically a sorted version of Sets and Maps.

Sky-Tiger

I recently wrote a news story on SearchSOA.com about SwitchYard replacing Jboss ESB. Click that link to read the full article if you want more details. The basic story is that SwitchYard is going to replace JBoss ESB in the JBoss SOA Platform 6. SwitchYard has some significantly better tooling and design compared to the old JBoss ESB, most notably Camel routes. It's possible that Red Hat's newly acquired FuseSource Talent may be able to bolster SwitchYard even more, but that's pure speculation.

Most of the information in the SearchSOA.com article comes from Keith Babo, who is the project lead for SwitchYard. "JBoss ESB 4 is the existing ESB. SwitchYard is fundamentally JBoss ESB 5," he told me, and continued, "Integration is a fundamental part of any SOA project." Babo was good about giving technical details and factual examples (with maybe a pinch of hype). But he's obviously a bit biased by his closeness with the project.

Sky-Tiger

Most of the information in the SearchSOA.com article comes from Keith Babo, who is the project lead for SwitchYard. "JBoss ESB 4 is the existing ESB. SwitchYard is fundamentally JBoss ESB 5," he told me, and continued, "Integration is a fundamental part of any SOA project." Babo was good about giving technical details and factual examples (with maybe a pinch of hype). But he's obviously a bit biased by his closeness with the project.

I'd really like to find out what real users are doing with this new integration project. I know that some folks are already using SwitchYard, or at least playing with it, because they're posting in the JBoss forums for SwitchYard. But so far, I haven't gotten a good sit-down with a user and I'm starting to get the impression that there aren't that many out there yet.

Sky-Tiger

I'd really like to find out what real users are doing with this new integration project. I know that some folks are already using SwitchYard, or at least playing with it, because they're posting in the JBoss forums for SwitchYard. But so far, I haven't gotten a good sit-down with a user and I'm starting to get the impression that there aren't that many out there yet.

I don't think ESBs in general have fallen out of favor. I know that the old JBoss ESB has a reputation for being sort of hard to start into. Do you think that might be keeping folks away? Is the name change stirring up confusion with railroads and electrical substations? Maybe I'm just not looking hard enough. Is your team using SwitchYard? Do you know one that is? Had you heard of SwitchYard before this article? If so, let us know your impressions of the new JBoss ESB.

Sky-Tiger

SwitchYard has adopted the service component architecture (SCA) approach. According to Johnson, the SCA is a long specification with a plethora of smaller sub-specs. "SwitchYard hasn't focused on meeting every single minor spec, but it does get to the core of the spec."

The tooling, meanwhile, is intended to further aid adoption by allowing architects and developers to capitalize on skills they've already learned. "You already have skills," says Babo "and SwitchYard is meant to let you use those skills to build SOA applications via Camel routes, Drools, BPMN and other tools, along with the SwitchYard visual development."

The SwitchYard team aims to abstract away the nitty-gritty details involved in integrating those tools to build applications, and then deploy them via JBoss AS7, OpenShift for the cloud, a regular old Tomcat server or a variety of other runtime environments.