Its about 6.30PM here in Prague and the day 1 of The Server Side Java Symposium (TSSJS) is wrapping up for the day with an award ceremony (sponsored by GigaSpaces). I am too tired and sleepy to carry on after yesterday’s long flight and lack of sleep but thought of posting a few interesting things that I noticed here at the symposium today.
Firstly the venue and the setup is pretty cool and there are over 300 people from many parts of Europe. The day started with a brilliant keynote by Stephan Janssen. His topic being: Supporting the RIA Space. (A Java conference kickstarts with a talk on RIA — interesting! isn’t it?). If you were at JavaOne this year and attended Stephan’s talk then you probably heard a lot of this. I had to step out of his talk a little early to get setup for my own talk, which followed Stephan’s. I spoke about JPA/Hibernate and RIA integration. Was happy to have a house full of attendees at my talk but was surprised when I saw only a few hands go up on my question: “How many of you are familiar with RIA?”. In fact a few were getting familiar with the subject only from the keynote that had preceeded my talk. Very interesting, again!
TSSJS speaker lineup is quite impressive. There were talks by many well known people, including Nati Shalom (GigaSpaces), Alexandru Popescu (InfoQ), Michael Keith (EJB 3.0), Guillaume LaForge (Groovy/Grails), Holly Cummins (IBM) and Geert Bevin (Terracotta, UMYN & RIFE) on day 1 itself. There were many other good speakers today: its just that I presume the ones I listed are better known than others. There are many more good speakers in the next couple of days to come. Obviously I could not attend all the sessions today so it would be unfair for me to comment much about the ones I never even peeked into.
Both the Groovy talks (Alexdru’s and Guillaume’s) were cool and well attended. Java Performance (Holly’s) and JVM Clustering (Geert’s) were very popular as expected.
These days when you go to a Java conference its a lot about dynamic languages (and their existence on the JVM) and the first day here reinforced the same feeling. However, one interesting change was a company called ZeroTurnAround , which promised dynamic redeployment of Java applications (far better than the JVM HotSwap). Their tool is called JavaRebel (I spoke with Jevgeni — who carries a fascinating title of Lead Rebel in the company) and he was kind enough to walk me through a lot of examples where Java code could be redployed effortlessly. There message could be interpreted as: “Java can be dynamic in some ways too, without being dynamically typed or interpreted!” If you are a Scala fan, you will be happy to know that JavaRebel comes built-in with Lift, the emerging Sacla framework. Talking about frameworks, there are too many in the world of Java to catch up these days and that is the topic of my next presentation at TSSJS this Friday. I am not going to miss the opportunity to express my frustration dealing with over supply then! Wish these framework makers found a way to create alternative energy sources; with their commitment there with be no oil crises today :)
More tomorrow!
Tom Baeyens (jBPM / JBoss workflow project lead) has a good post on the jBPM (JBoss workflow) community day held at the Guinness brewery in Dublin. Warning - slides may contain pictures of people drinking beer.
In case you missed How to combine (jBPM) Workflow and (Drools) Business Rules (what do you mean that you were at Java One instead?) - here’s the summary. Slideset is available on this blogpost.
- Workflow (e.g. JBoss jBPM) is great - it allows you to take spaghetti code and draw it as a workflow diagram (flowchart) so that it can be reviewed by the business (the nice people who pay our wages). You then attach standard (Java) actions to these steps.
- Only problem is when you come to a decision node (the one circled in red below): How do you decide to go left or right (in the workflow)? Normally this is coded in Java - good for us, but hidden from those nice business people (which means that this is more room for errors-in-translation).
- Business Rules allow you to keep those decision making rules in Plain English: When something is true , then do this. That’s it. The rule engine does most of the hard work.
- Integrating Workflow and Rules is easy. Use JBoss Seam (link) or do it by hand (link). And it works on non-JBoss web / app servers such as Websphere, Oracle Application Server, Tomcat and Weblogic.
- Repeat x6 : Use workflow and rules. Use workflow and rules …
More information on:
In a maybe related development, Tom Baeyens is now using strangely Rules-y like examples over on his workflow blog ….
Vincent Pardington has a good post up on DZone beginning an SOA pitfalls series. His first post, on NIH in the SOA world is a good one, but I think misses one important point:
First of all, the idea of a SOA is to reuse existing services. If department A builds a get_personal_details service, there’s not much point in department B building a get_address service. Assuming the get_personal_details service returns the full address.
Of course, there may be multiple reasons why department B would do this:
- They don’t know about the get_personal_details service. In this case there is no proper service registry, a point we will discuss later.
- The way they design their application does not cause them to think about reuse. This is one of the things that can happen when applying Big Design Up Front. Something we will also discuss in a future blog (way to build up the suspense, not? ).
- They’ve known about the get_personal_details service but they decide not to use it. Maybe they don’t know what it does exactly, maybe they don’t trust department A to get it right or keep it right, or maybe they’d rather have full control over the implementation. In this case, you have some classical NIH hitting you. This is the time to discuss the ownership of the services and allow both department A and department B to feel in control.
I think there is one more here that is organizational. In my experience, services in the enterprise tend to be developed as part of an application. The problem is, they aren’t staffed as standalone products after the application for which they were originally designed goes into maintenance mode. Let me set up a #3 to Vincent’s storyboard:
Team B knows about the get_personal_details service, but the address returned doesn’t include the shipping code for the address. They would love to use it, but Team A is now working on the next project. Team A’s boss doesn’t want to spare resources to amend expand the service, and Team B’s boss doesn’t want to take ownership of the service.
The problem is one of perspective. In reality, Team A built TWO applications: One for the end user and one for developers and they should be slotted to do ongoing enhancements to either one of those. I know at Manheim there was an earnest effort to establish a product ownership system fro the “Services” products. The problem there was, nobody in management wants to own them.
I know there was a great article in ACM Queue a little over a year ago about the services infrastructure at Amazon. Their solution was to treat the services products as a profit center: every call back to underlying services was “billed” to the application group making the call. This has the effect of encouraging the service owners to add value to the services infrastructure, as well as encourage upstream applications to be frugal in their stress to the back end. I found this to be a really compelling structure, but I can also see how it might lead to some… poor… software decisions in a less disciplined organization.
