"Anderson Jonathan" <[EMAIL PROTECTED]> wrote:
Time for my two cents. We've been using Axis 1.2 alpha builds since November '03 to build WS-I compliant document literal web services. How is this possible? Here's our cookbook:
This is a terrific message, thank you! I think this would be a great thing to enshrine on the Wiki; is there any convention for doing that?
+1! Very succinct and to my mind accurately conveys the "recommended approach" these days.
I'm slowly understanding the shift that WS-I and document/literal imply. But I'm left wondering a philosophical point; what value is SOAP really offering? Why not dispense with Axis entirely and just go straight to the DOM when implementing a web service?
Processing XML directly is a strength. :-)
SOAP is no longer the technology it was 2001 where Section 5 described wire encoding options and a type system. Now its a framing protocol and processing model. What that means to me is that SOAP is the soap:Envelope/soap:Header/soap:Body tags that allow service designers to put application stuff in one bucket (soap:Body) and keep that separate from non-functional stuff that goes in Headers.
This provides the possibility of a layered architecture with commodity features available from 3rd parties. Imagine no standard framing protocol. The following would be baked into the application layer message:
1. Security, credentials, signing and encryption info 2. Message Correlation 3. Reliable messaging info 4. Transaction causality 5. Diagnostics and logging headers 6. Routing information 7. Plenty more
And it would be baked in a 1000 different ways. If you believe the point of XML Web Services in Interop than what have we gained if all endpoints need to have your entire application stack as you defined it installed.
The great thing about the SOAP-as-RPC view is that, when it works, it makes client programming really simple. The caveat is "when it works", since the naive implementations induce a lot of coupling that make future system evolution and composition difficult.
True - I think thats why it was so popular out of the gate. It was only when folks quickly started reaching the limits of RPC SOAP that doc/lit really started to gain momentum.
This seems to be the central quesiton of web services design. I know a lot of people are thinking about it and it's driving a lot of technology development. It's latent in the WS-I spec. But I haven't seen so much clear writing about WS interface design directly.
Halleluah! I'm just starting to blog about that! IMHO, Web Service Message design has been an afterthought of the spec working groups that comprise your typical WS stack. You need to know a lot of grunge to design an easy to consume service:
1. XSD - what to use and what to avoid is the hard part especially when modeling non trivial data. What will axis do with a .NET DataSet, or collections or...
2. WSDL - WSDL 1.1 is chaos. Hopefully WSDL 2.0 will improve that but it looks m ore complex not less to me though several problem have been addressed. There is the question of migration from WSDL 1.1 to WSDL 2.0 as well. Not exactly straight forward.
3. Various language bindings. What will you interface be like to code against in the foo language?
Jim Murphy Mindreef, Inc.
