Bill Burke has released a corrected posting on the JBoss SOAP stack..

Now, instead of saying that the Axis team turned down the JBoss code contribution, he says that the code is in their CVS repository with the Apache license, we are free to take it up. Which we may do, though we need to know exactly what has changed and why. Nobody likes random people coming with a long term fork and saying "please integrate all these changes"; if someone from the JBoss team were to push for various features and explain how they benefit everyone, then patches go in. Everybody knows that you have to argue for patches into OSS code.

The timetable looks a bit like this then:

1. JBoss get access to the J2EE TCK, in exchange for lots of $$ to Sun.
2. JBoss need to get Axis to work with the TCK.
3. As the TCK is confidential code (Sun's fault, not JBoss's), only people with TCK access can find, fix and test the bugs, which means that the number of people can do so is pretty low. Essentially, only OSS projects that have TCK access can do it: Jonas, T-Max, Apache Geronimo and JBoss. That's all.
4. JBoss chose to fork the 1.1 branch to get their fixes in. This was their choice, and IMO, a long term mistake. Better to have put the effort in to become committers on the Axis project.
5. After the fork and J2EE certification, JBoss are left with a problem. Do they (a) get the stuff back into Axis, (b) maintain the branch forever, (c) come up with their own stack (potentially reusing bits of the existing code).
6. Option (a) needs effort. It would give the JBoss implementation access to all the many improvements to Axis1.2: SOAP1.2 support, better .NET interop, memory consumption improvement (!), performance boosting, much better Unicode handling, many many defect patches both client-side and server side.
7. Option (b) denies JBoss all the improvements in Axis1.2 unless they are pulled back in, retested, etc, etc. This is why even though the Apache license permits branching, it almost never makes economic sense. Once you fork, you opt out of collecting fixes and features from the primary branch.
8. Option (c) gives you the ability to start from scratch with a clean codebase, write something optimised for seamless EJB integration, etc, etc. It also means that you start from scratch with interop problems, from .NET jagged arrays to effective support of multi-gigabyte attachments (tip: don't buffer them to memory). This probably has the most engineering effort of all.

JBoss have chosen the third path, their own stack. This was not, as previously claimed, because the Axis team turned down their patches. How could we? We didn't even know what they have done. So why do it?

Tactical reason: you have a stack that is tightly coupled to your impl, manned by developers on your payroll, working to solve your problems on your timescale. As SOAP is (currently) very central to J2EE, it kind of makes sense.

Strategic reason. If you contrib to Axis, the beneficiaries are the other OSS J2EE stacks, Jonas, TMax and Geronimo, along with other vendors like Macromedia. Now, to come out and say that is your reason generates bad press, but if you were to say "we don't contrib to Axis as it benefits IBM", then maybe, just maybe, people might believe you and so you can justify your actions making you look the good OSS group, not the bad ones.

Strategic reason #2. If you do JBoss-only extensions, and apps use them, then the apps only work on your stack. You get lock in. We call this the "BEA J2EE extension strategy", for want of a better name :)

Personally I am disappointed. I think where JBoss went wrong was not in the decision they have just made, but back in the past when they forked Axis to get J2EE compliance. If they'd tried to work in the project then the current Axis release would meet their needs, and they would get the performance and interop improvements of the current release. Plus with no need to branch, we wouldn't have to bounce all Axis support calls from JBoss users over to the JBoss list. Given the current situation (fork of old Axis release; not kept up to date with Axis), high engineering costs, there is tactical and strategic benefit in the action.

I also think it is a mistake because there is much more to SOAP than the TCK. There is client side SOAP talking to Python servers. There is SOAP relay agents handling DIME-attached messages from .NET clients, forwarding them to Sun SOAP stacks that only hand Soap with Attachment Stacks. There is Grid Services, with the emergent WSRF corba-over-XML that I deal with in my daily grind (BTW, I now quite like the properties vs. methods model of this). Focusing on seamless server-side SOAP to EJB binding is only a subset of what SOAP can do. It is also the subset that preserves the SOAP-as-RMI-with-Angle-Brackets model of JAX-RPC which I currently think is wrong :)

Given that the net contributions of the JBoss team to Axis has been near zero, their adoption of a new stack is not going to directly hurt the project. It is only if the JBoss stack takes other engineering effort away from the group, or if JBoss SOAP gains more mindshare as 'the server-side stack' then Axis is threatened. But even then, we are only threatened in the area of SOAP to EJB binding, not client side, intermediary, or general interoperability.

What about end users? Well, if you use the JBoss fork of Axis, they have to be your first port of call with a problem. If they write their own stack, when it ships, they may be better at dealing with the issues. Until that stack is ready you are in trouble, as the current fork is code-frozen, and you can't switch directly to Axis1.2. If you use the Axis1.2 branch -on JBoss- then stay with that branch and all is well. It will work as it currently does, and you can host it on any other J2EE engine too. Of course, if you use the JBoss fork of Axis, and you want to switch back to Apache Axis, then you have an incentive to find those JBoss changes and get them reintegrated with Axis. If anyone wants to do that, and the changes are compatible with the current codebase (or can be adapted), then I am sure they will be accepted. We just need someone to put in the engineering effort.

I am going to close with the note that these are personal opinions, not official statements -as I presume, are Bill's. I don't want to create some illusion of yet-another-JBoss-versus-Apache spat to enlighten the TSS news pages on an otherwise dull day, because that isn't it. JBoss have chosen to exercise their rights, first to fork Axis, and then to write their own JAXRPC impl. If anyone deserves to be given a hard time here it is Sun for keeping the TCK tests secret, making it that much harder to build open source projects that pass the tests. Also I'd like to find whoever it was that wrote the Exception marshalling bit of JAXRPC, and ask them exactly what they were thinking.