Loosely Coupled

Things have been really hairy at work lately. I haven't had much chance to write. Here's what I've been up to. JCAPS One of my goals this year has been to make JCAPS more usable. A tall order indeed. I'm going to hit on the details of some of these items in later posts, but here's a bullet list of some of the issues I've been working through. My organization uses some non-standard x12 EDI messages. The way to get JCAPS to process these messages is by creating an OTD from an SEF file. I had no luck finding someone to help me create such a file and there are surprisingly few Java libraries that support these x12 messages. I wound up writing my own parser. It works pretty well and can be extended to support other message types. I've developed an approach that provides an automated way to test my JCAPS collaborations using JUnit. I'll describe this approach in future posts. The company I'm working for has a change control process th...

I downloaded some of the Air samples and the first thing it wants to do is install the application on my machine. I expected an Air application would be fairly lightweight (like a client-side Java application), and as long as I had the Air runtime on my machine the application would run - no administrative rights required. Not so. And too bad. Installing Eclipse is simply an unzip. There is no need to add entries to the registry or provide administrative rights. It's simple and that's the way it should be. I wonder why Adobe didn't follow this model?

I started this podcast project so I could learn some things I haven't had time to experiment with in my "real" job. Things like playing more with Ruby, trying out Behavior-Driven Development, and experimenting with Agile practices (plus I really wanted a better podcatcher program and I needed something to do over the winter). While I haven't produced much real code yet, I've created some simple prototypes and wanted to comment on some things I've been looking at. Reading an RSS feed My first prototype was a very simple Ruby program to read and parse an RSS feed. I had found some code here using the standard Ruby RSS Parser so that's where I started. At first I thought it was broken, but after about a minute and a half it returned. This wasn't going to cut it, so I started to look for alternatives and quickly found the feed-normalizer gem. Some quick coding and the total time to access the RSS feed was reduced to about 10 seconds. Not bad...

The JCAPS training I attended ( Foundations of Java CAPS II ) was excellent. We screamed through the course material in 3 days and had discussions on other JCAPS topics the other 2 days. Here were my impressions. I enjoyed learning about the eInsight Business Process Manager . The tools and steps involved in creating a business process are very similar to those used to create a JCD. There are a lot of interesting constructs like correlation and the "flow" element, which easily enable parallel processing. One frequent topic of discussion, was when to use an business process (eInsight) rather than a JCD. There's a certain flexibility to creating a business process, gained at the cost of speed. Since you can do virtually everything in a JCD that can be done by a business process, we questioned when each was a better fit. We didn't reach a consensus and I'm sure we'll be talking about this again. We explored the shortcomings of the repository and the be...

I've made embarrassingly little progress on my podcatcher so far. My plan was to entirely read Lean Software Development before getting started, but it's taking me a while to get through the book - in a good way. I seldom read more than 5 or 7 pages before I find myself reflecting on current or past projects. This knowledge could've saved me time on previous work by making the most important & well defined features a priority - delaying discussion and decisions on the "nice to have" features until later. Some of these ideas I've stumbled on by accident or heard about from others, but it's great to have them validated and expanded into this set of lean thinking tools. I'm sure this is a book I'll reread many times in the coming years. Anyway, I want to revisit my requirements list for the podcatcher, prioritize the features, and define the features for my first sprint. Here are the requirements for the podcatcher from a previous post, ro...

In recent SOA discussions with people at work, the topic of orchestration often comes up. The problem is, like Web 2.0 before it, the meaning of what an orchestration (or orchestration layer) is differs depending on who you're talking with. In my view, an orchestration simply refers to the process of integrating disparate applications. This idea is obviously not new. It's just a new name for an RPC or ESB-layer but relies on HTTP for communication instead of CORBA or something like JMS . This view is supported on Orchestration's Wikipedia entry which describes an orchestration as the process of coordinating an exchange of information through web service interactions. Speaking of the Enterprise Service Bus, it seems there is some confusion whether the "orchestration" lives at the same layer of the ESB or at a layer above the ESB and helps to coordinate ESB communications. I fall into the first camp, believing that "orchestration" is just a new ...

Again and again the topic comes up at work about fine vs. coarse grained web services. Is anyone else talking about this? I guess I don't understand what the big debate is about. I think of a fine grained service as implementing a very specific, atomic operation. Course grained services implement larger, multistep operations... possibly consuming other services. The way I look at it is this: a business has some piece of functionality it wants to make available for others to use (the service). It shouldn't matter if the steps performed by the service can be broken into smaller components. If no one can use these intermediate (finer-grained) components, the energy spent defining, building, and maintaining this (unused) functionality is wasted. My position is that it's better to wait. Should the need to reuse some of the functionality arise, then refactor the common functionality into a smaller, reusable service. Am I thinking about this wrong? What am I missing?