Wednesday, May 30, 2007

The other shoe drops - And then there was light.

Well, Burton Group delivers the knockout punch IMHO.

What a difference a year makes.

Welcome Anne Thomas Manes. Anne is wicked smart - that is a fact.

May 09, 2006: I'm one of the folks responsible for mixing the Kool-Aid. I presented at the W3C Workshop on Web Services (representing Sun). I participated in numerous standardization efforts at W3C, OASIS, WS-I,, and JCP. I have a vested interest in making sure that WS-* succeeds.

May 30, 2007: If you're ready for REST I suggest you jump on board right away and get ahead of the curve," she said. "You'll have to train your developers in REST principles. You'll probably want to adopt one of the new frameworks or help build one yourself to help your developers implement RESTful applications. You definitely need to provide guidance to your people. What you want to do is work to the point where REST becomes the default for all your distributed applications."

I certainly disagree with her time lines, but am glad she has seen the light on REST.

I'm very excited about the post WS-* world. It is settled - to my delight, much sooner than I predicted. This only reinforces my feeling that we are at a major strategic inflection point.


What's next?

Via Mark Baker who really does deserve a trophy or some such.

Update Fixed date.

XML Code Gen & Service Description Langauge

Stefan Tilkov talks about Runtime Interface Dependency.

. . . while my application code may be tolerant to at least some changes, the generated infrastructure code isn’t

+1 for WS-DuckTyping.

I realize that my WADL Gateway Drug logic is therefore fairly twisted given my own experience with the over dependence/brittleness that results from code gen. My idealist side agrees that it isn't necessary. My "I wanna see this happen" side appeals to it because the current state of the WS-EnterpriseProgrammer thinks in a service description language way. I just want to throw them a bone. I'm not sure this is wise or what.

There are some good comments in Stefan's Does REST Need a Service Description Language? post.

My favorite:

peter: I’m very interested in how a “typical” REST development process looks like (if such a thing exists). Up till now I have to stick to WS-* at work. How would a cross project interaction work in the REST world? What does the service provider project team give to the service consumer project team? Just a set of URIs? How do they implement the REST service clients? Manually, using CommonsHTTPClient with an XML Mapping framework of choice? Do I stress the toolsupport too much?

stefan: "Do I stress the toolsupport too much?"

Yes, I think you do — after all, do you hand over a WSDL without any accompanying documentation when you use WS-*? Chances are you provide the other team with some documentation, either inline or separate, that they have to read before using your service. A great way to document your resources is to return HTML when someone does a GET …

CommonsHttpClient is a good choice. Whether or not you need an XML binding framework is orthogonal.

peter: Yes, you’re right. WSDL is not enough as documentation for the service consumers. Usually we provide the complete client api :) Which was not the intention from the beginning. But most colleagues ask for example code in their preferred language and not an interface description. Then we come to the question why we used WSDL in the first place? There is one thing were it really works. I use soapUI a lot for testing. Point it to your SOAP Service, append “?wsdl” and let it generate a sample request.

I think that Mark Baker sums it up concisely:

Cut the cord already! RPC is dead. You’re not in Kansas anymore.

Monday, May 28, 2007

Google GData

If widespread use of REST & Atom at Google don't convince you that perhaps that WS-* stuff doesn't have such a bright future, then perhaps enthusiastic nodding from a prominent MSFT blogger will.

Take a good hard look at GData. It is well documented and comes with clients for everything besides Erlang.

Via Tim Bray

LINA - now that is what I'm talkn' about!

With LINA, a single executable written and compiled for Linux can be run with native look and feel on Windows, Mac OS X, and UNIX operating systems.

I am encouraged by Adobe Apollo for the same reason that LINA looks promising:

Tools like this could give us cross platform desktop applications and bring Linux to the masses.

LINA of course is FOSS - yay on that.

If LINA goes anywhere, Adobe will open Apollo. For all I know, this is already the plan.

More please.

Via Planet Intertwingly, via Allison Randal (O'Reilly)

WADL Gateway Drug

Stefan Tilkov responds to Aristotle Pagaltzis who thinks REST doesn't need a service description language:

In principle, I agree; for pragmatic reasons, I believe efforts like WADL make sense, if only to have an answer to one of the most obvious questions for new REST converts :-)

+1 to that.

Take a gander at the spec. I tear up just looking at it. It is beautiful compared to WSDL - just beautiful.

I think that the risk with any service description language is that people take it too far and become overly dependent on it. Generating code from them tends to do this. But then again, code gen can be helpful. You just have to know when you have taken something too far and not be afraid to press the eject button to dumb it back down.

I think that REST client developers at the very least will want schema definitions of what to expect in request/response payloads. IMHO WADL does a good job of not taking things too far. As I said, compared to WSDL it is a thing of beauty. It is so simple when the only option is HTTP (i.e., compared to the absolute insanity of protocol agnosticism).

If you aren't going to use WADL, you are going to have to document the service in prose or some such. WADL at the very least seems to be a really concise way to document things.

Update Somebody should give Mark Baker a trophy or something. I still will take WADL any day over WSDL, but Mark is probably right. Still, I'll take baby steps if that is what it takes.

Update 07-JUN-2007 I have been convinced that a service definition language is not good idea right now.

Lift on Scala & the Functional JVM

Tim O'Reilly mentions Lift on Scala.

Pretty wild.

There really are a crap load of Java APIs out there. Like it or not, Java owns the enterprise today. Maybe adding functional foo on top of Java is a good compromise. One could then have the joy of functional programming and use said crap load of Java APIs.

Is the JVM the way forward? Or will something deep in its belly only allow this approach to go so far?

What kind of mind bending errors do you have to acclimate too etc.?

Via Zack Urlocker

Update: Good Article: First Steps to Scala One reason you might want to use Scala is that it allows you to increase your productivity compared to Java while leveraging JVM execution speed, your existing investments in Java code, knowledge, and the vast array of APIs available for the JVM. It has the conciseness of a dynamic language like Ruby or Python, but it is statically typed, like Java. Another reason is that Scala comes with an Erlang-like Actors library that greatly simplifies concurrent programming, but runs on the JVM.

Sunday, May 27, 2007

Cyclocross Forest Park

I spent a couple hours today on my bike in Forest Park.

Pretty brutal climb for a cyclocross poser like me.

It was a great ride.

I love the sound of your tires on a dirt road digging in yet slidding a wee bit as you climb and turn. Wicked cool.

Saturday, May 26, 2007

Large Application Architecture vs. Integration Architecture

One topic that I see a lot of people struggling with is the difference between large application architecture and integration architecture. I struggle with this too.

Much of the commentary out there is regarding what I consider integration architecture. Topics like REST, Atom, XMPP, the dreaded WS-*, MQ Series, ESBs, application grids, etc.

You don't read as much about large application architecture. I think this is true because so much of the world today is dominated by integration. Most often teams don't have the opportunity to build something from scratch. Instead they are building things like web front ends to 30 year old mainframes. Things tend to get very fuzzy. You typically end up with a big ball of mud architecture.

I think the risk here is that there is indeed a difference.

Much of my time the last few months has been spent looking at building a new very large application. A large application has many different moving parts. This is similar to integration, but subtly different.

A key concept for me has been defending the core of the large application. XML everywhere makes zero sense in the core of a large application. Yet we see this in evolution strategies because different platforms are coming together (e.g., web and mainframe). Hammering a database on every page turn is bad - you have to be careful to seperate transient/active state from steady state/long lived storage. Also a large application needs to scale and is by definition then distributed. It can be very confusing.

For me, things like JavaSpaces and application grids make a lot of sense for large application architecture because they don't bork a large application into an integration effort.

But at least some of these technologies are also useful in an integration effort.

I realize that I am just blathering here. I think the only way to make sense of this is to separate the two concepts as best you can. The integration architecture should be the interfaces you expose and events you generate from various large applications or sub-systems. The application architecture should be dedicated to defending the conceptual integrity of that application / sub-system & pushing the integration to the edges.

Friday, May 25, 2007

Fried Cheese Curds


I spent the week in Wausau, WI for work.

We had fried cheese curds as an appetizer every night.

These must be awful for you.

But they are incredible.

Sconi is pretty great all around.

Thursday, May 24, 2007

OR - Not

Data management professionals need to start treating their data models and database schemas as ongoing projects of real value to the organization, which need constant ongoing maintainence and evolution. They need to stop treating a legacy schema as some immutable holy text handed down by God. Database refactoring is possible and practical (hat tip to Scott Ambler).

Gavin King of Hibernate / JBoss Fame sums up why I avoid all OR tools including Hibernate. What if I want to use the full features of my database and write some real queries and not get "certified" in your OR tool? Sure databases should be refactored, but it sounds like he is nicely describing the trap of OR tools: bow to the OR tool - just make it easy, don't resist! And watch the insanity slowly begin . . .

Hibernate and their ilk impose all sorts of crap on you, get their hooks in you, and slow bleed you to death.

In experience hands, they are fine - great, got, been there, done that.

I just don't see what is so wrong with JDBC (Spring JdbcTemplate if you are feeling frisky).

He goes on:

Relational databases are an integration technology, not just a persistence technology. And integration is important. That's why we are stuck with them.

Sad, true in some places, but we certainly don't want this to be the case right?

People are spazing out the most the last year or two about iBatis - apparently less invasive. I'm sure it is. I looked at it a year ago and indeed it looked less evil. I'm just too jaded I guess ... and I just don't get what is so wrong with writing JDBC.

Via Buko Obele

Tuesday, May 22, 2007

Signs of Life @ Apache River

It is encouraging to see a spark on Apache River list.

I'd love to see a come back.

Tuple Spaces are addictive.

Sunday, May 20, 2007

Strategic Inflection Point

More and more it feels like we are at a fairly sizable inflection point when it comes to application development and integration.

I remember reading Only the Paranoid Survive by Andy Grove when it came out in 1996.

Intel has the preface on their website. Here is a quote on what he calls "strategic inflection points":

Strategic inflection points can be caused by technological change but they are more than technological change. They can be caused by competitors but they are more than just competition. They are full-scale changes in the way business is conducted, so that simply adopting new technology or fighting the competition as you used to may be insufficient. They build up force so insidiously that you may have a hard time even putting a finger on what has changed, yet you know that something has. Let's not mince words: A strategic inflection point can be deadly when unattended to. Companies that begin a decline as a result of its changes rarely recover their previous greatness.

As someone who reads blogs and maintains this blog, I feel these more than I used to. These points come and go. There are small ones and big ones. I feel like we are at a major one right now. The biggest I have ever felt. Maybe it is just because I am passionate about some of the issues that are at a cross-roads right now - maybe it is just me. But I can't help but feel like it is more than that. Patrick Logan and I discussed it momentarily at work a few days ago. We didn't get into details, but he feels it too.

A couple topics that I am interested in that tell me things are changing. There will be many winners and many losers. If you are affected by these topics, I suggest you start paying attention, because your world is changing:

  1. Open Source Software is a major threat to commercial proprietary vendors. These vendors are starting to lash out in strange ways. Will it only be MSFT that lashes out? Where will this go? Why now - what was the tipping point? This? The fact that OSS has come this far - that executives get it? That the partner pull-through proprietary platform is threatened (i.e., no apps no platform)?
  2. WS-*, an enormous industry initiative is an utter failure. REST wins, wow.
  3. People are drifting from MSFT Office in favor of the web and experiencing a whole new level of collaboration and knowledge management.
  4. J2EE is spent - Spring has $10MM to spend.
  5. Cambrian Explosion of Web UI Change (Flex, Silverlight, JavaFX) - where will it lead?
  6. The google-ization of the data center.

I could go on, but don't want to lose you. These are the ones I personally feel the strongest

Saturday, May 19, 2007

OSS Middleware License Sort

I spend a lot of time on next generation architecture. This includes technical analysis, POC work, pilot projects, and then taking the tech mainstream. I am most interested in architectures that are simple that will result in far fewer defects than what we have today (e.g., excessive mapping, translation, co-mingling various state etc.).

I have stated my license preferences before.

They remain the same. I am not opposed to commercial proprietary software if it brings tremendous value to the table and simply can't be done without a more flexible & innovation friendly licensing alternative.

But in terms of middleware, I have come to a recent conclusion. I sort based on license type. I no longer look at commercial proprietary middleware. I have had too much angst in the past due to it and the commercial oss middleware today is fantastic.

For next generation middleware, I see no reason to perpetuate the inferior commercial proprietary model.

All FOSS projects are not alike of course. You have to be very diligent in accessing the accessing the health of the community etc.

Wednesday, May 16, 2007



I can't decide if this thread feels like yesterday or 10 years ago.

We'll have to see what the outcome is of the TeleBriefing, but wouldn't it be nice if the other shoe fell and we could just move on?

The shoes of course have been dropping left and right, but far too many people still haven't noticed and are uneducated with regards to the misery that awaits them.

It is going to take long enough for all the ancillary - it provides enough business value so suck it up and integrate with it WS-* COTS products to wash through the IT ecosystem once we all agree that it is WS-Over.

So can we WS-WrapItUp already?

Overheard in Portland

Extremely funny - even if you don't live here..

Tuesday, May 15, 2007

Many Flavors of Grid Computing

Good post: Nikita Ivanov: What is Grid Computing.

Mobile Code

It bends your brain a bit at first. And J2EE ClassLoader hell didn't help on the FUD front, but the future is not only about mobile data (ala SOA), but also mobile code.

GridGain does mobile code.

And it looks a wee bit more approachable than PreferredClassLoader.

MSFT Patent Links

Matt Asay: Some of the best thoughts on Microsoft's patent poll tax

Eben Moglen Video Goodness I love listening to him speak.

Jonathan Schwartz: That's not a genie any litigator I know can put back in a bottle.

I have to say, that Fortune magazine article was some pretty bad PR.

Viva FOSS! Viva Freedom! Viva Transparency! Viva free thinking clever people that do stuff!

$10MM for Spring


Emerging from the Google OSS Grid Haze

Looks like GridGain is emerging from their semi-silence:

GridGain Systems announced today availability of the first public release of GridGain project, an enterprise open source grid computing platform for Java. This release culminates 18 months of development and presents a software product with unique set of grid computing features, open source LGPL licensing and clear focus on high-performance Java-based development.

"Almost two years ago we set out to develop a technology that would change the enterprise Java grid computing landscape in much the same way Spring and JBoss have changed the J2EE market through simplification and focusing on a developer. Today we are releasing our project that is based on proven professional open source model, business and community friendly LGPL licensing, and the host of unique grid computing features", said Nikita Ivanov, founder of GridGain project.

Tangosol (now owned by Oracle) and others gave us the Java "Data Grid". Perhaps GridGain can give us the "Compute Grid" part. This is what we struggled with in looking at data grid/caching technologies - you still needed the compute part somewhere. Tools like Tangosol excelled in bridging the gap between J2EE performance problems due to data latency issues. But that is only 1/2 of the problem in terms of application grids. You still need to be able to easily add compute nodes to be able to scale.

Without a compute grid, you need to rely on things like JMS or other bits of J2EE. This is of course fine in an evolution approach - just doesn't seem to fit right in a new large system (at least for me).

Could this be an application grid without the Jini/JavaSpaces baggage? Don't know - certainly borrows some Jini features (code mobility). They know how to document things and have a roadmap and bits so that is a start ;) Message to Apache River: see I'm not kidding, the clock is going tick, tick, tick - the future is coming.

This should be interesting to watch.

Sunday, May 13, 2007


GridGain smartly pays Google so they show up when you google "oss grid". Otherwise, they only show up on the second page and I wouldn't have seen it today.

I read about it for 30 minutes and didn't run away screaming. Looks like a pretty young product. I'm also a bit afraid of AOP, but I'm a simpleton. They also use Spring - see it is everywhere. But they are FOSS and run on JBoss so hey - maybe it isn't bad.

Anyways, thoughtful people that seem to know some stuff and know how to try to start a community by documenting things fairly well. They also seem to be disatisfied with highfalutin grids that talk big, but don't deliver. We can all relate to that.

Anybody know anything about it?

Spring is everywhere

First GigaSpaces and now Appistry.

Spring is nice and everything, but I don't quite get how/why it fits here. It particularly doesn't make a ton of sense to me with massively dynamic & distributed technologies like Jini/JavaSpaces and Grid. Class loaders anyone?

Perhaps it makes things more approachable. It certainly doesn't make things more open. I choose open over approachable.

Grid & the Web vs. JavaSpaces

Some of the grid computing concepts look awful similar to JavaSpaces. And the community appears to be thriving (as opposed to Jini/JavaSpaces which is not).

There are some OSS projects and a number of commercial vendors. Done properly, you can use many different languages and platforms (as opposed to just Java with JavaSpaces).

Perhaps it is better? Simpler or more complicated? Not as good, but good enough? What about associative memory? Grid + REST + XMPP + Atom? Something else? More locked in or less?

I do love the promise of the tuple space. I hope some day it makes it into the mainstream. I no longer think it will any time soon, sadly. There are forces out there that I do not understand that will continue to relegate it to the niche category of "high performance computing". Until there is a thriving community around it, few will embrace it. I hope this changes. I certainly will be watching.

5/13/2007 9:45 PST Updated some links.

Portland, Oregon == Weird

Thank goodness it is weird here.

Every time I leave I want to come home.

I was even in San Francisco last week and felt the same way. Hopefully Portland stays this way.

Wednesday, May 09, 2007


This just in from the nicest person I know (my mother):

Part of a prayer I read this morning:

............"that I will be well in my own soul and part of the world's healing this day." Amen

Saturday, May 05, 2007

The Challenges of Latency

Nice article on latency by Dan Pritchett.

The web has created an interaction style that is very problematic for building asynchronous systems. The web has trained the world to expect request/response interactions, with very low latency between the request and response. These expectations have driven architectures that are request/response oriented that lead to synchronous interactions from the browser to the data. This pattern does not lend itself to high latency connections.

Exactly - I've lived with async systems for some time so my mind thinks this way naturally. I'm constantly amazed at how many programmers just don't get async. There has been progress in the last year or so, however. I'm a little shaken on this topic at the moment though. I am sick to tears of JMS and love the richer async patterns in JavaSpaces, but am faced with walking away from it as the lack of a thriving community has me rattled. What are other ways to accomplish JavaSpaces like styles without JavaSpaces? Hmmm?

I recently read an article where the recommendation was to delay horizontal data spreading until you reach vertical scaling limits. I can think of few pieces of worse advice for an architect. Splitting data is more complex than splitting applications.

This is where all the bodies are in busted distributed systems. It is so easy to make decisions for the short term that make your first (or next) release easier. The problem is these decisions are almost impossible to unwind.

I have much to learn in this area.

Determining whether the passive data center is truly ready to take traffic can only be done by sending traffic to it. This is difficult to do in an active/passive design without impacting customers. Active/active has an inherent self-proof of suitability for managing traffic.

Again, more effort in the short term because you have to actually make it work for real. I've seen many active/passive rigs where everyone knew that if there was a real DR incident that it wouldn't fail over properly. Active/Active really means that you can sleep at night ... it is the TDD equivalent for DR. Also everyone feels bad for the passive servers. I mean what did they do to deserve a life of just sitting there depreciating? I have also said that passive servers are either in purgatory or maybe that is what server heaven is - it is all pretty strange when you think about it.

Wednesday, May 02, 2007

Ahem Where are the Jini/JavaSpaces Bits?

Nice overview of JavaSpaces.

I likes it. I wants it. Really I do.

JavaSpaces is some of the best tech. I've had the opportunity to work with. Build a Generic Worker and tell me you disagree I dare you.

But, there is something wrong - I'm sure it is coming real soon now - that is what we keep hearing, but where are the bits? Where is the roadmap?

I said it a while ago. But the clock is going tick tick tick. It is May - it became a poddling in December/January. 5 months ... no bits, no roadmap?

One commercial proprietary vendor, a partially retired Pragmatic Dictator FOSS impl. and a very quiet maybe FOSS Apache project does not a thriving community make.

What gives? Does Sun want this to happen or do they want it to die? I just don't understand. I mean to offense - I'm new. But the current state of the community makes it very hard to want to invest in this technology - no matter how much potential it has.

I'm going to JavaOne a bit and am going to try to find out. I'll let you know how it goes.

Angry Pilgrim

Mark Pilgrim lit me and others up with some un-constructive criticism. I guess I do that occasionally so if I can dish it out I can surely take it :)

He raises some good points - concerns that I share.

We *reluctantly* looked into Flex a few months ago. We did this after trying numerous Ajax frameworks. We were not interested in a widget here or there that did some Ajax booya. We wanted to build a full blown RIA app for a very complicated system.

After suffering through severe pain in trying to get Ajax frameworks (choose any one you like) to work with Firefox, IE 5, 6, and 7 we threw our hands up.

We heard good things about Flex so we tried it.

We weighed the pros and cons of its openness (at the time it was just shared source equiv.) and decided to proceed further. Since then, they have opened up Flex - or stated the intent to under the MPL license. We were very happy to see this development.

Flash - is of course still proprietary. Mark is focused on this. He raises good points - concerns I share in a style try not to.

Adobe is showing a good direction towards opening things up further. I'm hopeful that some day Flash will be open.

In the meantime, our business has competition and we seek to beat it with the best systems we can build. We weigh the pros and cons, make our choices, and live with the consequences. Just like Google Finance and YouTube (properties owned by Mark's employer that both use Flash) do.

Tuesday, May 01, 2007