Todd Fast's Blog

Saturday, Jan 29, 2005

How to Use NetBeans APIs

While participating in the NetBeans DevRev process for NetBeans 4.1, I came across this handy document, How to Use Certain NetBeans APIs.

[Find more about at Technorati]

Interoperability and Document-Based Web Services

Sameer Tyagi has an extensive article (part 1, part 2) over at java.sun.com called "Patterns and Strategies for Building Document-Based Web Services". Nice work Sameer; keep 'em coming.

Friday, Jan 28, 2005

Developer Collaboration in Java Studio Enterprise 7 Reviewed on Developer.com

Michael Klaene has a nice review of Sun Java Studio Enterprise 7 over at Developer.com. In particular, he had several good things to say about JSE's developer collaboration features:

"The most interesting new feature to Java Studio Enterprise 7 is a team collaboration tool. This tool is essentially a code-aware Instant Messaging application within the IDE. After launching Collaboration Server (I used the server bundled with the development platform, but typically this would be a centralized server within an organization), I created a few accounts and practiced trading code and files between two users I created. When its time to share code, you select a button to let the tool know the type of code you are using (Java, XML, JSP), then enter it. The tool color codes and numbers the text according to the specified format, just as if you were using the IDE's main editor (it even completes code and provides JavaDoc links). It is also possible to share a file in which two team members can edit its contents simultaneously.

"The collaboration tool worked as promised during my tests. How relevant will this tool really be? For lone developers, the tool won't mean much. But I can certainly see a benefit when a team of developers is actively working with the same code base. I predict there will be many attempts by other vendors to duplicate this concept." [emphasis mine]

I have to agree with his final statement; I'm sure the developer collaboration space is bound to get more crowded over time, but the JSE group is not waiting around. Keep an eye on my blog for the scoop on some quite significant developments in developer collaboration over the next month. We're also planning some very interesting announcements and sessions for JavaOne 2005. Stay tuned!

[Find more about at Technorati]
[Find more about at Technorati]

Wednesday, Jan 26, 2005

A Spicy Site

A colleague pointed me to a terrific site that can tell you just about everything you'd want to know about spices, be it chemical, linguistic, cultural, or culinary: Gernot Katzer's Spice Pages. For instance, the entry on pomegranates has a fascinating discussion of "biblical spices" described in the Old Testament. I could easily spend a couple of hours reading Gernot's site (what am I saying, I already did).

Tuesday, Jan 25, 2005

Chris Webster's blog

He's kept quiet about it, but my colleague Chris Webster has a blog. Chris is an Open API black belt and was one of the lead engineers on the NetBeans 4.1 release. He worked hard to bring all sorts of cool J2EE development features to the NetBeans IDE. After a tour of duty in the NetBeans group, Chris is now back working with me on building Service-Oriented Architecture tools in the Java Studio Enterprise group. He's sure to have plenty of useful and interesting things to say in the coming year, so please pay him a visit.

HOWTO: Adding Technorati Cosmos Links to a Roller Blog

As I mention in the article below, my technique was primarily a hack to get around what I assumed was either a missing macro or missing documentation. Patrick Chanezon is more familiar with Velocity and has explained the proper way to escape links in Roller. Cheers, P@.

After seeing the convenient Technorati Cosmos links on Tim Bray's blog, I wanted to add them to my Roller-based blog. Unfortunately, it was a bit of trouble, so I'm blogging my findings here for my fellow Roller bloggers.

The Technorati Cosmos URL takes the following form:

http://www.technorati.com/cosmos/search.html?rank=&url=[blog permalink]

To use this URL, we merely need to supply the [blog permalink] in the template above and put the result in an anchor tag. In Roller, you can get the relative permalink (relative to the base domain and roller context path) with the following variable:

$entry.permaLink

However, if we want to avoid hard-coding the domain and Roller context path, you can prepend the following variable:

$absBaseURL$entry.permaLink

Now, putting this together in an anchor tag and remembering to escape the embedded URL, we have the following (note, this should all be one line when used in HTML):

<a href='http://www.technorati.com/cosmos/search.html?rank=&amp;
url=$absBaseURL$entry.permaLink'>...</a>

This almost works, but there is one subtlety with Roller's permalink syntax that caused a bit of trouble for me.

Specifically, Roller includes a document fragment in its permalink URL, and document fragments must be preceded by a hash mark (#). When tacked onto the end of the search URL above, the browser interprets the hash mark and fragment as belonging to the actual link instead of being part of the value of the url query parameter. Thus, when sending the search request to Technorati, the browser omits the fragment identifier and the search ends up returning the wrong result set. In order for the full permalink including the fragment identifier to be sent as part of the request, the hash mark preceeding the fragment identifier must be escaped so that it will be interpreted as part of the value of the url query parameter. Unfortunately, Roller doesn't include any macros (that I could find) to escape the hash mark.

My admittedly hack-esque solution was to use a little bit of JavaScript to escape the fragment identifier when the link is clicked. While this technique won't work if the user has turned off JavaScript, that condition is fairly uncommon these days; until someone addresses the missing macro in Roller, this technique should suffice for the majority of readers.

First, add the following JavaScript to your master Weblog page template's <head> tag:

<script language="JavaScript" type="text/JavaScript">
function replaceCharacters(conversionString, inChar, outChar)
{
    var convertedString = conversionString.split(inChar);
    convertedString = convertedString.join(outChar);
    return convertedString;
}

function escapeHref(object, inChar, outChar)
{
    object.href=replaceCharacters(object.href,inChar,outChar);
}
</script>

Now, modify your _day template and add the following anchor so that it appears once per entry:

<a href='http://www.technorati.com/cosmos/search.html?rank=&amp;
url=$absBaseURL$entry.permaLink' onclick='escapeHref(this,"#","%23")'>
...
</a>

Remember that although I've split lines above, you should put all of this on a single line in your template.

That's all there is to it. When the link is clicked, all hash mark occurrences in the href attribute will be replaced by the escaped form, "%23", before the URL is sent to Technorati.

[Find more about at Technorati]
[Find more about at Technorati]
[Find more about at Technorati]

Friday, Jan 21, 2005

Toddicus Fastius, 26 CE

My parents have been spending the last several years doing a huge amount of geneological research in their spare time. I'm not really suited to the task of doing such research, but I love to hear the results. In contrast to simply cybersleuthing online using sites like Ancestry.com, they've been researching in meatspace, scouring various documents, tax records, receipts, and church legers in rural parts of the Midwest, as well as conducting interviews with aged relatives and scanning tintypes and photos of people whose likenesses had been presumed lost. It's pretty remarkable to see photos of relatives many times removed. I'm sure it will be even more remarkable for our distant descendents who will have access to video, documents, email (perhaps even the V i @ G r A spam I get every day—will they even know what it was for?), and all sorts of other digital detritus we shed as a byproduct of our technology-infused lives. Merely considering the incalculable possibilities for insight my Thunderbird address book might present in a hundred years is mind-boggling.

While conducting research recently, my parents unearthed something I thought was even more amazing, however. They had been researching my grandmother six degrees removed on my mother's side, which to me was already pretty remarkable; it's hard to imagine that they could trace back that far given the number of undocumented children, multiple marriages, premature deaths, and other glitches that often bring geneological research to a standstill. Despite the odds of just getting that far, they were able to connect this gggggggrandmother to research someone that else had published on Ancestry.com. Remarkably, this research went back nearly 2,000 years to a citizen of the Roman Empire in 26 CE! I've yet to get the full scoop from my parents, but according to them, this improbable genetic journey wound through places like the Near East, Northern Asia, and Western Europe, and included at least one pass through Norwegian royalty.

Now, I'm the first to admit that it's extraordinarily hard to believe that such research could be supported by rigorous evidence...but, if by some astronomical chance it is valid, it means that I had a Roman relative that lived in the Near East as a contemporary of Jesus. I say this not because it's at all special in itself—we all have relatives that were contemporaries of Jesus (or Siddhartha, or Mohammed, or Zoroaster, or any great historical figure), not to mention I'm probably related to a statistically significant percentage of you reading this right now—but the fact that this person's name could be known 1,979 years later bakes my noodle. Regardless of its veracity, I consider it a good story, and especially for an American, a lesson on our often tenuous connection to the past before 1776.

[Find more about at Technorati]

WS-Confusion

Hardly a day goes by that I don't wish for a specification-less world, especially when it comes to the steady dribble of WS-* specs that just won't stop. Tim Bray has made some amusing remarks about the situation (also check out Matt Powell's rebuttal), but if you ever wondered how the WS-* specs get done, check out the Web Services Protocol Workshops Process Overview by our friends at Microsoft. Or, if you just want to know what the heck is going on, Matt's blog has a nice pointer to a Microsoft whitepaper, An Introduction to the Web Services Architecture and Its Specifications.

[Find more about at Technorati]

Thursday, Jan 20, 2005

Thinking about Web services policy

While scrounging around for WS-Context info, I also found this nice blog entry on Web services policy from Greg Pavlik. Specifically, Greg makes several compelling arguments for why policy should not be part of a service's WSDL description. Thanks, Greg.

[Find more about at Technorati]

Some context on WS-Context

I stumbled across this meaty WS-Context presentation by Aad van Moorsel at the University of Newcastle. He has some interesting things to say about using context for multilateral conversation (which I discussed in an earlier article). Some related reading: the WS-Context spec; Web Services Composite Application Framework (WS-CAF); some comments from Greg Pavlik over at Oracle.

[Find more about at Technorati]

Wednesday, Jan 19, 2005

It's official: I'm now a tech blowhard

Despite years of toiling under unofficial status, I can now officially be labeled an arrogant, myopic, out-of-touch, tech blowhard: I registered toddfast.com and for the time being have pointed it here to my blog at Sun. Despite the typical track record of people with vanity domain names, I couldn't resist given that it was still available after all this time (the last time I checked must've been some time last century); then again, my name is far from common. I do feel a few small pangs of guilt and shame at the indulgence, but in any case, it's considerably pithier than http://blogs.sun.com/roller/page/toddfast.

The Great Metadata Revolution -or- Why You Can't Keep Good Development Tools Down

This article discusses some consequences of the introduction of metadata annotations to the Java language, and how instead of obviating application development tools, annotations will in fact make them all the more valuable.

Annotations to the Rescue?

As most of you already know, the Java Development Kit 5.0 (or JDK 1.5 for the traditionalists) introduces language-level metadata via annotations, the general syntax of which are specified in JSR-175. In addition to several novel uses, annotations offer a partial solution to the overbearing complexity of building enterprise applications in J2EE and other application environments. For example, EJB 3.0 will use annotations to generate home and remote interfaces for an EJB from a single source artifact. Annotations allow what is generally known as metadata-driven programming, in which metadata is attached directly to programming constructs to precisely describe their semantics. Over time, the increasingly overused (and widely disliked) XML-based configuration technique most of us are used to will be replaced—or at least largely supplanted by—use of metadata specified via annotations directly in source code.

As the Java-based software industry (and the software industry as a whole) moves toward what ex-Microsoft employee and Intentional Software's founder, Charles Simonyi, calls Intentional Programming (IP), Java annotations will be a key element of reducing the overall complexity and amount of hand-coding needed to perform application development tasks. Annotations formalize the semantics of program elements, for the first time making it truly possible to define what it is that a developer knows but heretofore could not express formally in the actual application source. That is, metadata encoded in annotations help get knowledge out of developers' heads and put it directly into the source without requiring an irreversible translation to traditional programming constructs. The savings in terms of maintainability, portability, and transparency of Java applications will be very real, though it is perhaps still a bit early for most developers and architects to understand just how fundamentally annotations will change how they go about application development. Trust me when I say that annotations in Java will change everything you think you know about application development—they represent a true revolution for the Java platform.

With the introduction of annotations and metadata-driven programming for the Java platform, there are a few questions that are only just being asked by the general developer community. One of these is how annotations will affect application development, and specifically, how will they affect application development tools? Does the introduction of annotations mean that development tools will wane in their usefulness until we somehow arrive at a Nirvana where programming is so easy that all we need is the simplest of text editors to write the most complex applications?

I imagine there are a few people who would like nothing more, and for the small but outspoken group of developers who prefer to code every line by hand, annotations in their simplest form represent a potentially huge leap forward in productivity. However, these gains won't last, and thus the answer to the question posed above is a resounding no (which is fortunate for me, a tool architect in Sun's Enterprise Java Tools organization). Let me explain why.

Complexity Begets Metadata Begets Complexity Begets...

Metadata via annotations is one solution to the increasing complexity of application development. Rather than manage a number of separate artifacts (source code, metadata, etc.) that must be carefully kept in sync, annotations allow metadata to be attached directly to programming constructs. Although in the near term the same effective information may be stored in, say, an XML deployment descriptor and the first-generation of annotations now being defined (thereby making them semantically equivalent), language-level annotations are ultimately more capable, more powerful, and more convenient than metadata stored separately. In short, annotations, being easier to use, lead to increased use of metadata.

This is a a great result—increased use of metadata is a boon for application development because it makes more possible using less. But, it has at least one significant drawback: annotations become complex and unwieldy after a certain point. This is by no means an annotation-specific issue; any set of information becomes unwieldy and hard to manage when it passes a certain size. In the case of annotations, they work quite well when only a few are used and structurally they are relatively simple. However, the more numerous and precise the semantics of the elements being annotated, the more unwieldy annotations become as their number and structural complexity grows.

To that point, many people don't yet realize that annotations are themselves Java types, with most of the capabilities of traditional classes and interfaces. Furthermore, many people I talk to don't yet realize that annotations can effectively be arbitrarily complex, just like other types defined in Java. If you are familiar with JavaDoc-style attribute annotations (such as those used in XDoclet, whose values consist of just arbitrary string values), this is actually quite a difference. Annotations can be specified with most of the complexity found in normal Java classes, thus making them far more powerful and robust, but also potentially quite complex.

Although the nominal situation today is that there are few (if any) annotations used per unit of actual code, this trend will very quickly change as the complexity and adoption of annotations grows exponentially. The more that can be done by annotating something, the more annotations will be used. Our work here in the Java Studio Enterprise group has shown that it takes just a handful of annotations before they begin to overwhelm the element with which they are associated. It certainly can seem a bit ridiculous to see a one-line method with twenty lines of annotations preceding it, but in order to achieve the order-of-magnitude productivity gains that metadata-driven programming brings to the table, it is largely unavoidable and will become increasingly common.

Does this mean we're back in the same boat we were in before annotations were introduced? Frankly, yes and no. Keep in mind that once we begin talking about application development using metadata and annotations, we have suddenly begun talking about a fundamentally different type of application development. It may not yet be apparent, but we have entered a new era in which application complexity will increase by at least an order of magnitude, all made possible by extensive use of metadata. However, by using metadata (and eventually meta-metadata, meta-meta-metadata, etc.) application development itself doesn't need to become more complex, especially where tools can assist in limiting the impact of these quantum shifts.

Ultimately, application development is a zero-sum game—any gains in the ability to do more with less are almost immediately erased by the fact that even more complex problems become solvable. Thus, we've essentially just refactored the application development problem by introducing metadata-driven programming to Java. The tasks developers perform today will become easier in the short term, but these gains will soon be outstripped by the increasing complexity of next-generation applications. This is not something to lament; rather it is just the way of the world. For example, in the same way that 2nd-generation languages (2GLs) supplanted 1st-generation languages when they became too complex to use for generalized software development (a ridiculously short journey), 3GLs eventually supplanted 2GLs, and now Java plus metadata has effectively become a 3.5GL, featuring many of the benefits of a 4GL via annotations while retaining its general 3GL nature. Such is the technological treadmill that we perpetuate.

So, if annotations are ultimately not the long-term solution to application development complexity, what is? The answer should hopefully come as no surprise.

The Value of Development Tools

The oft-misunderstood and underestimated mission of development tools is essentially three-fold:

  1. Sanity - to make sense of a complex world on behalf of the developer
  2. Simplification - to reduce complexity and cognitive load for the developer
  3. Speed - to increase developer productivity

I assert that the Three S's as I'll call them (or S^3 if you prefer) have been put to the test and proven true over and over again. Despite their near-term appeal as a way to reduce complexity in hand-written code, annotations will not decrease, but will in fact dramatically increase, the value of development tools.

This conclusion may initially seem counterintuitive, but upon reflection should be apparent. Apart from temporary improvements achieved by quantum shifts in methodology (of which the introduction of annotations is one), the long-term solution to application development complexity has always been the presence of good development tools, regardless of the technologies involved. Although development tools going forward using annotations will be significantly different than tools we have all used in the past, the fact that we now have annotations at our disposal really has no bearing on the fundamental value of tools because the level of complexity of the application development problem itself will essentially remain unchanged. We will instead now be able to achieve more for a given amount of effort, but the required level of effort will remain constant.

Ultimately, as a tool provider, I see annotations and metadata-driven programming as greatly beneficial to my business, and using them I look forward to helping developers tackle the next level of complexity in application development. Long live metadata, annotations, and good development tools!

[Find more about at Technorati]
[Find more about at Technorati]

Friday, Jan 07, 2005

Academic work on BPEL

Last year, Paul Brown at FiveSight conveniently listed a number of links to academic work done on BPEL.

[Find more about at Technorati]
[Find more about at Technorati]

Thursday, Jan 06, 2005

Texas Twang

Hmm, is there an upsurge of general interest in linguistics lately? I just watched the last half of "Do You Speak American?" last night on PBS, and now Yahoo! is running a story on the Texas twang. I moved to Texas from the Midwest when I was 5, and aside from a few "y'alls" and the occasional "tump" or "fixin' to", I never picked up the accent. In fact, quite the opposite: the constant teasing over my nasal Midwesternisms purged nearly all regionalism from my speech.

Web Service Standards List

A handy list of Web service standards from BEA.

Archives

Tags

Feeds

Search

Links

Navigation

Referers