On 12/12/06, Alexander Johannesen <[EMAIL PROTECTED]> wrote: > > > > > > > On 12/12/06, Steve Jones <[EMAIL PROTECTED]> wrote: > > Very easy? If I've got the WSDL then I can have a test client > > _running_ in a minute or less. > > What's your definition of "running"?
Deployed and able to call the Web Service with a set of pages that help me test. > Just because you *fetch* the API > doesn't mean you can use it with understanding straight away; there's > no limitation on the API level to what you can do, nor is there > semantics that are standardized, so how does the WSDL explain to you > their business rules? No it doesn't (hence the reason I want WS-Contract) but it does say to me what the capabilities are (the methods) and it does say what data types they accept and it does tell me what they will return. If I have something that says (in my nice IDE generated proxy) Quote requestForQuote(Order) and its on a Service called "OrderManagement" I can (as a human) make a pretty smart guess that if I send in an Order I will get back a quote for the price of the order. > What I'm saying here is that there is no > automatic connection between the client and server; there's always a > developer, with or without sexy tools, that connects up core business > pipelines. Agreed, but with a nice WSDL you are starting from a position where the analyst & architect can also understand the service they are consuming (just generate a UML component off the WSDL). The question is ease of use and economoics How much will I need to pay a developer to "right click" and consumer the WSDL and then code straight Java. How much will I need to pay a developer to manually create the XML documents and understand PUT/GET/POST semantics and to create a dynamically adaptable system that works with REST. There is always work to connect A and B, but connecting A and B adds no value in itself (it is A calling B that gives the value) so a smart choice would be to pick the cheapest way to achieve it. > > > The "three layers deep" bit is what is confusing me, as is the > > "someone's" which sort of implys that its owned by an independent > > third party. Could you clarify? > > Just another rhetorical, really; an encrypted message on a service > that sits within a service that sits within the service, which is > especially true in secure stacks that don't want the endpoint to be > published anywhere. Most often you use the API to get to the next > service in the chain, although of course not all stacks are defined > this way. In the REST world the URL is the endpoint published on > demand (which means never officially published anywhere), and the > backend focuses around that instead of the stack. Just my clumsy way > of talking about where the focus sits in the two different > technologies. But as far as I can tell, you don't like the non-static > nature of REST. I still don't have a clue what you are talking about, a real world example would help. On the non-static nature, I just need to understand the cost of having this dynamism and then to work out when that cost is worth it. > > Alex > -- > "Ultimately, all things are known because you want to believe you know." > - Frank Herbert > __ http://shelter.nu/ __________________________________________________ >
