I think the major issue at hand is that organizations expect developers to write schemas. Schemas should be developed by data experts who understand data modeling, and understand XSD and namespaces. Organizations should define standard corporate schemas, and developers should be advised to use the corporate standards. They should also be advised not to generate schemas from their application code.
Think about it -- how many developers are responsible for defining database schemas? If you left it to developers, they would generate database schemas from their code using O/R mapping tools. If you expect people to share services -- or to enable composite service development-- you have to start at the data type level. You must have standard corporate data types that represent, e.g., "customer" in customer service applications. Most WS-* frameworks provide tools that generate code from WSDL (e.g., wsdl.exe and wsdl2java). There are also plenty of O/X binding frameworks in the Java world (e.g., JAXB, XMLBeans, JiBX, Castor). These tools can isolate the developer from having to deal directly with XML. There is an impedance mismatch between XSD and objects, but as long as you recognize it and deal with it, it's no worse than the impedance mismatch between object and relational. The problem is that developers don't want to deal with the impedance mismatch -- they assume that SOAP is just like RMI, and they get annoyed when it doesn't work seamlessly. They just need a little education. The bigger challenge is mapping method-oriented objects to RESTful resources. Todd suggested a tool that maps a collection to a set of resources, but I don't think it's quite that simple. Most objects expose object-specific interfaces. If they only expose getters and setters, then it's fairly trivial to do automatic mappings. But how do you automatically map object-specific methods to GET, PUT, POST, and DELETE? Anne On 6/8/07, Michael Poulin <[EMAIL PROTECTED]> wrote:
I think that people "who are simply doing XML (maybe only on the response side) + HTTP instead of WS-*" are NOT doing Services; it is simple XML-based RPC over HTTP. So, the value of Services yet to be discovered for them. As of WSDL, I totally agree with Todd; I do not understand why its creation is not well automated. I saw a few clumsy "wizards" for WSDL however. XML Schema writing is also semi-automated by, e.g. Altova. The problem, nonetheless, is in how to manipulate namespaces and schemas in the WSDL. This issue looks like a 'rocket science' for many developers and requires very strong guidelines and governance. For example, how one can modify data in doc/literal WS style with backward compatibility for those users who do not care about the change (i.e. the WS has to provide the same namespace as before and offer a schema change)? Well, I am not looking for the answer to the example question but rather curious how many people would consider such task as a challenge for an average WS developer. - Michael *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. 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. 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 ------------------------------ Choose the right car based on your needs. Check out Yahoo! Autos new Car Finder tool.<http://us.rd.yahoo.com/evt=48518/*http://autos.yahoo.com/carfinder/;_ylc=X3oDMTE3NWsyMDd2BF9TAzk3MTA3MDc2BHNlYwNtYWlsdGFncwRzbGsDY2FyLWZpbmRlcg--+>
