gpoul's Out Of Memory Blog

Last week we announced that IBM Business Process Manager V7.5 will eGA on June 3, 2011, and GA on June 17, 2011.

WebSphere Process Server and WebSphere Lombardi Edition support will be discontinued between 2013 and 2016, depending on the version.

I’ve never really thought about the backend systems when using my smartphone, but with more and more people using mobile internet devices to access sites the load patterns will be impacted. While during normal operation the load is spread nicely throughout the day, when large events occur sites will be hit by a huge number of clients simultaneously. Billy Newport describes those FlashLoads in his latest blog post.

Using the WS-BPEL 2.0 standard with WebSphere Integration Developer:

The IBM products WebSphere Integration Developer (hereafter called Integration Developer) and WebSphere Process Server (hereafter called Process Server) support the majority of the concepts of WS-BPEL 2.0. However, some of the WS-BPEL language elements in Integration Developer and Process Server Version 7 are still using the syntax defined in the preliminary BPEL4WS 1.1 specification. Many of the language differences are purely related to the WS-BPEL syntax, while the runtime semantics of the affected language elements is identical. For example, in the WS-BPEL 2.0 standard, the switch and terminate activities have been renamed to if/else and exit, respectively, while keeping their semantics exactly the same.

As a result, when business processes are modeled in compliance with the WS-BPEL 2.0 standard, manual rework is necessary before these processes are consumed by Integration Developer and Process Server. To substantially reduce this rework, this article describes an import tool that transforms the affected WS-BPEL 2.0 language elements into semantically equivalent language elements understood by Integration Developer and Process Server V7.

Logging is one of those things that sounds easy, but is incredibly hard and complex to do properly. Especially if you have to debug applications in production it is hard to decide which log entries to have in your code and which ones are too much overhead to include. These 10 Tips for Proper Application Logging are definitely a good resource to start thinking about whether you’re doing it right or where you might be able to improve. [via TSS]

Recently I came across a fairly interesting paper about Large-scale Incremental Processing Using Distributed Transactions and Notifications written by two Googlers, Daniel Peng and Frank Dabek. (Proceedings of the 9th USENIX Symposium on Operating Systems Design and Implementation, 2010)

Most of the stuff was interesting, but not applicable to what most people will have to work with, unless you try to work with a massive dataset… like… let’s say building an index of everything on the web.

One of the most interesting parts for me was the following paragraph:

Our experience with thread-per-request was, on the whole, positive: application code is simple, we achieve good utilization on many-core machines, and crash debugging is simplified by meaningful and complete stack traces. We encountered fewer race conditions in application code than we feared. The biggest drawbacks of the approach were scalability issues in the Linux kernel and Google infrastructure related to high thread counts. Our in-house kernel development team was able to deploy fixes to address
the kernel issues.

Anyone who worked with web applications, dealt with web security, or single sign-on will certainly have learned that HTTP cookies, while a simple concept, have many complex intricate behaviors that even differ between browser implementations. What’s making things worse is that there is no real written specification that documents the design behavior. In his recent post on HTTP cookies and protocol design Michal Zalewski outlines many of these intricacies and design behaviors and I’m sure you’ll learn about a few you haven’t seen before ;-)

On Monday we announced that IBM will join the OpenJDK project. If you’re interested in why this decision was taken and what this means, you definitely want to read Bob Sutor’s blog post on this change in direction.

One major part is the decision that “IBM will be shifting its development effort from the Apache Project Harmony to OpenJDK” and that there will be changes to the JCP “to make it more democratic, transparent, and open”, although it seems to be unclear what concrete steps will be taken.

Henrik Ståhl posted a few details about Oracle’s future plans on his blog, but apart from the fact that we’ll finally see a Java SE 7 and Java SE 8 JSR, there is not too much of substance to report. We’ll see whether that gets more concrete over the coming months.

It turns out that the JDK 7 development project is delayed quite a bit and the current estimated ship date is now Mid 2012. Given this delay Mark Reinhold is currently looking for feedback on a proposed Plan B, which would only include certain parts of Coin, NIO.2, InvokeDynamic (JSR 292), and “JSR 166y” (fork/join, etc.) in JDK 7 and delay everything else until JDK 8.

The estimated ship date for this Plan B would be Mid 2011 with JDK 8 being delayed an additional 6 months with a ship date in Late 2012.

I’m not a huge fan of releasing two major JDK releases within two years when the most current release is already almost 4 years old, but it seems like that’s what Oracle is currently leaning towards.

Comments on this post are closed, please post your feedback directly on Mark’s blog.

Update 9/21: Plan B is now the plan of record.

The WebSphere Application Server V8.0 Beta is now available.

Update 7/9: Andrew posted that the download is now fixed and he also included some helpful links to get started with trying the beta.

Every wanted to script Google services? Then you’ll have a lot of fun with GoogleCL, a Google command line tool based on the GData APIs.