Aehso’s Output

Producing Open Source Software: How to Run a Successful Free Software Project

Karl Fogel has released his book Producing Open Source Software: How to Run a Successful Free Software Project (Karl is the guy behind Subversion at CollabNet by the way). Of course he can’t write a book about free software and not give the book away for free so there are links to free PDF/HTML copies of the book on the page above .

Most chapters in the book are equally relevant to running a commercial engineering group that produces commercial software so don’t let the OSS tag scare you off. All software engineers could learn more than a thing or two by studying how mature OSS projects are/should be run.

Dave Chappell’s Opinari #14: The Case Against BPEL

There seems to be a bit of a fuss about BPEL in the past week that seem to be derived from Dave Chappell’s piece The Case Against BPEL: Why the Language is Less Important Than You Think

I agree with most of Dave’s assesment of BPEL but in several instances he argues that BPEL is deficient in some manner because he wants it to do things that a process definition language has no business doing. Rightly enough he starts off by defining the language’s goal:

the language’s goal is to provide “a notation for specifying business process behavior based on web services. (empasis mine)

The following limitations apparently make BPEL “Not Useful”, when defining executable business processes:

…local objects will most likely be written in Java or a .NET language, such as C#, and so the BPEL process will need some way to access them. The BPEL spec doesn’t define a standard way to do this.

I refer back to the based on web services part of the languages goal. The BPEL approach is to externalize complex logic like this, put it behind a WSDL interface (that is implemented using C# or Java) and treat is as a partner of the process. This is a Good Thing as it forces designers to isolate platform dependencies behind standard business level APIs (WSDL).

…Yet much software today doesn’t support web services, a situation for which BPEL provides no standard solution.

He’s right, there is no magic bullet. Anywhere, in any language. BPEL is based on the premise that all partners to the process expose WSDL interfaces. Even suggesting that a language specification could produce an alternative “standard solution” to solve this open-ended problem domain is a bit harsh.

…the language doesn’t define a standard way to access relational data or other non-XML information.

Again, integrations with datastores should be implemented by partner web services, isolating the business process definition from the low level details of how data is persisted. This is a common service-oriented approach that is to be found in many Web Service based architecture.

…it doesn’t define mechanisms focused on interacting with people.

Again we’re talking integration with a backend messaging systems (HTTP servers, SMTP, SMS etc) . This type of asynchronous notification/event services can easily be provided by a partner web service (implemented in whatever language, integrating with whatever systems). The point is, this doesn’t belong in a Business Process Language - it should be externalized from the process definition and therefore doesn’t belong in a process definition language specification. A followup piece on ZDnet’s SOA blog clearly illustrates how this has been done in the field. I can add that I followed the exact same approach a couple of months ago while developing a BPEL based supply-chain solution for a customer.

So after listing the above, Dave does state that “it’s not correct to criticize their absence”. However, he does follow up with the following statement:

[...] it means that implementing a complete process in BPEL generally requires using roduct-specific extensions.

Product specific extensions are not “generally required” - just because they are there doesn’t mean they have to be used. That’d be a pretty large shortcoming in the BPEL spec if that was the case. The spec design is such that everything that BPEL cannot do ‘natively’ by the defined activity set should be extracted to a partner web service, thereby maintaining portability. Of course I say “should” - some of the product-specific extensions (like BPEL-J) make this unecessary but they do so at the cost of breaking portability, as Dave noted. I agree that this is a bad thing but proprietary extensions are a fact of life and in BPEL’s case, they can be avoided.

I should point out that I don’t, by a long shot, think that BPEL 1.1 is the finished, polished specification - clearly they wouldn’t still be working on 2.0 if it was.

Structure 101

I got a note from a old colleague at Headway Software - they’ve got their new Structure101 tool out on beta and it’s looking very good. Identifying excess structural dependencies in code is nigh on impossible without top down analysis tools like this and any tool that can identify “fat” and “tangled” code gets my vote. Anyone interested in modular java programming should check it out - they’ve put some 2-minute web demos if you want the quick intro.

Eclipse OSGI core CLI

With the release Eclipse 3.0, the Eclipse platform migrated the core runtime onto a new OSGI R3 implementation as the basis for its whole plugin framework. The OSGI implementation provides all the low level bootstrapping, plugin classpath management, dependency resolution, APIs exposure control and and whole host of other (currently underutilized) facilities. Eclipse users havn’t noticed the change since it’s all under the hood but Eclipse plugin developers have noticed as the plugin framework is now a little more powerful and metadata can now migrate from the trusty plugin.xml descriptor into an archive’s MANIFEST.MF file, as prescribed by the OSGI specification.

Recently, the OSGI implementation has been promoted to a sub-project of the Platform project and is now publically known as the Equinox project. Effectively they have seperated the OSGI implementation from the rest of the Eclipse platform and now distribute the OSGI framework as one 700k jar. That’s a lot of very useful framework packaged into a very small archive. What got me more interested is that they added a command line interface onto their OSGI framework. Launching it is as simple as:

C:\eclipse\plugins>java -jar org.eclipse.osgi_3.1.0.jar -console

That gives you a little ‘osgi’ prompt:

osgi>

Here’s a hint - enter ‘?’ for help - I’ll not paste it all in here but suffice to say that you can do a lot from that little prompt. There’s lots more at the Equinox quickstart page.

Now here’s where it gets interesting. Java has needed something like this for a very long time and the Java Community Process are starting work on a Java Module System(JSR 277) specification. The initial description of that JSR pointed out that OSGI R3 had some limitations that rendered it unsuitable for consideration. But now Eclipse now supports OSGI R4 - I wonder does it resolve those issues?

I expect to see OSGI play a larger and larger role in Java library/application packaging and distribution in the future. However, OSGI really only provides benifits if the packaged code is modular and easily pluggable. Monolithic messes that cannot be decomposed into multiple bundles will not gain as much benifit.

Free VMWare Player

Interesting concept - VMWare have released a free lightweight (28Mb) distribution of their virtual machine engine that just plays pre-built OS distributions. Nice way for vendors to distribute demos/trials of their software, and I’m sure big shops will use it internally to run old machine images.

I must give it a spin at the weekend, their browser appliance virtual machine is probably worth a look for the hell of it. From what I gather it contains a stripped down Ubuntu Linux withFirefox, GAIM, BitTorrent, and a Terminal Server Client.

Eight Fallacies of Distributed Computing

Via Ted Neward’s excellent disassembley of Floyd Marinescu’s A Brief History of EJB, I stumbled across Peter Deutsch’s old Eight Fallacies of Distributed Computing. Back in the day in Iona, being caught in possession of a list like that would probably have gotten me fired (kidding), but I do remember reading it and thinking “uh oh, we may be missing something here”. Developers building any type of SOA/ESB SOAP/REST based server, tools or solution would still do well to print it out and put it somewhere prominent.

Funnly, it’s almost like Sun are trying to hide the list since the common link returned by Google is broken.

Box, Vinoski and JBI.

An interesting conversion going on between Don Box and Steve Vinoski, started by Don’s comments/questions related to Steve’s recent IEEE Internet Computing article. They are definately ‘talking across’ one another (as Don puts it) and I think the reason is Don hasn’t really grasped the purpose of the JBI spec. Don states:

I do have a hard time seeing how the Java developer community is served by yet another programming/management/deployment model for writing hosted code.

JBI does not serve, and was never intended to serve, the general Java developer community, nor is it designed to provide a programming/management/deployment model for writing hosted code - it is for writing hosting code. I’m wondering if Don has read the specfication correctly? (Update: it would seem he hasn’t) The Target Audience section of the spec, in the Introduction section of the spec makes this abundantly clear:

The primary audience for this specification is system level software engineers who will develop the following:

• implementations of the JBI infrastructure itself
• the components that provide communications protocol support,business logic, transformation engines, intelligent message routing etc.

This specification is not appropriate for application developers or business analysts. It is hoped that this specification will facilitate the development of standard service composition tools and services targeted specifically at this group.

On an slightly unrelated note, Steve comments in one of his blog entries:

My take is that containers aren’t as special as we’d like to think they are. A container really just supports a particular programming model or style.

I’m a little surprised at this comment - surely anything that enforces a particular programming model or style is an important consideration?!?!

iTunes RSS extensions and XML parser getting more flak.

Oh dear, it sounds like the really rushed it out - read here and here.

John Reynolds on charging for Java EE App Servers.

It may seem like stating the obvious (to the converted) but, well, he just put it so well. The interesting question is, with everyone giving their tools away for free these days in a bid to lock customers onto their server platform, what happens when you can’t charge for the platform?

MS admit XP is too much to handle.

From Scripting News, Vic Gundotra, Microsoft’s General Manager of the Developer Platform & Evangelism Group, openly admits that when it comes to Windows XP

The costs associated with viruses, malware, and other malicious hacker inspired code is just to much to handle…

Or maybe I should have titled this post “Why Marketing Directors shouldn’t blog”?