Todd Fast's Blog

SSDL - The SOAP Service Description Language

One of the big gaps in building real-world Web services is that there is no common description of the semantics of a service and its operations. WSDL tells a service consumer how to invoke a service, but not why or in what order. In other words, WSDL gives syntax, not semantics. As a result, this information must be transmitted out-of-band to service consumers, where it is likely to be misplaced, misinterpreted, or ignored. Just this month, the SSDL spec was released by folks over at ssdl.org with the goal of filling at least some of these gaps.

--
Posted at 05:55PM Feb 28, 2005 by Todd Fast in Web  |  Comments[0]
Tags: /
Like this post?  |  | | |

A "Generic" Parody

For those of you confused, elated, or otherwise opinionated about the addition of generics to Java, check out this hilarious parody from Spud over at madbean.com.

--
Posted at 12:59PM Feb 28, 2005 by Todd Fast in Software  |  Comments[0]
Tags: /
Like this post?  |  | | |

Very Positive eWeek Review of Java Studio Enterprise 7

Peter Coffee of eWeek has published a very positive review of Java Studio Enterprise 7.

Sun's Java Studio Enterprise 7 is an impressively complete and smoothly integrated package for building Java applications in team environments, with unique and useful IM capabilities tailored to developers' needs. Its interaction among code and diagram views is unsurpassed.

In particular, he praised JSE's unique developer collaboration features:

Teams may become addicted to Sun's development-oriented instant messaging facility, with a syntax-aware editor and collaborative editing tools integrated into the workbench. Long listings or outputs can be sent, without the message-length restrictions that hamper lightweight IM systems.

When another developer is editing a shared file, affected lines are highlighted and guarded in other team members' windows to prevent collisions while enabling simultaneous work in different sections of the code. Sun officials promise to expand support for XMPP (Extensible Messaging and Presence Protocol)-based run-times; messaging security can be configured using HTTPS (HTTP Secure) and SOCKS Version 5. The system is easy to use and could quickly make converts of those who've never before found IM compelling.

Peter didn't mention all the cool developer collaboration features, so check out my developer collaboration webinar for the skinny, including a demo (the demo starts about 20 minutes in). Afterward, mosey on over to the Java Studio Enterprise 7 Try and Buy page to download a 90-day free trial.

[Find more about Collaboration at Technorati]

--
Posted at 07:08PM Feb 15, 2005 by Todd Fast in NetBeans  |  Comments[1]
Tags: /
Like this post?  |  | | |

Chiba: a Java-based XForms implementation

From the Chiba homepage: "Chiba is an Open Source Java Implementation of the W3C XForms standard 'that represents the next generation of forms for the Web'." Unlike most open source projects, the documentation for Chiba is terrific. Also check out the official XForms page at the W3C.

--
Posted at 03:17PM Feb 12, 2005 by Todd Fast in Software  |  Comments[0]
Tags: /
Like this post?  |  | | |

'Tools for X': Frustrations of a Tool Architect

A Common Situation

As a tool architect, I often hear from various teams or other engineers that they want me to build "tools for X", where X is some specific technology. Such requests are well-intentioned but often misguided. In such requests, I believe there are two factors at work:

1. Most engineers are impressed by tools
2. Tool concepts are unknown to most engineers

Engineers generally love tools and understand their appeal, even if they can't always articulate what makes one tool more useful, easier-to-use, or more productive than another. I tend to think that this is the result of being primarily tool users and not tool authors; tools are a specialized domain like any other and require a certain amount of experience from an author's perspective in order to fully understand and articulate the opposing forces that must be balanced when designing a good tool.

Yet, the perspective of the non-tool experts is entirely understandable. In the broadest sense, a tool is just a piece of software specialized for making some task easier, and in this sense, all software qualifies as a tool to someone. Every professional technologist has used thousands of tools, and written perhaps hundreds of them in some form or another. Tools come in many distinct flavors—administration tools, analysis tools, application development tools, compiler tools, programming tools, Mars rover path plotting tools, and many more. However, for those unaccustomed to speaking about these specific variations, they are all just "tools". This leads to a fundamental disconnect between those immersed in tools and others who are not, and this is the primary motivation behind requests for tools for X.

I believe the main gap in understanding is that one can only understand a tool by understanding what general problem its user is trying to solve. This problem definition and the use cases behind it are usually implicit assumptions of someone when they ask for tools—they have a hard time solving some problem P, in problem domain D, using X. Naturally, they want a tool to help with X, but P and D often go either unmentioned or under emphasized. The hard part for those not accustomed to it is in understanding and judging the applicability and relevance of D, the problem domain, to a broader audience.

Let's take an example. I encounter a common perspective in my interactions with various Java technology groups at Sun. For years, Sun has been pumping out great specs and technologies at a phenomenal rate, and we have armies of brilliant people relentlessly expanding the boundaries of the state of the art. But most of these people are not tools experts (nor should they be). They are experts in other areas, but they all sense the need for great tools that enhance the value of their various technologies. But what are tools for X when X is JAX-RPC, JMS, or JBI? Is it possible to write tools for these technologies? Yes, absolutely. But the question we must ask is: should we?

A $4,000,000 Hammer?

How do we answer the question of whether we should build a tool for a specific technology? There are any number of equally valid axes on which we could measure value, but there is one constant goal for tools: adoption. Tools must be adopted in order to be useful; indeed, the only true value of a tool is in codifying a solution to something that it is otherwise hard to do over and over again into a repeatable, easy to replicate form. The value of a tool grows in direct proportion to the number of times it will be used. Thus, we can make a decision on the attractiveness of a tools-for-X request by evaluating whether the resulting tool will be of use to a sufficient number of users such that its development and maintenance costs are justified. Few people can afford to build a $4,000,000 hammer to pound $0.01 nails (though some part of me can't resist thinking what an awesome hammer it would be).

So, using this simple yardstick, do tools for, say, JAX-RPC the technology make sense? Given its current state and the way it is used in the industry, my answer is no. This isn't to say that tools for JAX-RPC wouldn't be of terrific value to some people, but it would be hard to argue that they would be terrific value to most people.

The primary reason is that JAX-RPC is just one technology out of hundreds that developers will use to build something that will solve a broader problem they face. The real problem that developers have is not in using JAX-RPC per se; although that may be difficult in itself, it's just a speed bump on the much-longer road to something bigger—the application. JAX-RPC will be just one small part of an application. The meat is not in tools for JAX-RPC, but in tools for using JAX-RPC and a large number of other technologies together in order to build an application.

The Reason Behind The Request

I tend to think that Microsoft panders to users when it uses the slogan, Where do you want to go today?™, but this question is actually the beginning of wisdom when applied to tools. Tool writers—and Microsoft is arguably at the top of the heap—must always start with this question when confronted with a request from someone asking for tools. It's dangerous to take such a request and execute on it blindly, as the result will almost certainly be a failure because the underlying reason behind the request for tools was not discovered.

In nearly all cases, people that ask for tools for X are actually asking for tools for application development, where application is a fluid concept. An application is really a solution to a heterogeneous, recurring set of problems, independent of any particular problem domain. An application is the bringing to bear of a solution to an instance of a recurring problem set. When this solution is canned for reuse, we call it a tool.

As an example, to engineers building say, JAX-RPC, one recurring problem they encounter is likely to be the building of JAX-RPC services (perhaps in order to test that all the other one-off, non-recurring problems they've been working through in the creation of JAX-RPC have been actually solved). This then becomes their problem domain, and naturally they gravitate toward thinking of tools for JAX-RPC as the specific problem domain which they need help solving repeatedly. However, JAX-RPC will be just one small part of another, broader type of application that includes many more parts, and many more technologies.

I'm not trying to be hard on the JAX-RPC people here; they are just serving as a convenient technology example. But the disconnect I've hopefully illustrated is at the core of quite common misunderstandings around what a tools organization is, and what it should be doing when building tools.

Give 'Em What They Want

As a part of the Enterprise Java Tools group at Sun, I believe our ultimate goal is to give people the tools that they want. And what do they want? Well, this is the enduring question in the tools business, and knowing the answer is a key part of running one. But, there are some pretty obvious clues to the right answer, which I think I can illustrate with a few specific examples: most people don't want administration tools, because administrators are few and far between; most people don't want JBI deployment tools because integration architects are rare (at least today); most people don't want disk format tools because the need to reformat a disk is infrequent; etc.

No, what most people want are application development tools. But what type of application? For the Java Studio Creator group, application means the traditional, Web-based, business application where information is collected from users via forms and processed information is then reported back to them. This is arguably the most prevalent type of application today, and the one that most people refer to implicitly when they use the term "application". This type of application and its related patterns are quite well-understood in the tools industry now, and the stratospheric ease-of-use and capability that tools for this application type have achieved is quite remarkable.

However, in the Java Studio Enterprise group, the definition of application is significantly different. Although there will always be a need for corporate applications, developers are beginning to focus less on building the same kinds of corporate applications over and over again. Instead, focus in the industry is now moving quickly toward Web services and service-oriented architectures used to solve advanced integration and B2B requirements. I contend that this is a new era, and now that corporate application development has been solved well within the Java realm, attention has turned to the next frontier: distributed applications that consist of heterogeneous, loosely-coupled services which collaborate in ways more complex than traditional client-server, human-to-computer interactions. These new types of applications are an order of magnitude more complex, and all the more difficult to build good tools for. For me, it's an exciting time to be building application development tools, and there's no time to waste building "tools for X".

--
Posted at 06:16AM Feb 10, 2005 by Todd Fast in Developer Tools  | 
Tags: /
Like this post?  |  | | |

Developer Collaboration in JSE7 Webinar Available

The developer collaboration webinar I recorded last week has now been posted to Sun's public website:

http://wcdata.sun.com/webcast/archives/GSN-1924/index.html

In the webinar, I discuss what it means to collaborate with other developers within an IDE and then demonstrate presence, code-aware chat, and multi-user simultaneous file editing as integral parts of the development environment. Check out the webinar to see all these features live in Java Studio Enterprise 7. If you have any questions after watching the video, feel free to post them as comments here.

[Find more about Collaboration at Technorati]

--
Posted at 05:55PM Feb 08, 2005 by Todd Fast in NetBeans  |  Comments[1]
Tags: /
Like this post?  |  | | |

The Missing Link: From Objective-C To Java

I took a different professional trajectory than most of my peers: I received a degree in mechanical engineering but quickly decided to become a "corporate" developer using Paradox, Delphi, VB, and PL/SQL instead. Although I'd been programming since about age 10 on various pre-PC machines, to get where I am today, I had to slowly work my way down through layers of abstraction and technology on my own without the benefit of a formal computer science education (this has its benefits I suppose, but I can't really recommend it). As a mechanical engineering student a couple of years before the Web was invented (yikes!), my exposure to then-current technology was limited. For a time, various engineering algorithms in FORTRAN running on VAX mainframes were a daily headache (along with a semester's addiction to a MUD), though over time there were increasing uses for Macintosh word-processing and DOS-based MATLAB. In any case, as a result of this history, I'm generally quite interested in programming languages and various technologies outside my daily experience. So, over the weekend, I did some reading about Mac OS X and Cocoa to look at things from another perspective. This led me quickly to Objective-C, Cocoa's language of choice.

In the past, I'd skimmed information on Objective-C, but at the time its similarity to Java escaped me. I'd also previously studied Smalltalk and saw the similarities to Java there, but it wasn't until I read Apple's Objective-C description that I realized that much of the Smalltalk I saw in Java was filtered through Objective-C and OpenStep instead (of which the latter, not coincidentally, my employer was a big part). That Objective-C was an inspiration for Java isn't exactly a secret, yet no one seems to ever mention it, even here at Sun. What I was most surprised by, however, was the sheer level of similarity between the two languages.

Objective-C is so similar to Java that it's a fairly trivial matter to adjust one's Java mindset to it. Many of the things I love about Java are present in Objective-C. For example, Objective-C encourages interface-based development using what it calls protocols. Objective-C also has a strong runtime component, which normalizes its usage across platforms and offers a very high level of built-in capability. Objective-C even has a couple of features I wish were carried over into Java, like categories. (Poor choice of name but oh, how I've wished for such a feature...) There are some significant differences too, like the Smalltalk-inspired syntax addition to C and the fact that message selectors (method names) exist in a global namespace without regard to number or type of message parameters (this is similar to XML without namespaces, which was a problem when it was initially released). The lack of garbage collection is also a major difference.

When reading the Objective-C language description, it's easy to see how certain features were streamlined to create their Java counterparts. For example, it's obvious that Objective-C's use for the id pseudo-type apart from the NSObject formal type was obviated in Java by eliminating the C legacy. One day I'll have to ask James what his perspective is on the amount that Objective-C influenced Java. To me, however, although I know it wasn't the only influence, when reading about Objective-C, it's almost impossible not to feel that Java evolved as a network-aware, small-footprint alternative. There certainly was, and still is, a place for Java as a distinct language and platform, but in some ways it's too bad Objective-C didn't go further. There are surely many reasons for this, but I credit Objective-C's legacy as one stumbling block. Its C and NeXTSTEP origins introduced cruft that was nicely eliminated in Java, with the result being a far more consistent and friendly language--at least until generics were added. <grin> (Don't get me wrong, I love the support for generics introduced in JDK 1.5, but it doesn't do anything to make the Java language easier to read or understand.)

Although nothing will keep me from Java, it'd be nice to jump over into Objective-C once in awhile, if for no other reason than as a change of pace. But, there are a couple of hurdles. First, there isn't a good implementation of OpenStep that is sufficiently cross-platform. This is one of the things I love about Java, and although GNUstep is attempting to provide a portable OpenStep implementation, they're falling short for at least one major platform, and in particular their AppKit implementation is (still) lame. Second, Apple has extended Cocoa nee OpenStep in ways that are very attractive, but again, unavailable anwhere but on the Mac platform (as intended I'm sure). Finally, there are no good-but-inexpensive tools for Objective-C except Xcode and Interface Builder on the Mac; as nice as these tools are, in most ways they aren't really up to the level of capability of a modern Java IDE.

Even though it doesn't seem likely that I'll be writing Objective-C code any time soon (particularly since Cocoa supports the Java language nearly as well), learning about it and its history has been an eye-opening journey, and superb insight into the history of the programming language I use daily. Hats off to Apple for keeping Objective-C not just alive, but vibrant, and to the innovations in language and tools from which we unwittingly benefit today because of it.

--
Posted at 01:07PM Feb 07, 2005 by Todd Fast in Software  |  Comments[1]
Tags: /
Like this post?  |  | | |

Thanks for attending!

Thanks to all of you that attended my developer collaboration webinar this morning. If you weren't able to attend, the webinar was recorded and will be posted on http://developers.sun.com shortly; keep an eye out here and I'll announce when and where you can get it as soon as I know. In the meantime, if you have questions or feedback about developer collaboration or any of the other things I discussed in the webinar, please feel free to add comments to this entry or mosey on over to the Java Studio Enterprise 7 forum and post a message. If you'd like to start co-coding with your colleagues now, you can download a free, no limits, 90-day trial of Java Studio Enterprise 7 at our Try, Buy, or Upgrade site.

--
Posted at 11:04AM Feb 03, 2005 by Todd Fast in NetBeans  |  Comments[1]
Tags: /
Like this post?  |  | | |

Developer collaboration webinar @ 10 AM today...it's not too late!

It's not too late to register for my developer collaboration webinar on Thursday, February 3rd @ 10 AM PST. Learn how to use developer collaboration in Java Studio Enterprise 7 for real-time, multi-user communication and coding. See my previous post for full information.

[Find more about Collaboration at Technorati]

--
Posted at 06:00AM Feb 03, 2005 by Todd Fast in NetBeans  |  Comments[0]
Tags: /
Like this post?  |  | | |

Developer collaboration webinar @ 10 AM Thursday...it's not too late!

It's not too late to register for my developer collaboration webinar on Thursday, February 3rd @ 10 AM PST. Learn how to use developer collaboration in Java Studio Enterprise 7 for real-time, multi-user communication and coding. See my previous post for full information.

[Find more about Collaboration at Technorati]

--
Posted at 07:34PM Feb 02, 2005 by Todd Fast in NetBeans  |  Comments[0]
Tags: /
Like this post?  |  | | |

How to write Java apps for TiVo in NetBeans

Yesterday, TiVo announced that they were releasing their HME SDK to rev up third-party development for their platform. It's a great idea made even better because the toolkit is Java-based. Shortly after the announcement, NetBeans evangelist Tim Boudreau released this article on writing applications for TiVo using NetBeans.

[Find more about NetBeans at Technorati]

--
Posted at 01:55PM Feb 02, 2005 by Todd Fast in NetBeans  |  Comments[0]
Tags: /
Like this post?  |  | | |

Abe Vigoda is...alive!

Upon hearing of the Pope's illness, I rushed right over to see if another of my favorite octogenarians was doing alright. According to abevigoda.com, Abe is still OK. Well, at least he was when I posted this.

Abevigoda.com is a simple website with a terrifically funny concept. The best part is the subtle font difference between the word alive and the rest of the page, as if at any moment the website would be updated were Abe to pass on. It's almost as if Abe were himself connected to the Internet, just like my toaster will be someday. I suppose this is fitting: In general, I like to think of Abe as leading us boldy into the future, with just an occasional bathroom break along the way.

--
Posted at 05:09PM Feb 01, 2005 by Todd Fast in General  |  Comments[0]
Tags: /
Like this post?  |  | | |

Register for My Developer Collaboration Webinar on Thursday

I will be giving a free webinar covering developer collaboration in Java Studio Enterprise 7 on Thursday, February 3rd, at 10 AM PST (see link for your local time). I'll be describing our vision for developer collaboration in JSE and then giving an in-depth demo of the product. We'll also have a Q&A session to answer any questions you may have. If you're interested in attending, please head over to the webinar registration site and sign up.

[Find more about Collaboration at Technorati]
[Find more about Developer Collaboration at Technorati]

--
Posted at 04:54PM Feb 01, 2005 by Todd Fast in NetBeans  |  Comments[0]
Tags: /
Like this post?  |  | | |