Excellent questions, Todd. On 6/8/07, Todd Biske <[EMAIL PROTECTED]> wrote: > > I'd like to start a separate thread on what the real problems of WS-* > are from a developers perspective that continue to fuel the fire on > these debates. That is, rather than continue to say whether REST is > better than WS-* or not, lets talk about why there is a level of > frustration with WS-*. I think Ashraf Galal's comments on the goals > of WS-* with respect to A2A versus the goals of WOA captured things > quite well. > > From what I've seen in working with a variety of developers, it > seems that things fall apart because of the strong movement toward a > WSDL-first, or even XSD-first approach. Erik Johnson made a similar > comment on Stefan's blog. Building WSDL and XSD by hand is something > that developers loathe. It's not easy to do, and many of them > question the ultimate value in it.
So why don't they use a reasonable set of tools to help them design them? I don't think anyone seriously expects anyone to design a BPEL script by hand. The obvious way to produce a BPEL script is to use a modeling tool. The same is true of WSDL and XSD. You should define an XSD using a visual data modeling tool, and once you've defined the input and output message structures, it's trivial to map them into a WSDL file. Try one of these tools: - Altova XMLSpy - Progress StylusStudio - oXygen XML Editor - Eclipse WSDL Editor > Odds are that they will still > need to create a human-readable user's guide anyway, and many wonder > whether that is sufficient. Add to this the fact that there is a > distinct level of distrust (which is unfounded in my opinion) on > anything that is generated. Some will argue that generated code > increases coupling, which I don't agree with. Generated code may > increase your dependency on the tools, but it doesn't necessarily > increase your coupling in your solutions. Compilers generate code. > Nobody complains about them anymore, so why are we so averse to using > generators in other areas? There's a natural maturity cycle with > these things, and always a potential to use them wrong, but tooling > is what makes things more efficient. I've yet to run into an > enterprise that wants to spend more time writing custom code. > > Coming back to the original premise, the theory goes that when you > simply add an annotation to your code that says "give me a WSDL > representation of this service" that you're now going to get > something where the interface is tightly coupled to the your > implementation. If the thing you annotated was already an interface, > rather than a concrete class, is this really the case? Yes, there is > greater risk that you may be exposing platform specific structures, > but it seems that a little education or even some automated testing > tools could easily capture this. This is the big issue, though -- Java developers seem to really want to expose Java collection types through their Java interfaces, which causes interop issues. > > As for the complexity of the WS-* stack, this is another argument > that doesn't hold a lot of water for me, mainly because I don't see > very many developers that have to deal with it. If the people > working in the standards bodies want to continue to come up with > standards for more fringe items that are of importance to smaller > communities, that's fine with me. If I don't need them, I can simply > ignore it. Someone else may need it, and they should pay attention. > It only becomes problematic if I have to worry about them when I have > no need for the capability. For example, if I don't need reliable > messaging, I don't have any extra work to explicitly state that I > don't need it. > > So, is the problem really just the complexity of using XSD and WSDL? > If it was far easier to do work with this, would life be easier? > Again, this is not directed at the REST crowd. This is directed > toward the people who are simply doing XML (maybe only on the > response side) + HTTP instead of WS-*. As previously stated by many > people, these developers aren't writing REST, although I'd bet a > majority of them think they are. > > -tb >
