The Breakfast Club

The Breakfast Club is an easy-to-watch movie about five teenagers in detention. It’s definitely a teen flick, and most of the more serious friendship-building scenes are clearly aimed squarely at this age bracket. Having said that, the (partly) slapstick comedy appealed to me, although I think it’s probably necessary to be in a mood for something a bit silly.

The only poorly drawn character in this film is Mr. Vernon, the school principal, who reacts inconsistently and is hard to follow. The students all fit into clear stereotypes at the start, but unsurprisingly move out of these molds as the film progresses. I was expecting good things of Emilio Estevez, and indeed he delivered, but Judd Nelson provides a standout performance as probably the hardest character to play: the rebel, who, despite some softening, stays a rebel to the end.

As is usual in Hollywood, the film is let down by the use of some adults to play high-school ‘children’ (Judd Nelson was 25 during filming). The reality of the film suffers a little accordingly, although the quality of the acting goes some way towards negating this.

A good movie to watch when you’re looking for something short and not too intense - plus this gives you the dubious honour of being able to say you’ve seen **the **definitive 80s teen movie.

What is WebSphere Integration Developer?

WebSphere Integration Developer (WID) is IBM’s development tool for constructing SCA modules that can be deployed to WebSphere ESB and WebSphere Process Server. It is built on top of Rational Application Developer (RAD), which is in turn Eclipse-based, so it inherits a lot of functionality, including support for Java, J2EE, UML, etc. However, it also provides the ability to develop:

  • ESB SCA-based mediation modules, which can contain ESB mediation flows (and Java components).

  • Process Server SCA-based modules, which can contain Process Server SCA components such as business processes (using BPEL), human tasks, business state machines, business rules, and selectors.

(see this posting for more information on SCA modules and components)

WID, like RAD, is Eclipse-based, and provides the same flexible, customizable development environment. For example, one can customize the Eclipse Capabilities provided by WID so that the Process Server and/or ESB development functionality is hidden (once loaded, go to Window / Preferences / Workbench / Capabilities / Integration Developer / *). This is useful if you know you want to target a particular type of server.

Although WID is often used with WebSphere ESB or Process Server, it is not supplied in the box with them and must be obtained separately. However, it does contain a version of Process Server that can be used for testing modules before deployment - commonly referred to as the Integrated Test Environment (ITE) or Unit Test Environment (UTE). During installation of WID, you can create an ESB or Process Server profile against this for testing with (or both). This is possible because Process Server contains a superset of the functionality of ESB. See this Developerworks article for more information on testing this way, as well as some more information on WID.

Mediation the Third

After my previous post about mediation in ESB, I should add that there is a third way to modify messages on the bus, that doesn’t go by the name of ‘mediation’: using a JAX-RPC handler. It’s only suitable for SOAP messages (which can be transported over HTTP or JMS), but is otherwise most similar to Platform Messaging mediations. The primary advantage of JAX-RPC handlers is that they are conformant to a JSR specification, but they aren’t able to do a number of things that mediations can, such as modify the target of a SOAP request.

You can find more information in this article on Developerworks.

Correction: SCA Default Binding

In a previous post describing SCA in WebSphere ESB / Process Server, I wrote that SCA modules have to be running in the same address space. I’d like to correct this: the restriction actually imposed on these bindings is that they need to be between SCA modules running in the same WebSphere cell (see this post for more information on cells, nodes, and servers). This is because the SCA resources that are automatically created when an SCA module is deployed are cell-scoped. Different types of SCA resources are created depending on whether asynchronous or synchronous behaviour is required, which is normally decided automatically, but in both cases the scope is the same. For more information, see this Developerworks article.

It’s worth adding that there also two other types of bindings that I didn’t cover before:

  • Enterprise Information Systems (EIS) - Integration with WebSphere JCA adapters.

  • Stateless session bean - Integration with stateless session beans.

I plan to cover these more in later posts.

Software Change Management Should Change

Almost all software, whether it be public domain, open-source, or commercial, is not just released once. Typically it goes through many versions, changing (and hopefully improving) each time, sometimes adding features, sometimes removing bugs or problems, sometimes introducing new ones. This change is normally managed (at least for larger software systems) using two or three elements:

  • Version control systems (also called source control or library systems). These are typically used to keep track of different versions of source-code, enabling previous versions to be retrieved, different parts of the software to be merged together, and so on. CVS is a well-known open source example.

  • Bug tracking systems (bugs are sometimes called defects). These are used to keep a list of all the outstanding bugs and details about them. Bugzilla is a well-known open-source example.

  • Feature or requirement tracking systems. These are used to track new features that need to be added to the software (wherever they may come from).

In some cases, these systems may be integrated, in other cases not (integrated systems are normally more useful: for example, you can easily ask the question: ‘when this bug was fixed, what code changed?’).

Currently, commercial software companies often follow something akin to a waterfall model and treat features as long-term work items and bugs as short-term (as an aside, the original inventor of the waterfall model didn’t believe in its effectiveness). This is a risky game to play if your competitor can implement new features before your model allows you to. It’s likely that as commercial software becomes under increasing pressure from open-source competitors, often using nimble development methods such as agile programming, commerical software production companies will need to turn around production of new versions with new features faster than before to survive.

One of the mismatches occurs in treating bugs and features independently. Bugs take time to fix. Features take time to implement. In a sense, both are actually customer requirements, even if the customer hasn’t asked for them. Bugs customers won’t notice shouldn’t be fixed, and bugs they will notice will become a requirement even if they haven’t noticed them yet. Features either the customer has asked for or you think they may want should be implemented. Features that only you want are a waste of time. Bugs that your customer thinks are bugs normally are, even if you want to call them a feature.

So this leads to my conclusion (and not everyone agrees): bugs and features are actually the same type of thing. They are both customer requirements and should be managed the same way, triaged the same way, and developer time assigned to them in the same way.

Many open-source projects already treat features and bugs like this. Firefox’s Bugzilla, for example (in common with most Bugzilla installations), tracks features with a severity of ‘enhancement’. This probably isn’t ideal; features shouldn’t be treated as second-class citizens compared to bugs. But it’s a step in the right direction. This way, developers of Firefox see bugs and features as being of the same kin; lack of features cause some customers just as much pain as lack of bugfixes.

This issue is far from settled, and there are strong opinions out there that disagree with me. But it is clear that everyone involved in software development should be aware that this is not a solved problem.

subscribe via RSS