Wilfred Thinking Aloud

Dialogs becoming First Class Citizens

One of the things that has been a real pain in my career is that -- while building Web UIs -- in many cases I had to carry conversational state across a number of HTML pages without having the proper tools to do so. In these cases, the conversational state is bound to the unit of work or activity, and not to a session. I can't tell you how many frameworks I've used that didn't consider dialogs to be a first class citizen. The talk on Shale really made my day: Shale already provides rudimentary support for it, and it will continue to evolve to support multiple concurrent dialog instances...

JavaOne Apres Keynote (Monday)

Here's a summary of the coolest things mentioned during the keynotes:

• The Application Server is going to be open sourced;
• Our JBI environment is going to be open sourced; (I *like* it)
• It will include a BPEL Servcie Engine;
• The JDO days are officially over; (.....)
• Hapner had a slide in his presentation showing a JBI environment with an XForms Binding Component;

JavaOne Plucker Database Update

The JavaOne schedule has been updated, so here's a new Plucker Database.

JavaOne Plucker Database

In exactly 24 hours, I will get on the plane leaving from Amsterdam to San Francisco. After that, I will have about 10 hours to prepare for JavaOne. Based on some work done together with Gero Vermaas, I hacked the conference schedule into a Plucker database. Now I can read the entire conference schedule from my Palm.

You can download the Plucker file from here. Here are some screenshots:

Vertical Integration vs. Horizontal Partnerships

The shift from vertical integration to horizontal partnerships is IMHO one of the important business drivers behind SOA.

In the past, organizations used to have a desire to control the entire supply chain. Large corporations would own both the local retailer and the mines providing the basic material for their products. Corporations like that resemble the red organizational structure in the figure below. Let's call them Red inc.

Over the years, business has been moving away from this old "vertical integration" school of thought into a new business model that prefers "horizontal partnerships". Divisions and business units became responsible for their own profit and loss, which eventually led them to search for other opportunities to grow and stabilize the incoming flow of revenue by searching for other clients of their services. It is only a natural consequence that the strong ties with old organization would get weaker and that ties with new organizations would grow stronger.

Eventually, this has led business units to become business partners. Because of the weaker ties with the old organizations, and because of their desire to offer services to other clients than the old organization, old ad-hoc integration processes would no longer work. Instead, the business unit would search for a coherent and well-defined market proposition, and seek for standards adoption to become more attractive for potential new customers.

The following figure illustrates it. In this case, a business unit of the Red inc., is starting to offer its services to the green organization. This way, it is drifting away from its original position in the old organization, and is starting to become a business partner for the old organization. It is responsible for its own profit and loss, so its basically crawling up on its own feet now: let's call them Yellow inc. The green organization (Green inc.) has come to the conclusion that it no longer wants to have the services of the business unit in house, and decided to outsource the entire set of services originally provided by the Green inc. business unit to the Yellow inc.

The mechanisms in a typical SOA architecture facilitate exactly these kinds of rearrangements in your organization:

• Having a clearly defined market proposition and a related clearly defined coherent set of services allows Yellow inc. to offer its services to other organizations than Red inc.
• Adoption of vertical standards in the definition of the services of Yellow inc. allows Green inc. to pick another business partner in a relatively painless way.
• The loosely coupled nature of the open Web Services standards attribute to this freedom of choice and flexibility even more.
• At the same time, being alligned with the direction in which the industry is heading (embracing the Web Services standards), works as an excellent sales argument for Yellow inc.
• Both Red inc. and Green inc. are able to focus on their core business.
• ...

Expect to read more about this in my blogs in the near future.

P.S. Make sure to check out John Crupi's blog about the role of the business unit too.

RAID for Dummies

A colleague passed this to me this afternoon. I couldn't stop laughing.

JavaOne Pitcher

<nl_NL>

Vanavond heb ik me ingeschreven als T-shirt tosser. In eerste instantie leek het mij wel aardig om deze entry als titel "I'm a Tosser" mee te geven, maar dat is waarschijnlijk nogal verwarrend voor onze vrienden in de UK.

Hoe dan ook, betekent dat dat ik tijdens JavaOne op dag 2 (zet het in je agenda) in staat ben om een door James Gosling zelf geproduceerd Duke T-shirt in je maag te splitsen. Maar alleen als je zelf goed kunt vangen. En als ik je ken. (Ik ken mensen pas echt goed als ze een biertje voor me hebben gekocht...)

</nl_NL>

SOA Smells

Ever heard of "Code Smells"? Let me give you an introduction if you haven't. "Bad Smells in Code" was an essay by Kent Beck and Martin Fowler, published as Chapter 3 of "Refactoring: Improving the Design of Existing Code". This is what Wikipedia says about it:

"In the community of computer programming, code smell is a jargon term used among hackers to refer to a symptom that indicates something may be wrong: a suggestion at the possible presence of an anti-pattern."

The thing with "Code Smells" is that they can indicate that there might be a problem in your code, but they can not guarantee that a specific piece of code is wrong. You still need to make a decision based on the trade-offs involved.

More than half a year ago, we were trying to figure out if we could identify a deterministic approach for defining the appropriate service layer definitions. (Like the granularity of a service, and some proper guidelines for dividing the entire problem space up in several domains.)

After a while, we decided that it might be a little to ambitious to come up with a deterministic approach. We did however agree upon a couple of key indicators that would at least give you a hunch on where to put your service boundaries. The indicators were based on analysis based UML deliverables, and included rules like this:

• Search for tightly coupled clusters of types in your Domain Object Model and defines service boundaries at the edges of these clusters;
• Search for commonalities in Use Case steps; (Those commonalities might justify another service layer.)
• Search for commonalities in how typical scenarios affect snapshots of the Domain Object Model; (Commonalities in affected types might also call for another service layer.)
• Make a distinction between your "Business Process" types and "Business Concept" types in your Domain Object Model. "Business Process"-related types do only exist for the lifetime of a certain business activity; "Business Concept"-related types survive a certain business activity.

We labeled it "SOA Smells", since it reminded us of "Code Smells". A bad smell in refactoring does not necessarily mean that you must refactor something. It just means that you need to consider a piece of code for refactoring. Similarly, a "SOA Smell" does not give you the ultimate and ideal service boundary, just like that. Instead but it simply highlights a few potential candidates, before you consider all of the different trade-offs.

DocBook saves the day

During the last 2.5 years, I have been writing all of my documents in DocBook. And boy, do I love it. I don't think many people with a software background really enjoy writing technical documentation; the good news is that with DocBook.... you are programming again. Yep, you heard that right: programming. Consider it to be the rescue plan for techies that need to write documents. (In fact, that's probably also the main reason why it is so succesful in the Linux/Gnome community.)

Don't get me wrong: you don't need to be a developer to use DocBook. Basically, the only thing that you really need is a text editor and a tool to convert you XML document into whatever format you like. If you feel like giving it a try, then you might find these pointers interesting:

• DocBook DTD and Documentation
• DocBook XSL: The Complete Guide
• http://sourceforge.net/projects/docbook/

If you're planning to use a tool like XMLmind's FO Converter, then you don't even need to care about the stylesheets. This tool has it all. In that case, you might also like XMLmind's XML Editor. Both tools have a free edition. In that case, you get a tool that looks like this:

But the really cool thing of DocBook is of course, that it is so incredibly easy to generate documentation. That means that you can limit yourself to the barely sufficient, and have anything else generated for you. Whow. It's basically just hacking an XSLT stylesheet together and you're done. The only penalty is that you need to learn XSLT, but then again, who doesn't need to know at least something of XSLT in these days, so you might as well consider it a reward instead of a penalty.

Kill Bill

Last year, just before JavaOne, I all of a sudden felt inspired by the annual artwork of James and some other pieces produced by a couple of brazilians, so I decided to give it a go and produce my own Duke t-shirt. Basically, I reasoned like this: favorite actress + Duke = instant art. So I took Gimp and a flyer of a recent movie, and after an hour I had this:

I don't know, but the net result somehow seems to be a little over the top. Don't know what it is...

AnnoJXTA

I just finished reading Dan Malk's blog on Delicious. Nice, and it brings back all sorts of memories.

-Like, when we within Sun were also looking for other ways to keep in touch, exchange ideas, reflect upon products and technology. The problem that we were facing is that - apart from our shared interest - we didn't really share a lot in common: everybody was working in other timezones and locations, and were only meeting each other twice a year. (And we do of course try to solve anything using technology....)

One of the things that we considered is Annotea. Never heard of it? Make sure to check it out:

"Annotea enhances collaboration via shared metadata based Web annotations, bookmarks, and their combinations. By annotations we mean comments, notes, explanations, or other types of external remarks that can be attached to any Web document or a selected part of the document without actually needing to touch the document. When the user gets the document he or she can also load the annotations attached to it from a selected annotation server or several servers and see what his peer group thinks. Similarly shared bookmarks can be attached to Web documents to help organize them under different topics, to easily find them later, to help find related material and to collaboratively filter bookmarked material."

[This dates back to 2001! So, this stuff already existed way before del.icio.us.]

The first time I used Annotea, it felt like a revelation. Using a premature Mozilla plug-in, I navigated to "a competitor's" site, and added a note to the homepage stating that they were nothing but a bunch of loosers. Harharhar. That felt great! Anybody now visiting the homepage of this company would now immediately notice my carefully formulated evaluation of this company. Yup!

Not much time after I saw the value of a tool like this, I also ran into some of the disadvantages of it. This is the cool thing: everybody can read it. Yippee! But wait: everybody can read this. Uh-oh.

Another problem was the fact that it was pretty centralistic in nature. Within a company that feels that everything of value should be connected to the network, it was a hard sell to move everything of value to a single host. So we needed to get rid of that too.

After a while, we started to think about about a solution based on combining Annotea with another complementary piece of technology: JXTA. This is the thing that we had in mind:

In the above, any HTTP request by our browser would result in another Annotea HTTP request being sent to the Annotea Servlet. The Annotea Servlet would run locally as a service on every host participating in the JXTA network, and would delegate the request for annotations to both the local AnnotationSource as well as the JXTA based AnnotationSource. Requests to add or update annotations by the browser plug-in would eventually only be handled by the AnnotationTarget, who would simply store it in a small local database. (Think Hsqldb.) The JXTA Annotations Service would use the same source for incoming annotation requests.

So this is what we got, simply by combining Annotea and JXTA:

1. An Annotea-alike solution, allowing us to exchanges ideas, opinions and observations;

2. Leverage existing browser plug-ins;

3. Store our own comments locally, so we could even do that off-line for all we cared;

4. These ideas would be made available to our peer group, as soon as we would go online;

5. Leverage the JXTA security mechanisms to share our ideas only with our Java Center peer group;

6. But at the same time use the Internet for distribution of our ideas. (Talk about hiding in plain sight.)

On top of that, JXTA appeared to be a natural fit to the problem: in any case, it would always first serve you the annotations of your buddy sitting right next to you, and then fan out through the Internet.

Written in the palm of my hand

A quick entry, to proove myself that it is possible to edit blogs from your palm. If you care to know, it isn't really convenient. Going crazy over all the times i've misspelled thimgsr htegjk, aaaaaargh

Done on a Sony Clie TH55 with wireless support.

SOA vs. soa

The ongoing discussion on the meaning of the word SOA is reminding me of the of the discussion on the meaning of Component Based Development in the past. It could probably also have reminded me of the discussion on the word Internet in the past - if I wouldn't have been too busy riding my skateboard and reading comics at that time.

If you do see the resemblance between what we are going through today, and the rise of the Internet - well, then you are in good company: Doug Kaye is covering some of that in his excellent book "Loosely Coupled: The Missing Pieces of Web Services". If you don't know this book, then make sure to get it now. It's an excellent guide for knowing how to ride this new wave in the industry, without being required to know all about the WS-* standards.

The reason why I bring all of this up is this: the introduction of Richard Stevens' monumental work on TCP/IP contains this little line:

"...The word internet means different things depending on whether it's capitalized or not.

The lowercase internet means multiple networks connected together, using a common protocol suite. The uppercase Internet refers to the collection of hosts (over one million) around the world that can communicate with each other using TCP/IP. While the Internet is an internet, the reverse is not true."

I say, let's introduce a similar distinction between SOA and soa: in this case the "common protocol suite" based on widely embraced standards including orchestration and identity standards would be the upper case version: 'SOA'. In that case the term 'soa' would be reserved for other flavours of service oriented architectures, like Jini, JXTA and what else is out there. As a consequence, the following would apply: "While SOA is an soa, the reverse is not true."

Cube-omatic

Anybody who has ever been working with Sun has probably at some point in time been confronted with the ubiquitous Cube, the simplified architectural reference model that came out of the Java Center practice. (If you never ran into the Cube, well, then you have been talking to the wrong people.)

The good thing about the Cube is that it is simple. Simple = good. To quote Calvin: "if you can't say it in just a few words, then it's probably not worth talking about it at all". That's what the cube was all about: idenfitying the different concerns in your architecture, and mapping those concerns to different dimensions on a 3D model.

The bad thing about the Cube is that it didn't always feel very comfortable where your components would fit in. As Clemens Szyperski ("Component Software") already pointed out: a strictly layered architecture is seldomly found. But that's not all: our ideas on "different concerns" have also been shifting during the last few years.

Because of this, a couple of people within Sun have been discussing some alternative reference models. Most of those options still remind us of the old Cube. Problem is, we didn't have anything to play around with these different views. I don't have a 3D cube model tool that we could use for that purpose.

Since most of the architectural documentation that we create today is linked to the different concerns mentioned in the cube, and since we have been building a lot of documentation from DocBook lately, I figured that having an XML grammar for 3D architectural models and a mechanism to build the PNG images from XML documents would be quite handy. So I created a Maven plug-in to do exactly that.

The Maven plug-in will look into a certain directory, and covert all files it finds into SVG, using a simple (!) XSLT stylesheet. After that, the plug-in will kick off Batik, and Batik will perform the conversion of SVG to PNG. That's all. The result looks like this:

And this is the kind of files that you feed into it. I must admit, the DTD is crummy, but hey - what you can expect from a hour of work.

<?xml version="1.0"?>
<!DOCTYPE cube SYSTEM "../dtd/cube.dtd">
<cube zaxis="dimension-qualities" 
      xaxis="dimension-tiers" 
      yaxis="dimension-layers">
  <space>
    <dimension id="dimension-tiers">
      <name>Tiers</name>
      <value>Client</value>
      <value>Presentation</value>
      <value>Business</value>
      <value>Integration</value>
      <value>Resources</value>
    </dimension>
    <dimension id="dimension-layers">
      <name>Layers</name>
      <value>Application Layer</value>
      <value>Virtual Platform Layer</value>
      <value>Upper Platform Layer</value>
      <value>Lower Platform Layer</value>
    </dimension>
    <dimension id="dimension-qualities">
      <name>Qualities</name>
      <value>Security</value>
      <value>Performance</value>
      <value>Scalability</value>
    </dimension>
  </space>
</cube>