For registration and more information check logica.dk/apex

Finally on Wednesday 1st of July Oracle released their highly promoted new version of Oracle Fusion Middleware.

A lot of new stuff and concepts to play with like Composites, Event Driven Architectur (EDA), Complex Event Processing (CEP)…
AND now based on the Oracle Weblogic Server (from the BEA acquisition) which will for sure make all better performing and stable.

Based on my Beta findings it will be a great step forward for Service Oriented Architecture.
It is now all highly integrated and all Java based (also Business Activity Monitoring - BAM).

Hopefully upcoming time I will have more possibility to try things out and share the findings.

For now try it out yourself and tell me your findings
All stuff as well as the webcast on the release can be found via:
Introduction to Oracle Fusion Middleware 11g

Greetz,
Jørn

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.