Todd Fast's Blog
Dependency injection vs. service locator
This article by Martin Fowler describes the dependency injection and service locator patterns and offers some pros and cons of each.
As interesting and useful as dependency injection and inversion of control (IoC) containers are, I tend to agree with Martin's conclusion that the service locator is a somewhat more straightforward pattern, especially if a standard locator mechanism like JNDI is available. On the flip side, as developers become more and more accustomed to dependency injection, particularly as a primary idiom for application development, it does offer some interesting opportunities to (at least seemingly) reduce application complexity.
--
Posted at 12:52AM Nov 18, 2004
by Todd Fast in Web |
Comments[1]
Tags: /
Like this post?
| 
|
|
|
Prague, Belarusians, and a drink to avoid
Well, I'm off to Prague in 12 hours or so for some in-depth discussions with the NetBeans group. I can't say I'm looking forward in the least to the 14-hour ride in coach. The last time I went to Prague (exactly one year ago this week), I was lucky enough to sit next to a couple of friendly Belarusian's with a 2-liter bottle of duty-free vodka. The bottle didn't survive the trip, but it was a great way to enjoy a long trip compared to shelling out for business class. I don't expect to get that lucky this time, but at least I'm looking forward to some cheap liters of pilsen and some medovnik once I get there.
This time around, though, I will definitely not be ordering what the bartender at the Diplomat told me was a fave among Prague youth: shots of Red Bull and absinthe. <shudder> Contrary to someone's assumption, combining two horrible-tasting drinks doesn't make them taste better--quite the contrary, in fact.
Don't actually try this, but here is a guess at a recipe to approximate the taste of this horrible concoction, since absinthe is largely unavailable in the US (though actually it's not illegal, as most people think):
- 1 can of Red Bull
- 3 aspirin tablets (for the bitterness)
- Handful of grass clippings (for the sickening plant flavor)
- Everclear (for the kick)
--
Posted at 02:35AM Nov 14, 2004
by Todd Fast in General |
Tags: /
Like this post?
| |
|
|
Congrats to Matt!
My friend and colleague, Matt Stevens, had a brand spanking new addition to his family today. I will leave the details to him to publish once he gets some rest. Congratulations!
--
Posted at 08:10PM Nov 12, 2004
by Todd Fast in General |
Tags: /
Like this post?
| |
|
|
What The Unclean Masses Are Thinking: Yahoo's Buzz Index
Today I noticed Yahoo's Buzz Index feature that purportedly provides insight into mass culture by uncovering nodal points for all to see. Cool, but few surprises overall.
However, from looking at the leader board, it's obvious that a significant fraction of Yahoo's users are likely to be video-game playing, urban-music-listening, Oprah-watching (?), teenaged boys. Although Yahoo screens out all adult-themed searches, I have a feeling that the leader board would remain eerily the same even if they were included.
--
Posted at 07:55PM Nov 12, 2004
by Todd Fast in General |
Comments[1]
Tags: /
Like this post?
| |
|
|
Final Hours of Half-Life 2
Check out this great article at Gamespot describing in great detail the saga of Valve's soon-to-be-blockbuster game, Half-Life 2.
--
Posted at 06:34PM Nov 12, 2004
by Todd Fast in General |
Tags: /
Like this post?
| |
|
|
Java Studio Enterprise 7 Press Release
Sun just published a press release that has a few nice blurbs on developer collaboration features in Java Studio Enterprise 7.
--
Posted at 01:29PM Nov 09, 2004
by Todd Fast in NetBeans |
Tags: /
Like this post?
| |
|
|
JavaOne Developer Collaboration Demo Video
For those of you who missed the live version, here is the video of the Java Studio Enterprise 7 developer collaboration demo I gave during James Gosling's keynote at JavaOne 2004. The demo is about 12-15 minutes in, after Tor Norbye's Java Studio Creator demo and Matt Stevens' Java Studio Enterprise UML demo.
--
Posted at 06:48PM Nov 05, 2004
by Todd Fast in NetBeans |
Tags: /
Like this post?
| |
|
|
Declarative MIME resolvers in NetBeans
Ever wondered how to recognize an XML file without opening every candidate file in your DataLoader and parsing it? Let NetBeans do it for you by using a declarative MIME resolver.
--
Posted at 06:29PM Nov 05, 2004
by Todd Fast in NetBeans |
Tags: /
Like this post?
| |
|
|
Tips for using NetBeans SystemOptions
A colleague asked me a few questions about using SystemOptions in NetBeans 3.6 today, so I thought I'd blog my response for everyone else. SystemOptions are the nodes you customize in the IDE's Options dialog. Unlike when using other parts of the Open API, developers generally don't usually create nodes here directly (though this is possible); instead, they define instances of SystemOption beans and the IDE takes care of presenting these instances as nodes. SystemOptions are pretty well-documented, but there are a few things that bear clarification.
First, for our purposes, all SystemOptions are JavaBeans. This means that they have accessor and mutator methods conforming to JavaBean conventions, and that they use BeanInfo to allow friendly editing in the property sheet.
The actual bean instance and how the IDE gets to it is specified in a .settings file that you include with your module and reference from your module layer file. This settings file is in a NetBeans XML format and it not only indicates the type of the instance (and all its superclasses, interfaces, and superinterfaces), but it also tells the IDE which method on which class can be called to create (or return a reference to) a singleton instance.
All of this is well-documented in the SystemOption JavaDoc, so no need to repeat it here. Note, one thing that may not be immediately clear from the docs is the fact that settings files (and any other file declared via the url property) are resolved relative to the layer file location, unless you use an absolute URL beginning with a slash (/). In other words, the resolution rules are the same as URLs in HTML/HTTP.
One caveat when using the settings file is how much information you specify. If you leave out a crucial type declaration, like java.io.Serializable, the option may not be instantiated or may otherwise behave strangely. To be safe, always include all type declarations for the SystemOption in your settings file.
In order for your option to appear in the IDE, it must be declared in a particular location in your layer file. Specifically, it must be declared as a child of the /UI/Services/ folder. It's tempting to just place the reference to the settings file here directly, but this prevents it from being picked up by the default lookup and can potentially cause unexpected behavior. Instead, you should place the instance in the /Services/Hidden/ folder and mirror it in /UI/Services/ folder using a .shadow file reference to the original. You can find full information in the Services API overview docs.
Once you've created and installed your option, you will want to make it friendly to edit by adding a BeanInfo class. This works just like it does for any other JavaBean, with one subtlety. In NetBeans, the BeanInfo's list of PropertyDescriptors is used not only for display of properties, but also to decide which properties will be persisted between IDE sessions. Therefore, unlike other uses of JavaBeans, you cannot omit a property from the PropertyDescriptor list to hide it from the UI while also saving the value of the hidden property. Furthermore, if I recall correctly, the hidden property of the PropertyDescriptor is not respected when displaying the option. If you want to keep some hidden options, create a new option class, place it in the /Services/ folder, but omit it from the /UI/Services/ folder in your layer. It will then be persisted if changed (from your module code), but will not appear in the UI. This is useful if you want to do something like remember selections, dialog locations, or anything else that the user doesn't want to manipulate.
--
Posted at 07:21PM Nov 04, 2004
by Todd Fast in NetBeans |
Tags: /
Like this post?
| |
|
|
A Conversation about Web Service Conversations (Part 1)
This article distills some of my thoughts surrounding Web service conversations—a seemingly easy-to-grasp concept that can be surprisingly subtle. As I have the time, I hope to add more parts to this article; if you have suggestions, please feel free to add comments here.
What is "Conversation"?
Conversation in the Web services domain is a set of semantics overlaid atop a lower-level series of message exchanges. Any particular message exchange may or may not be considered part of a conversation.
Conversational state is the full set of information pertinent to these exchanges. Conversational state may be centralized (for example, in a message's content) or distributed (for example, in various stateful service instances), depending on the way conversation participants interact. It's important to understand that, technically, conversational state is not necessarily limited to business protocol state. Rather, conversational state may also be information pertaining to the ability of a particular service implementation to act on a message. For example, a set of configured components inside a service implementation may be considered part of the conversational state, even though it is static and unchanging across multiple conversations (though presumably not across all).
I can think of two broad perspectives on the meaning of the term conversation:
- As describing a causal set of message exchanges, where the causality implied by these exchanges is meaningful in some regard (though perhaps this "meaning" is simply the recognition by an omniscient observer that these exchanges are causally related). In this scenario, the body of information for the conversation is fully described by the message content exchanged between participants. For example, the state of the conversational information could be derived by simply looking at a log of the messages that were exchanged between participants. One way to think of this perspective is as messages acting as nouns, and service operations acting as verbs; messages are the embodied state of the conversation, and operations act upon this state to change it in some fashion.
- As describing the presence of context which provides additional information or semantics that is logically part of the body of information shared between the conversation participants. The information contained within messages themselves, then, are only part of the full set of information important to the combined function of the conversation participants. In this view, the full state of the conversational information is the state of the context of each participant. In this perspective, contextual information act as direct objects, and messages act as verbs to effect changes in that information. Each particpant retains a set of information relevant to that conversation.
State Implications of Conversation
Because the conversational state in perspective (1) is wholly described by the messages exchanged between participants, service implementations can be stateless. The necessary conversational state is reconstituted per request by a service implementation based solely on message content, and any particular service implementation's cache of this state is destroyed when a particular request has been satisified (for, example, by sending another message or by consuming the information in the message in some fashion).
Perspective (2), however, implies statefulness on the part of individual participants. Conversational state is the union of all contextual state from each particpant, and this state is inherently distributed.
Perspective (1) is a familiar paradigm from the Web application domain (actually, the Web application domain has versions of both (1) and (2)). For scalability, Web application servers may remain stateless and rely on a client to return any relevant state to the server during a subsequent request. In the Sun Java Studio Web Application Framework (a k a JATO), this capability exists as the page session and client session features. In JavaServer Faces, this capability exists as the client-state saving setting for an application.
However, Web applications also have the ability to maintain server-side session state (perspective (2) above). The server and client use a correlation strategy to associate a particular set of server side state with a particular client request. In Java servlet terms, this manifests as a jsessionid cookie being passed between client and server as part of a requests or response. The predominant Web application correlation strategy is based on an arbitrary, protocol-level key assigned by the server.
Although it is possible to define conversation in terms of perspective (1), perspective (2) appears to be the predominant assumption behind conversation in the BPEL domain (from which the formalism of conversation arose). The BPEL spec talks about process instances and correlation of messages to these instances. In various implementations (Collaxa, BEA Workshop), conversational state is typically either embodied as a "working set" of data used for a particular request (Collaxa), or embodied as a stateful object instance on the server to which messages correlating to that instance are routed (BEA Workshop). These approaches are equivalent—in both cases, a particular conversational context is present during the processing of a message which is determined to be part of that conversation; whether that state persists as a live object instance or a dehydrated set of data is an implementation detail.
Based on the way BPEL spec writers and various BPEL/service runtimes approach conversation, I assert that if there is no contextual state, there is no need for conversation as narrowly defined in the Web services domain.
Correlation Strategies
Correlation refers to the technique of assigning a particular message to a conversation. In implementation terms, it refers to the mechanism by which a particular message is assigned to a stateful process or service instance (or in other words, a context) for handling. Correlation is directly related to conversation; it is the mechanism by which conversation is tracked.
There are many possible correlation strategies. Here are a few being used today:
- WS-Addressing: provides the ability to pass endpoint references as well as "thread" information, i.e. which message a reply message is in response to.
- WS-Conversation: BEA's proposed spec for handling conversation using simple callback addresses and arbitrary conversation IDs. (WS-Conversation is implemented in WebLogic Workshop 8.x.)
- Content-based: uses business protocol information to associate conversational state with messages.
Different correlation strategies have an effect on the ability to support bilateral or multilateral conversations (see section below). For example, content-based correlation appears to be the only correlation strategy to naturally support multilateral conversations, because the correlation information is potentially shared between all participants. By contrast, WS-Conversation requires the use of a conversation ID, which cannot easily be made known to more than two particpants (the originator and the recipient).
Types of Conversation
There are two distinct types of Web service conversations: bilateral and multilateral.
Bilateral conversations take place between only two participants. A particular particpant may be involved in more than one bilateral conversation simultaneously, but these conversations are distinct. That is, service A can simultaneously participate in bilateral conversations with service B and with service C, but the A-B and A-C conversations are distinct. The only common element is service A as a participant in both conversations; thus, B and C are not part of the same conversation. It is perhaps natural to consider these distinct conversations as part of a single, logical, overarching interaction, particularly if they are causally related. That is, from an omniscient view, we may consider these to be part of a single "conversation" in the broadest sense, but this usage of the term does not fit the narrower Web services defintion of conversation.
In a multilateral conversation, more than two participants may be involved in a single conversation. Using the example above, A, B, and C would all be participating in a single conversation, and B and C would be considered part of the same conversation. This type of conversation could be considered conversation in the broad sense, in that it corresponds to the omniscient perception of conversation. However, it is more rigorous than merely perception, in that a multilateral conversation implies some shared state between all participants, and some shared information used to correlate messages to the conversation.
In fact, this latter point is the main differentiator between bilateral and multilateral conversation. In a bilateral conversation, information used to correlate messages to the conversation is not shared by all participants and is limited to just two participants. In a multilateral conversation, more than two participants may share the same correlation information. The distinction between bilateral and multilateral conversations is important when talking about conversational state and correlation strategies at runtime.
Before I forget, there is a potential pitfall when using multilateral conversation with component-based Web service runtimes or frameworks. Specifically, these runtime architectures allow multiple Web service client components pointing to the same target service to be added to a single parent service. This causes a problem when the target service has a callback—the callback must be correlated to a particular component instance in order for it to take action in response to the callback. There seems to be no clear way to perform this correlation without using bilateral conversation, in which each invocation of the target service can occur within a different conversation. Within a multilateral conversation, there would be no way to differentiate callbacks meant for separate components. Therefore, multilateral conversations (and thus content-based correlation) may be incompatible with multiple service client component instances. The question is open as to whether an IDE or toolset could restrict the number of component instances if content-based correlation is being used, or if this limitation simply means that content-based correlation could not be used at all.
--
Posted at 10:31PM Nov 03, 2004
by Todd Fast in Web |
Tags: /
Like this post?
| |
|
|
Dispelling NIO myths
An interesting article on the JDK's NIO features and the EmberIO library.
--
Posted at 10:05PM Nov 03, 2004
by Todd Fast in Software |
Tags: /
Like this post?
| |
|
|
Cross-connected neurons - biology and programming langauges
After doing some reading about genetics and taxonomic systems in biology, it struck me how similar principals were at work in programming language design. Specifically, object-oriented languages that include classical inheritance tend to take a phylogenetic approach to structuring software systems. That is, they classify software structures in terms of their inheritance, or "is-a" relationships.
Some languages, however, also include a morphogenetic component in their design. That is, they allow classification of software structures in terms of their "shape" or how they "look". A better way to say this might be to classify objects according to their interfaces, or supported operations. The actual inheritance of an object (or phylogeny) is of less importance than the way it "looks" (or morphology) to users of the object.
Java is an example of a language that supports both phylogenetic and morphogenetic classification, primarily through its use of interfaces that can be used to make an object "look" like a particular type without actually inheriting from a particular parent type. (Admittedly, this analogy isn't perfect, since there is still an "is-a" relationship even when using interfaces. However, with the exception of tag interfaces, the primary use for an interface in Java is to specify the set of operations a class defines.) ECMAScript, however, with its prototype-based design, is fully morphogenetic. The only thing that makes an ECMAScript object classifiable is its set of members. (Here is a nice article on ECMAScript's morphogenetic features.)
--
Posted at 09:55PM Nov 03, 2004
by Todd Fast in Software |
Tags: /
Like this post?
| |
|
|
Do I really have to post this?
Hopefully this is preaching to the choir, but here is a nice Allen Hollub article advocating interface-based programming. It's notable for its nice summation of points.
--
Posted at 09:49PM Nov 03, 2004
by Todd Fast in Software |
Tags: /
Like this post?
| |
|
|