Alpine Design Goals

As Steve Loughran has written, I’m becoming involved in his and Edmund Smith’s effort to create Alpine, an XML-centric SOAP stack. Currently, there is no infrastructure such as a Wiki or mailing in place yet. But since Alpine is intended to be a very open project, I will simply outline some of my own ideas here. As this is my blog, not an official project site of any sort, what I write here is intended as input to a discussion.

If you haven’t done so already, you should read the excellent paper that officially started this thing (although Steve sent me a very early Alpine doc back in September). If you’ve read my criticism of RPC-style Web services recently, or if you search my blog for serialization or older posts like this, or even this older discussion with Ted Neward, you won’t be surprised that I agree with most of it.

One part of the paper outlines a set of design goals for Alpine:

1. Stay in the XML space as much as possible.
2. Take advantage of as much leading edge infrastructure as we can.
3. Adopt the the handler chain pattern of Axis/JAX-RPC.
4. Target SOAP 1.2 (POST only, WS-I Basic Profile 1.1)
5. Document/literal mssages only, not RPC/encoded.
6. Support XSD and Relax NG schemas.
7. Run server-side, client-side, and as an intermediary.
8. No support for JAX-RPC or JAX-M/SAAJ APIs.
9. Configurable procedurally, through the Java Manage- ment API (JMX).
10. Permit dynamic handler chain configuration during mes- sage processing.
11. One supported parser.
12. Run on Java 1.5 and later.
13. No provision of side features such as a built in HTTP server, or a declarative configuration mechanism. These are delegated to other products.

I’ll review some of these in turn and try to provide some elaboration and personal opinion.

Stay in the XML space as much as possible

This is the number 1 design goal, as it is the major difference between Alpine and other, JAX-RPC based stacks. (In the elaborate words of Chris Ferris: SquarePeg RoundHole.) It’s also what I find the most attractive aspect about the whole idea. Preliminary discussions involved Elliotte Rusty Harold’s XOM as one of the possible XML APIs. As far as I can tell, XOM would be a good choice. I’m unsure about whether a pull parsing, push parsing (like SAX) or tree-based API, or all or only two of them, is the most pragmatic choice. It’s obviously not easy to switch from one to the other later on, so this needs to be decided early on.

Take advantage of as much leading edge infrastructure as we can

Not much comment here, except that I would like the project to avoid adding a gazillion JARs as a dependency.

Adopt the the handler chain pattern of Axis/JAX-RPC

The handler chain pattern is a common design element in CORBA ORBs, JAX-RPC, as well as commercial implementations such as the one from Systinet, so I’ll take this as a natural approach. One interesting are is to find out how similar the processing model of handlers or interceptors within the stack is to the processing model itself - i.e. whether the handling of a message by multiple processors can be local or distributed without a change to the programming model.

Target SOAP 1.2 (POST only, WS-I Basic Profile 1.1)

I think the SOAP 1.2 GET binding should definitely be supported — my only disagreement. If SOAP 1.1 is easy to add, I’d vote for doing it; I’m OK with primarly targeting 1.2, though. (WS-I BP 1.1 still relies on SOAP 1.1, BTW; WS-I profile compliance will obviously have to be postponed to one of the next versions.)

Document/literal mssages only, not RPC/encoded

RPC/encoded is a dead horse, so there’s no point in riding it. I believe the same is true about RPC/literal, still, WS-I BP compliance might require it.

Support XSD and Relax NG schemas

I think whether to validate and what schema language to use should be configurable. I see Schematron as a great additional candidate. I don’t see any need to make Alpine depend on WSDL or any other description format.

Run server-side, client-side, and as an intermediary

The ability to program intermediaries is in my view essential; it’s also a use case where the flexibility of having direct access to the SOAP message is required.

No support for JAX-RPC or JAX-M/SAAJ APIs

I don’t think support for JAXM or SAAJ as something that is necessarily bad. In my interpretation, it would be better to phrase this statement differently — support for JAXM or SAAJ is simply not a design goal.