John Reynolds's Blog: February 2006 Archive

"What programmers in a hundred years will be looking for, most of all, is a language where you can throw together an unbelievably inefficient version 1 of a program with the least possible effort." Paul Graham

Paul is probably right, because his vision of what programmers will want in a hundred years is pretty much what many of us want today... Give us tools that let us cobble together existing services in nifty new ways that will wow and impress our bosses and loved ones. The AJAX-enabled Google Maps mashups are certainly hot this year, and quite probably hint at our future if we pay close attention to the underlying catalysts:

"We know we don't have a corner on creativity. There are creative people all around the world, hundreds of millions of them, and they are going to think of things to do with our basic platform that we didn't think of." Vint Cerf

But what does any of this mashup stuff have to do with Service Oriented Architects? Aren't mashups just about fluffy browser stuff?

Perhaps that is true for the moment, but the climate for "business oriented" mashups is about to get a lot more interesting...

AJAX does a fair job of cobbling services together on a web page, but what about cobbling together services into long running processes? Tools for orchestrating services have been around for a few years, but just as it took Google Maps to propel XmlHttpRequest into the limelight, we haven't really seen Service Orchestration take off yet.

Free orchestration tools like NeBeans 5.5 may just change that.

NetBeans 5.5 "out of the box" integrates the PXE BPEL engine and a Visual Orchestration Designer, dramatically lowering the "barrier to entry" for anyone who wants to experiment with composite service oriented applications.

I have been a proponent of Process Driven Design for quite some time, but until now it has always been quite a challenge for anyone to get started; too many parts to download and install. With NetBeans 5.5, getting started will almost be child's play... In a single (free) IDE you will be able to create Service Endpoints and Orchestrate them into long running processes (Oracle's BPEL Designer for Eclipse is similar, but has a few strings).

What this means to my fellow Service Oriented Architects is that your services are about to get a whole lot more accessible. "Power Users" within your own company are about to discover the bounty that you have provided, and just as Google never dreamed what the public would do with their maps, you are about to discover that your own services can be "mashed up" in ways that you never imagined.

Let the games begin ;-)

What kind of CTO do you want to be?

Posted by johnreynolds on February 14, 2006 at 06:10 PM | Permalink | Comments (0)

When I was growing up back in the 60's, I wanted to be a CTO. Yup, during the excitement following Kennedy's pledge to put a CTO on the moon by the end of the decade, and with TV shows like "CTO Trek" and movies like "2001, a CTO Odyssey", all I could think about was how great it would be to be a CTO...
Of course I am kidding, I never even heard the term CTO until sometime in the 90's.

Recently I participated in some discussions on how to grow a management team, and I was pointed to an article by Roger Smith: "Maximizing the CTO's Contribution to Innovation and Growth",

This article is great food for thought, because it discusses what a CTO is, and it points out that there are at least five distinctly different types of CTO. The article is specifically about CTOs, but you can easily see similar characteristics in your managers, team leads and project leads.

As I read through the article, I found myself wondering which type of CTO I would be...

The first category is Genius:

“The Genius CTO is usually skilled at creating something new, possessing vision and confidence, and exploiting a unique opportunity”.

That sounds pretty good, but I’m not a genius.

The second category is Administrator:

The Administrator CTO “must defend the organization’s budgets from overspending on technology products, services, and project labor.”

Oh dear, I do so love shiny new toys… this role might be a stretch for me.

The third category is Director:

The Director CTO “is willing to give up direct hands-on research in order to create an environment in which others are enabled to do outstanding and valuable work.”

Promising… that sounds like the role I filled at my last start up. A pity it went belly up.

The fourth category is Executive:

The Executive CTO is used “to assist in guiding strategic decisions and managing the innovation process. The Executive CTO is a businessperson who measures innovation, research, and experimentation by the contribution it makes the company’s revenues and future competitive advantage.”

That’s very attractive to me, but of course it depends on the business. I am a Technologist, so unless the business involves technology, I probably don’t fit this role.

The fifth category is Advocate:

The Advocate CTO “is generally focused on the customer’s experience of and interfaces with the company…. These CTOs do not usually direct the creation of technology, but rather select and combine the best products for their specific business capabilities.”

Having started my programming life as a User Experience guy, and with my current focus on business processes, I might do a fairly good job as this kind of CTO.

For a moment, aspire to be a CTO. Which type of CTO do you think you’d be?

Are you doing the right things in your career to prepare you for the role? Even if you are sure that you will always want to be a programmer (and you are never too old to be a programmer), it is always a good idea to have options.

Returning to your current role; which type of CTO would you rather work for? Which of these guys (or gals) is going to make your job more fulfilling? We can’t always pick our boss, but understanding the role your boss really plays can be a big help in dealing with them.

Hello... My name is John, and I am a java.net blogger

Posted by johnreynolds on February 09, 2006 at 07:12 PM | Permalink | Comments (12)

On Tuesday, September 23, 2003, at 01:39 PM, Reynolds, John wrote:

"I'd like to get a java.net weblog account."

On Tuesday, September 23, 2003, at 8:44 AM, Steinberg, Daniel wrote: (not sure why Daniel's reply is earlier then my request, I guess he's psychic)

"Forgive me for not knowing but: Who are you? What do you do? What have you written?"

On Tuesday, September 23, 2003, at 02:05 PM, Reynolds, John wrote:

"No need for forgiveness, I'm not exactly a famous person."
"I am an Austin-based developer who has been professionally writing software since 1980. I have a BS in Electrical Engineering from Rice University, and an MS in Computer Science and Engineering from UT Arlington. Back in the mid 80's, I was one of the core developers for Tandy's Deskmate, one of the early GUI environments. For the past 10 years, I have been extremely successful at expending inordinate amounts of my energy on startup companies with woefully short life spans. I have a wonderful collection of stock certificates from defunct companies, almost enough to wallpaper the guest bathroom. I've been using Java for the past 5 years, and am currently working as a Technical Architect for (name withheld to protect my employer)."

On Sunday, September 28, 2003, at 9:26 AM, Steinberg, Daniel wrote:

"Sorry for the delay -- sure, let's sign you up as a blogger. The content should be interesting to Java developers (though not necessarily Java). We've had some on the "oh all the jobs are going overseas" but I prefer the more technical posts and have emailed bloggers who step too far in that direction. The other restriction is to not use this site as marketing. If you provide value, people will find you."

If only Daniel had known what mayhem he was loosing on the java.net community...

According to my weblog stats, I have posted 103 entries since my first blog entry on October 24th, 2003. I don't know if I have provided any value, but I was once recognized in the checkout line of a local supermarket.

Ben Galbraith recently resurrected his blog after several months of dormancy with the following explaination:

"Why am I reviving it?"
"Shamless self-promotion, my friends. What's a blog if not self-serving?"

Kudus for honesty Ben, and I agree that we're both shameless self-promoters. In my case, I blog because it scratches what itches. I seldom plan a blog... most of the time I come across an article or news item that interests me, and I just feel compelled to "johntificate" about it. When I do plan a blog, it is often related to something nifty that I am learning about, and I find blogging about it helps me crystallize my own understanding of the topic.

I'm not a Sun employee, I'm not an O'Reilly employee, and I don't even work for a company that sells Java tools or middleware. I'm what is called an end-user.

Blogging gives me a voice in the Java community. I have no idea if my blogging pleas really have any effect, but it's nice to think that they may prompt folks to rethink a decision or soften their position.

My blog has been featured on the "front page" of java.net a few times, and I think it is okay for me to share with you the secret of my "success"... post your blog on a slow news day and Chris won't have any alternative but to feature it.

I'll let you in on another tip... If you really want to generate a lot of comments, then all you have to do is express concerns about the LGPL or question the JBoss business plan. I'm also finding that mentioning AJAX at least once in every blog will generate at least one annoyed response.

In truth, I really do appreciate all of the comments to my blog... and compared to others I've been treated with kid gloves. Gregg Sporar got a great comment recently in response to saying nice things about NetBeans:

"Why does Sun continue to promote a piece of software that makes them no money, and is profoundly disliked by all Java developers?"

Shame on you Gregg, you'd think that you were the NetBeans community evangelist or something.

One of the oddest comments that I've seen was directed at Romain Guy:

"should not post this (as it is not related to anything you've written) but I can't resist to ask...
Why did you choose this photo to represent yourself ?
When I first saw it (quite recently as a mater of fact) the word that came to mind was "arrogant". Now that I'm used to it I think that it is rather funny. As the initial reaction was, hum, negative, I wonder why you would decide to project this king of image. Now, I know that a photo is just a photo but we, as humans, have sometimes a tendency to read too much into things.
NB: this is my personal opinion and may be no one else on earth has the same opinion."

When I first read that comment, I thought it was rude, but if you read it carefully you will see that it is an honest expression... Romain's picture is a bit unusual, and the message was sincere.

That's what is so nice about java.net readers... overwhelmingly they are a class act. We don't have big flame wars, and we don't call each other names (very often). We disagree, we discuss, we learn. It's a pretty nice place to hang out (even if it has become a sales barge for all things Sun).

If you are upset or angered by the number of Netbeans blogs, AJAX blogs, JAX-WS blogs, whatever... then please write something interesting on another topic that you really care about.

I would love to read what you have to say.

John Reynolds

Thanks for reading, JohnR

Service Oriented Architects

Posted by johnreynolds on February 07, 2006 at 05:48 PM | Permalink | Comments (4)

In his XML Annoynaces blog, Micah Dubinko offers his perspective on software architecture and architects:

"It goes without saying that a major development project should have a solid architect at the core. A good architect needs to be able to separate personal preferences and prejudices from legitimate good design points--in other words, get the focus right. A concrete measure of an architect is whether outside groups--even ones that wouldn't normally be directly involved--are able to understand and accept the architecture. There will be times where it's just not possible to please everyone to the level of consensus, but still it provides a measuring rod against which to evaluate a design (or a designer)."

Micah is right; the true measure of an architect is whether or not they "get the focus right".

If you work with an IT group, you (like me) are probably involved in some sort of Service Oriented Architecture discovery or implementation project; Gartner predicts that SOA will provide the basis for 80 percent of development projects by 2008.

Given this huge trend towards SOA, we really need Service Oriented Architects who can "get the focus right".

Reuse is an often mentioned benefit of SOA, but I believe that SOA's key benefit is the closer mapping between business processes and the implementation. SOA meshes perfectly with Process Driven Design.

Many Object Oriented (Jave and C++) projects have great technical architectures, but the business process implementation ends up scattered across many modules and hidden in the code. When a business process changes (and they often do) it is quite often difficult (or at least tedious) to implement and deploy the process oriented changes: Not exactly what business wants.

I don't know why this happens, but I suspect a subtle impedance mis-match between form (architectural style) and function (what the program is meant to do). Perhaps Object Oriented architects tend to focus on UML Class Diagrams more than on UML Activity Diagrams?

Unlike Object-Oriented design, SOA is tailored to solve problems in a specific domain. As Miko Matsumura puts it:

"there are nearly an infinite number of software programming problems—game programming, graphics, engineering, mathematics, statistical modeling, you name it. The SOA that is getting people all hot and bothered isn't particularly interesting as a solution for all of these other problems. SOA is for business."

Service Oriented Architects need to focus on business processes and on business services. The SOA architect has to understand where a business process is likely to change, and where it probably won't. They need to understand factors that impact multiple process steps, and those that are specific to a single step. Without this level of business knowledge SOA architects will not be able to design services with the proper granularity, and they won't be able to design the proper data interchange model.

If this begins to sound a lot more like a Business Architect than a Technical Architect... I've made my point.

Can I call you back? - Asynchronous Web Services

Posted by johnreynolds on February 01, 2006 at 07:32 AM | Permalink | Comments (5)

Asynchronous Services are a fact of life, and a key requirement for successful SOA solutions. Doug Kaye summed it up well in his book, Loosely Coupled: The Missing Pieces of Web Services:

"Many of the benefits of web services can't be realized until asynchronous interaction becomes well understood and widely practiced, and some high-value applications can't be deployed properly or at all without it."

The simplest approach for implementing an asynchronous web service is to pursue a polling approach; the client makes a request, and then at a later time checks back to see if the response is ready. The advantage of this approach is that it is universally accessable... an AJAX enabled web page could easily handle polling. The down side is that... well... you are polling. Polling is probably the biggest waste of bandwidth we could devise, and you've got that nasty problem on the server: How long should I hold the response?

A more elegant approach for implementing an asynchronous web service is to pursue a callback approach; the client makes a request and leaves a return address (where the service should send the response). The obvious drawback to the callback approach is the limitation that it places on the client; the client must have a mechanism that allows it to receive messages.

Best practices suggest that you should support both polling and callbacks when implementing an asynchronous web service. Supporting both approaches will make your service accessible to the widest audience of clients, and that's a good thing.

Web Service Addressing defines standard SOAP headers for request and response messages. Most web service containers do not directly support this specification yet, but hopefully that's changing.

What would really help the average Java business programmer would be a "standard" technique for decoupling the code for implementing each asynchronous technique from the code that actually implements the business functionality of the web service. Why clutter up business logic with what is essentially messaging logic?

JSR 181 defines metadata for injecting web service aspects into POJOs, but it does not appear (to me at least) to provide for automating the creation of dual implementations (polling and callback).

My general feeling is that we are on the cusp of ubiquitous asynchronous web services, but we aren't quite there yet. It's still mostly a "roll-your-own" frontier, but the tracks have been laid and civilization is sure to follow.

Powered by
Movable Type 3.01D

java.net RSS Feeds