> Anne wrote: > 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. > ... > Java developers seem to really want > to expose Java collection types through their Java interfaces, which > causes interop issues.
I've asked the same question as you, and fully agree that there are tools that can make this easier. This leaves us with one of two scenarios, then: 1) The developer has used a tool to create XSD and/or WSDL. Now they need to bridge this file (from which no code currently exists) with their code. 2) The developer simply doesn't want to deal with XSD or WSDL at all and just wants to stay in their Java / C# / whatever code. In both scenarios, something that is going to be required is something that goes from platform-specific collection classes to something this is more interoperable. The developers in case #2 aren't going to find life any easier in trying to map these collections to REST, as the container and all of its elements should have a URI associated with them. While I've never done it myself, I suspect that doing this correctly could involve a significant amount of code, or at least a fundamentally different approach to the implementation than they may have today. It would be great if the frameworks provided a way to map a collection to a "web of resources" each with their own URI. So, somewhere along the line, we wind up needing some form of tooling that goes from the platform-specific world of the developer's preferred language to the interoperable interchange world we need for distributed computing. The tooling around WSDL and XSD hasn't made the "right" thing the path of least resistance (such as exposing Java collections or a .NET DataSet), and people look for something easier. I think a truly RESTful approach is going to require the same thing. Otherwise, the least path of resistance will continue to be just a base use of HTTP with whatever the developer chose to expose it, most likely being neither REST nor WS-*. -tb
