Then Google came along and launched their Java version of their Cloud environment(Google App
Engine). Since this one seemed to be easy and free to try, I decided to give it a try with the tutorial. ( App Engine the java platform , so not only the java language is supported, but languages like groovy and jruby also work, but I stayed with ‘just’ Java)  

Within a time span of 5 to 10 minutes I had registered my cloud application and was ready to get started. The registration is not much different than for a Gmail account. Then I decided to install the eclipse plugins, this also worked as a charm.
Next, I generated a GWT App engine project with hello-world example code and pressed deploy and my ‘hello world’ was running in the cloud.

The total time taken for this test run was less than 15 minutes and additional applications would be deployed even faster because the environment is all ready installed.

The benefits of this over a normal hosting provider for me are ease of use (the java hosting providers i am used to take a lot more time for installing a build), and scalability (the app engine requires you to work in way no local file access to enable distributed computing which enables them to scale your application).

And just as an exercise I decided to port a normal small java project of mine into my cloud project. Not much had to be changed, the local property file access was replaced by a classpath resource, and I had to hack my way into GWT which i never had used before. And that last part cost me the most time.

For the few interested in my IMDB profile compare tool see: http://film-freak.appspot.com/ It’s supposed to help film freaks compare which films they both saw and which the other didn’t saw. (If you have an imdb vote history you need to make it public first before you can use your profile number, and some large profiles are not handled right but the feature this service uses is not yet supported by IMDB)

Is the app engine flawless? yeah, well even though app engine comes with a local environment that resembles the real app engine, I had a bug that occurred in the real one but not the local one. The bug was related to the character parsing of the app engine (the bug is still in my application btw)

Also this application didn’t use the datastore, but I heard quite some troubles with the use of frameworks and standards (JPA) on the appengine. To summarize this; the appengine has a special datastore, BigTable, which is fast but not a RDBMS, and to use JPA or JDO plugins for frameworks have to be created and the quality of those plugins define what part of JPA and JDO is available and at this moment this seem to be quite limited. Maybe later this year I’ll take some time to play around with this datastore.

Also see:
http://www.theserverside.com/news/thread.tss?thread_id=54919

http://groups.google.com/group/google-appengine-java/web/will-it-play-in-app-engine

The first day we had some discussions about what DDD is and how it relates to normal Object Oriented Design. This led to some very interesting discussions, that helped a lot at creating a shared view on what a model is and what design is and what DDD is. Although I can imagine that a bit of background in OOD was a prerequisite in order to participate in these discussions.

To make a long story short; the center of domain driven design for us was: a design strategy where the design of the application is centered around the (problem) domain of the customer, written down in a model with an Ubiquitous Language and that this domain model should be used as a language among all/most stakeholders. Also noted as important, was the emphasis on the refactoring of the model, the agile iterative approach for creating this artifact. With this definition the difference with OOD is that DDD is broader, it favors the agile development approach and at the same time it is more strict (it gives more guidance in how your class model should be created). So some of us realized that parts of the DDD philosophy were already part of their current process.

The second session was a ‘modeling out loud session’ where we created a model for a business case using the theory of the first session. This also led to better understanding of the patterns of DDD with entities, value objects, services, repositories and factories. During this session our definitions of these patterns were refined, and also the gap between these abstract terms and for instance the Spring Framework was crossed. This held back the progress of creating the model for the business case, but of course led to a deeper understanding of the material. Eventually, with the help of the experienced DDD trainers, we made a nice domain driven design for the business case. And all participants received a copy of Eric Evans’ DDD bible so they can further expand their knowledge on this subject

More info on domain driven design can be found here.

( Logica employees interested in these kind of sessions should contact the manager of the Java IDT competence, but be aware that most sessions are very popular and the number of available places are limited. Other workshops that are coming up: Spring essentials, jQuery and Java Performance Tuning ).

See this link for more info on the takeover http://www.sun.com/third-party/global/oracle/index.jsp

On the other hand there has been a lot of fuzz about the release of java 7, for instance closures are not likely to enter java after all in java 7, but all kinds of other things are. See this link for more information about java 7 . Also take notice of project coin where developers brought in some very interesting ideas (small improvements) for the new java version.

J2SE 1.4.2 is in its Java Technology End of Life (EOL) transition period. The EOL transition period began Dec, 11 2006 and will complete October 30th, 2008, when J2SE 1.4.2 will have reached its End of Service Life (EOSL).

This doesn’t mean that Sun doesn’t support Java 1.4 anymore - with Sun’s Java SE for Business you can get up to 15 years of support for older Java versions.

However, if you’re on a project that still uses Java 1.4 you should really upgrade to Java 6, if you have any say into which Java version is being used. Besides the new features added in Java 5 and 6, you’ll enjoy the performance enhancements and bug fixes.

If you’re a Java programmer and you still didn’t learn the new Java 5 features… then you’re in trouble.

The SCJP exam for Java 1.4 has been discontinued this month.

I will try to give more insight into PA by using a more formal approach. In the section below I will use the definitions “success state” and “system” a lot. I will define these first:

Success state: P_1 and P_2 and … P_N

P_x (1 <= x <= N) is a predicate, for example: P_1 == (All timesheets employees are submitted), P_2 == (All submitted timesheets are correct).

System: S

S => P_i and P_i+1 and … P_i+m and Q_j and Q_j+1 and … Q_j+n

where P_i and P_i+1 and … P_i+m is a subset of our success state P_1 and P_2 and … P_N

Q_j and Q_j+1 and … Q_j+n are additional predicates, not in our success state.

Instead of system you can also read solution. A system can be an already existing system or something that can be built. To illustrate the difference between traditional strategies and the PA strategy, we will do a step by step construction towards an at first unknown success state T_success. We will start from an empty state T_empty.

Traditional strategy 1:
Step 1) Design new component C_1.
Step 2) Check new state T_1 with customer: is this state the success state? Yes: done, No: proceed.
Step 3) Design new component C_2, connect C_2 to C_1.
Step 4) Check new state T_2 with customer: is this state the success state? Yes: done, No: proceed.
Step 5) Design new component C_3, connect C_3 to C_2 and C_1.
Step 6) Check new state T_3 with customer: is this state the success state? Yes: done, No: proceed.
…

The first strategy starts building new components, one at a time. After each component is finished we check if success state is reached. This is not unlike many hobby projects where you start from scratch and build a component at a time. Once you are happy with result you have reached T_success.

Traditional strategy 2:
Step 1) Apply systems S_q, S_q+1, … , S_q+k (short: S_q’) to T_empty.
Step 2) Check new state T_k’ with customer: is this state the success state? Yes: done, No: proceed.
Step 3) Design new component C_1, add this component to S_q’.
Step 4) Check new state T_k1′ with customer: is this state the success state? Yes: done, No: proceed.
Step 5) Design new component C_2, add this component to S_q+1′.
Step 6) Check new state T_k2′ with customer: is this state the success state? Yes: done, No: proceed.
…

The second strategy starts from a combination of, most likely existing, systems. We then add components one at a time. After each component we check if we have reached the success state. This is a way of building systems which is used often when adding functionality to legacy systems.

Traditional strategy 3:
Step A.1) Apply a permutation of systems S_q, S_q+1, … , S_q+k (short: S_q’) to T_empty.
Step A.2) Check new state T_k’ with customer: is this state a good enough approximation of the success state? Yes: proceed to B.1), No: proceed.
Step A.3) Apply a different permutation of systems S_q, S_q+1, … , S_q+k (short: S_q1′) to T_empty.
Step A.4) Check new state T_k1′ with customer: is this state a good enough approximation of the success state? Yes: proceed to B.1), No: proceed.
Step A.5) Apply a different permutation of systems S_q, S_q+1, … , S_q+k (short: S_q2′) to T_empty.
…
Step B.1) Design new component C_1, add this component to previously found near success system permutation S_q”.
Step B.2) Check new state T_k1” with customer: is this state the success state? Yes: done, No: proceed.
Step B.3) Design new component C_2, add this component to previously found near success system permutation S_q”.
Step B.4) Check new state T_k1” with customer: is this state the success state? Yes: done, No: proceed.
…

The third, somewhat less traditional, starts by finding a good combination of systems. This combination should give a good approximation of the final state the customer wants to achieve. Only then you start adding new components.

Classic PA strategy:
Step A.1) Create a definition of T_success, called T_success’.
Step A.2) Check T_success’ with customer: is this state the success state? Yes: proceed to B.1), No: proceed.
Step A.3) Change the definition of T_success’ resulting in a new definition called T_success1′.
Step A.4) Check T_success1′ with customer: is this state the success state? Yes: proceed to B.1), No: proceed.
…
Step B.1) Directly derive definitions of components C_1, … C_u from best definition T_success”.
Note that C_1, …, C_u => P_1 and P_2 and … P_N must hold.
Step B.2) Match components C_1, … C_u with systems S_q, S_q+1, … , S_q+k.
Step B.3) Choose best matching(s). For these matchings T_success” must be a subset of resulting state T_matching.

PA first creates a state definition as close as possible to the success state. It then reviews and alters this state iteratively. Only when the definition is satisfactory the next phase starts. In this phase component definitions are derived from the success state definition. These component definitions are then matched with systems and the best matchings are chosen. Simplicity is important in PA: we always strive for a correct succes state with minimal size.

Note that the first two traditional strategies have no real focus on the final success state. This means that during development the chosen success state might actually be (a lot) different than the real success state. The biggest difference between the third strategy and the PA strategy is that in PA we disregard existing systems (read: solutions) until a really good success state definition has been found. Also, we extract as much information as we can from the success state definition. We then use this information to define components. Each component definition should represent a part of the success state. These component definitions should be mutually exclusive (i.e. no overlap) and all component definitions together should imply the success state. Next we match the component definitions with all known systems and come up with the best matchings. Classic PA is almost done here. We now compare the best matchings and present them, with cost figures, to the customer.

As mentioned earlier an important aspect of PA is the separation of the success state from any solution. This is important because of the reduced effort needed: anyone involved in the process can just think about the success state and can forget about (existing) systems. Depending on the number of systems this can be a serious advantage.

When there are only few solutions and the customer really doesn’t know what he or she wants, starting from an existing solution and building from that is the way to go. However, when there is one clear success state and many possible (existing) solutions PA will shine.

• [1]: http://www.procesacceleratie.nl/

The idea behind SOA is actually very good. It loosely couples the service and the front-end, thus separating our concerns. The term seperation of concerns (SoC) was first introduced by Edsger Dijkstra about 35 years ago. The Wiki has an interesting qoute on SoC [2]:

“All programming paradigms aid developers in the process of improving separation of concerns. For example, object-oriented programming languages can separate concerns into objects, and a design pattern like MVC can separate content from presentation and data-processing (model) from content. Service-oriented design can separate concerns into services.”

In this context SOA really looks like the next step in programming.

Assuming your company is planning to “go SOA” in near future, what challenges await?
Here are some of the implications that come to mind when using SOA:

• use of external services means higher internet bandwidth usage
• exposure of internal services to external companies means additional security measures become necessary
• using just a single connection to external services means a higher chance of losing messages
• use of possibly badly written external services means additional infrastructure and code measures, such as timeouts, become necessary
• when chaining services complex behaviour can emerge and message based testing tools are highly advised

Using SOA we also have to be more aware of:

• connection failure
• message loss
• service failure

By using a polling mechanism we could improve our awareness, but the transition to a Service Oriented Architecture will still be a step-by-step process [3], where we will learn by doing.

• [0]: http://www.finalist.com/content/19787/hot_or_not_contest_vermaakt_bezoekers_j-fall_
• [1]: http://www.nljug.org/jfall/
• [2]: http://en.wikipedia.org/wiki/Separation_of_concerns
• [3]: http://it.toolbox.com/blogs/the-soa-blog/soa-benefits-challenges-and-risk-mitigation-8075

Subject: “Extreem RAD : Live Web Applicatie Ontwikkeling met Oracle Application Express”
Pro: Roel Hartman
Office: Arnhem, the Netherlands
Date: 28 oktober 2008

Subject: “Standardizing SOA with Oracle’s Application Integration Architecture”
Pro: Adri Greeve
Office: Rotterdam
Date: 13 november 2008

Subject: “Practical Approach to SOA Adoption”
Pro: Edwin van Dis
Office: Amstelveen
Date: 27 november 2008

Register for a Pro4Pro session

On Monday the 20th of October Logica has invited Thomas Erl to speak on the Principles of Service Design and Patterns to transform the most important challenges into a successful realization of a Service Oriented Architecture. Business analyst, functional designers and architects will gain new valuable insights on the modeling of services and supporting architecture.

About Thomas Erl:
Thomas Erl is the world’s top-selling SOA author, Series Editor of the “Prentice Hall Service-Oriented Computing Series from Thomas Erl” (www.soabooks.com), and Editor of The SOA Magazine (www.soamag.com). With over 95,000 copies in print world-wide, his books have become international bestsellers. His most recent titles “SOA Design Patterns” (www.soapatterns.com) and “Web Service Contract Design and Versioning for SOA” were co-authored with a series of industry experts and are being released in the latter half of 2008.

Thomas is also the founder of SOA Systems Inc. (www.soasystems.com), a company specializing in SOA training, certification, and strategic consulting services with a vendor-agnostic focus. For more information, visit www.thomaserl.com.

Program
18.00 uur Welcome & diner
19.00 uur Welcome speach
19.15 uur Thomas Erl – ‘How to overcome the key challenges within SOA’
20.30 uur Drinks

The presentation will be in English of course.

Location
Logica, Prof. W.H. Keesomlaan 14 in Amstelveen

There is more info on the Logica site (in Dutch). You can also register (”aanmeldingsformulier”) there.

The keynote today was held by Richard P. Gabriel and Guy L. Steele, Jr. It was… strange. Very, very strange. Bizarre, in fact. The two of them went through the history of programming languages in a colourful slideshow spiked with music and video clips and singing and ringing on cowbells. They didn’t talk but recited, like they were reading poems instead of giving a tech talk. Bizarre, just bizarre. I couldn’t quite decide if it were madness or genius. So I suppose it must be art.

Session 1: Five Considerations for Software Developers by Frank Buschmann and Kevlin Henney
I attended this session mostly because of Kevlin Henney. I listened to one of his talks last year and it was hugely entertaining, as well as insightful. This session wasn’t quite that entertaining, but it had a lot of good content. The five considerations were: Economy (strive for minimalistic solutions), visibility (your ideas should be visible in your code), spacing (keep separations between domain, services and infrastructure), symmetry (keep the code clean and balanced) and emergence (do not build too much explicit control in your code, let it emerge instead).

Session 2: LEGO Develops a new robotics platform WeDo
This session was a disappointment. It was not a presentation on robotics or WeDo or LEGO’s vision for robotics in the future, or much of anything, really. Most of all it was a presentation of LEGO as a business, and of LEGO’s business processes. As if the audience was a group of business managers, and the speaker was trying to sell stocks. I should have attended Kevlin’s second talk instead.

Session 3: Real-world Refactoring by Neal Ford
This was another session with a lot of content. It’s hard to summarise what he said in just a few sentences, but I’ll try anyway. First of all, he presented two principles to keep in mind when refactoring: The composed method (break down large methods into smaller well-named methods until it reads like a series of steps in an algorithm) and SLAP (keep the same level of abstraction in a method). Next, he gave us two things to be cautious about: Dependencies on third-party frameworks and spider web dependencies among our own classes. In addition, he talked about detecting duplication in our code with the tool cpd, avoiding duplication of code in tests, doing large refactoring on branches and doing ‘scary’ refactorings of brittle code. Lastly, he advised us to use code metric tools to discover when and where to use refactoring.

Session 4: Patterns of Internal DSLs by Martin Fowler
Martin Fowler is another of my favourite speakers. He always speaks loudly and clearly and I always feel as if I learn something when I’m reading one of his books or listening to him talk. This session was no different, although it was rather more technical than I had hoped for. He gave us several techniques for writing internal DSLs, but no pointers at all on when to use DSLs in the first place.

Session 5: Building DSLs with External Workbenches by Neal Ford
Neal Ford opened this session with one interesting observation: IDEs are slowly moving from working on text files to working directly on the abstract syntax trees instead. Thus, text becomes just one possible representation of the software, among other possibilities. But the rest of the talk concentrated on two different tools for creating DSLs: An Eclipse based tool called Xtext, and a tool created by JetBrains, the company behind the IntelliJ IDE, called MPS. Both tools enabled the user to create DSLs and the tools to work efficiently with the DSLs. Xtext, for example, will automatically generate a new Eclipse editor plug-in for the language, complete with syntax-aware colour coding and context-sensitive help.

Conclusion
Domain Specific Languages was hot topic this year. I think almost every speaker at JAOO mentioned them in some form or another. The most obvious use of DSLs I’ve seen is as a build language (Gant being an example of an internal DSL inside Groovy). But I would have liked to see some more (and more diverse) examples of using DSLs in real life projects.

Other hot topics included functional programming (emerging into the mainstream, both in the form of new languages such as F# and Scala, and as a heavy influence on the evolution of existing mainstream languages); dynamic languages (pretty well established in the mainstream by now, with representatives such as Ruby, Groovy and Python); parallel computing (mostly as a threat hanging over our heads, waiting to be overcome one way or another) and how best to utilize the internet in our applications (cloud-computing and rich internet applications).

In conclusion JAOO 2008 has been a wonderful conference. I’ve learned a lot, talked to a lot of very interesting persons and gotten a load of inspiration that will properly take me days, if not weeks or months, to process. I hope I’ll be able to attend next year too.

Today’s keynote was about Google Chrome and their V8 JavaScript engine. It’s as nifty piece of technology, but wasn’t a very interesting subject for me. I can’t help but to doubt that JavaScript will be any kind of long-term solution for developing web applications, no matter how much Google optimizes their engine. The browser is a perfect distributing platform, but a lousy execution platform. I believe more in RIA technologies such as Flex, Silverlight and JavaFx.

Session 1: Of Code and Change: Beautiful Software by Michele Lanza
One word: Amazing! The first thing Michele showed us was a first generation visualization tool running in an Eclipse plug-in. It visualized code as a 2D graph where classes where represented by simple squares. Different metrics was used to control the width, height and colours of the squares. It was impressive what could be seen at a glance from such a relative simple figure. But the second thing Michele demonstrated was really fantastic. It’s a tool developed by one of his PhD student and it’s called CodeCity. It draws an entire software system as a full colour-coded 3D model of a city. Packages appear as districts and classes as buildings in the districts. It gives a whole new way of visualizing the overall architecture of system, spot areas ripe for refactoring, identify areas of frequent change or stale code, and much more. Take a look at .

Conclusion
For me, this day was all about Rich Internet Applications. I think Chrome is a good looking browser (I like the slick interface) but, as I said, I’m doubtful if JavaScript will continue to be the preferred language for web application in the face of the competition. Media codex’es aren’t build into the browsers but played through dedicated media players and plug-ins. I think we will see a similar trend for web application: They will use the browser as a distribution platform, but will run in dedicated ‘application players’ and/or ‘application player’ plug-ins. Whether these players will be build by Microsoft (Silverlight/.NET), Adobe (Air/Flex) or Sun Microsystems (JavaFX) I don’t know. Time will tell, I guess.