If a provider not provide the whole “cloud stack”, your integration-points will grow dramatically. In addition to your application components, you have to integrate the providers to each another. If N is the number of your components which are to integrate your potential number of integrations points to cloud-provider are = (N x (N -1)) / 2.

In addition each cloud provider has its own strategy – of course worst case scenario, but realistic. This will implicitly influence your release cycle. Bye bye agile approaches. From a deep technical point of view, you have to find solutions for things like names of your environment variables, basic programming constructs like file access and so on.


When searching for the term mashup, i visited my “first lookup”-site: wikipedia (many thanks to all who provide information to wikipedia). Here i found the description “Mashups and portals are both content aggregation technologies“. Ok, aggregating content. This is what for example open-social specifies. But can it be social to aggregate content without pay attention to the (user-centric) processes? From my perspective: not really. But the processes might not be strong structured. I have something like Adaptive-Case-Management in my mind.

Dear reader, what is your opinion? 


Taken from http://websocket.org/quantum.html: Reducing kilobytes of data to 2 bytes…and reducing latency from 150ms to 50ms is far more than marginal. In fact, these two factors alone are enough to make Web Sockets seriously interesting… 

Ok the most questions – from more technical guys- are:

  • “Does it waste my server ports?”. No. A Websocket is a stable, “once” established connection from the client to the server.  Only the client has to keep the connection open. But, the server need to handle something like a “session”. Apache and other do not support such a kind of session.
  • “What is the difference to AJAX or other approaches?”. Ok, first of all the server is able to send messages to the client without getting polled by the client.

Why Python is more popular than other programming languages for “Next BI” issues. Ok there are differences in the syntax, power of string operations or the allocable memory. But, [silent for few seconds] the most business critical issues have mathematical solutions. Solutions like clustering, grouping and so on (check Apache Mahout). I am talking about solutions in the field of linear algebra (for example the k-mean algorithm and so on). Most of them use mathematical matrix operations. And here the mayor -my opinion- difference between programming languages came into the game – the support for matrix-operations. Java (as one of many) does not support these operations natively. Some Java-Specification-Requests started but ended in a early stage.

My conclusion for java is: Some libraries with JDK 1.7 are very close to the performance of native binary – in in many cases better as python. The real power of java is the VM. Java Hotspot JIT compiles “hot” methods to native code and switches to those compiled methods while the program is being run.

Further reading:

Terracotta (http://terracotta.org) replicates changes from one heap to heaps in other VM’s and allows to synchronization and migrate threads across server instances. Let us compare the available solutions a bit.

Message queue approach  Low Yes Medium High
Database approach  medium  Yes High High
“RPC spread” like JGroups or Zookeeper  possible Yes  depend on Medium High
Custom API Low Yes  depend on High High
App Server medium Yes  depend on  Medium Medium
Clustered JVM Medium to high Yes X Low Low

I like this article – don’t be confused how old it is- http://jonasboner.com/2007/01/29/how-to-build-a-pojo-based-data-grid-using-open-terracotta/.


Ok i am only talking about the available a java solutions but the problem might be transferable to other programming languages/enviornments. While extending the memory which is available to a JVM the garbage collector will reduce the overall performance (GC takes time when you put more as 2 GB to a single VM). On the other hand this drawback is nevertheless backed by a “limitless” but -of course- slower disk store.

But – surprise surprise- Java has an out of-the-box solution for it. I am talking about the off-heap memory (term is taken from Terracotta way of wording).

For all these programs, a java.nio.ByteBuffer or Mapped Files

FileChannel channel = new RandomAccessFile(file, "r").getChannel();
ByteBuffer buf = channel.map(MapMode.READ_ONLY, 0L, file.length());

are an alternative to traditional Java objects – 6 x speedup with my testapp. I like this article http://www.kdgregory.com/index.php?page=java.byteBuffer.

.. after playing for couple of hours, the key difference between storm (https://github.com/nathanmarz/storm) and MapReduce (i like Hadoop) is that in MapReduce a job eventually finishes, whereas a topology processes messages forever.