Lots of interesting reactions to the Alpine proposal.

Don finds it interesting, and he is The Man when it comes to SOAP.

Some people think we are too harsh, and that a pure XML-model will be less useful.

I certainly think it will be less easy to get started, at least for the XML-ignorant, less easier to turn an existing object into a SOAP endpoint. But what if you know XML, what if you know how to write XSD+WSDL, and want your incoming messages queued for processing via Xpath operations? What if you want your endpoint to be able to handle dynamic messages where only a bit of schema is laid down in advance. Right now, you are out of luck. For those people, Alpine is what they need.

The other thing to bear in mind is the economics of open source projects. The Microsoft teams: Indigo, XML, etc, make their money by selling more copies of a system than it costs to make. The more users for the same amount of engineering effort, the more profit. In that business model, ease of use is absolutely critical. The barrier to entry should be low, both techically and in purchase cost. In this world, support costs are an expense, new versions have to be fantastic enough to justify an upgrade, and you can afford to throw some engineers at exceedingly hard problems. Hey, you can even afford people to write decent documentation.

Out in the world of Java SOAP, we have various choices.

1. Get a paid runtime off the app server vendor: Sun, IBM, BEA. All built on JAX-RPC, and we've just eliminated that off the sensible list.
2. Use Sun's RI of JAX-RPC. See above.
3. Cocoon, NetKernel. I need to do more of NK work.
4. Write it yourself

I've done some of #3, and although I'm probably about to get marked down as inactive in the Axis team, I watch the developer mail list to see how things are going. The one thing I don't go near is the axis user mail list. Why not? Because there are people there dealing with "connection refused" errors, or complaining that Axis throws an AxisFault with an HttpErrorCode numbered 404, please can someone help as they have a web service to finish that day, etc, etc. Or they have an EJB that they want to export as a Web Service because Corba is uncool, and are having problem with marshalling object references over the wire.

Far too many people in the Axis user mail list are not ready to be writing web services yet, not real ones, let alone ready to contribute to the Axis stack itself. Yet for an OSS project, active participation in that dev process is exactly what you need. You need a piece of software that end users are capable of enhancing, and you need end users capable and willing to do so.

Unlike the closed-source broadest-adoption-is-most-profitable strategy, all an OSS project needs is "meets the needs of a competent, combined user/developer group". The low barrier to entry should not be to start using the technology itself, it should be between being a user, and being an implementor.

I like to view JAX-RPC as the EJB of Web Services. EJB was designed to hide all the detail of persistence and distribution from those little developers, who didnt need to worry about such things. JAX-RPC was also designed to hide all the detail of serialization and distribution from those developers. Everyone knows that EJB is wrong, Ed and I are just pointing out that the emperor's clothes are equally sparse when it comes to XML messaging.

Java developers of the world unite! you have nothing to lose but interoperability grief!