Alexander Johannesen wrote: > On 12/12/06, Steve Jones <[EMAIL PROTECTED]> wrote: >> Alex, PLEASE go an read more on WS-*, most people aren't using it as >> RPC _between_ endpoints, but are providing an "object" style interface >> onto the invocation sides of the exchange, thus hiding the complexity >> from the developer. > > Glad you think I know so little of the WS-* stack. :) I use it every > day with a variety of systems, and seriously, RPC is mostly what these > interfaces provide. Sure you can wrap your API's into objects, no > problem, but they still amount to the principles of RPC; call a > function or method on an object with some parameters to invoke > business rules with data. And I hope you're not suggesting that OO > hides complexity better than good ol' procedures? :) >
OO is about calling methods and not knowing how they are implemented underneath. So when you call a method, you might underneath be using an RPC, but you could be sticking a message in a queue, writing an entry to a JavaSpace, or an http request etc etc. In the case of many systems that are built on the principle of stubs and interfaces such as CORBA, the methods/functions you invoke are indeed doing remote calls but not all "remote OO" technologies that present interfaces do this. Further methods on an interface don't have to be synchronous/blocking - you can model callbacks, queues etc if you choose to do so. If your WS-* tools vendor forces you down the line of RPC-style programming, that's their mistake (and they aren't the first nor will they be the last to make it). But, as you're expressing/designing interfaces, that doesn't have to be the way of the world. >> You also _don't_ have to know "bucketloads" on how that state impacts >> things if the service has been well designed, > > Well, "well designed" is a big cop out, as you can say that about anything. :) > >> you need to know >> _enough_ to complete your interaction. REST also requires you to >> understand the impact of state change. > > Actually, the dynamically REST system we've got only gives you > contextual endpoints, and as such does not require you to know about > state at all in a lot of cases. But I guess we can argue back and > forth about this, as we're on a strictly hypothetical level without > proper use cases. Yes, we as developers need to know shit, we need to > know what's going on, and what happens next, WS-* and REST the same. > > I find it very hard to talk with you about these things. A lot of > these things are about design more than they are about wheter you > technically can do it. They both can do it, no problem. With REST > there are some principles in place that just simply wins me over, such > as ; > > * Guaranteed GET for all resources (with content negotiation if you > want it; XHTML for browsers [or a Wiki page], > application/x-cool-invoice for your application, XML for debuggers > [browsers set up with it]) which makes it a doddle to see if I'm at > the right place at any given time. I don't need a fancy tool in an IDE > to do this; just a browser, or telnet, which makes it very easy to > capture the info, store it away, proxy it, forward it, document it, > and so forth. > > * The resource orientation itself (I don't need to know how to invoke > the "object", only how to use it) which also makes you think in > different semantic terms than objects (more structure and taxonomical > relationships), which is compatible with how most people on the planet > uses URL's. > > * URL's are free; they can be bookmarked (by browsers as well as > applications and tools), which helps in exposing your design (both > semantics and schematics) and hook people in (GET is easy; it somewhat > becomes part of your documentation) > > * Optional : Control of API schematics ; dynamically driven > machine-readable API's. (For static lovers: downside is of course that > they're dynamic :) > > * Based on technology that's been around for yonks, and is proven to a > large extent in terms of reliance and scalability, and the technology > specifically is much, much larger than service orientation alone (if > you're into WS-*, you're into service orientation; REST grapples with > much more than that) which means more people have expertize in various > aspects of it. > "Technology that's been around for yonks" - can you be more specific about what technology you're referring to? Web servers? Databases? Something else? For me service orientation is not about technology so I don't understand your statement about "technology is specifically much much larger". > I think that's my main positives. And I feel the negatives are more on > people's preference to the dynamic nature of REST more than what you > technically can do with it (but with a bit of proxying and caching, > REST can be pretty static too). Maybe people don't like the > multi-channeled nature of REST (content negotiating, mime-types) or > the lack of strong typing (at least by default; you can push XML > Schema based stuff down your pipeline if you want, but it just ain't > standardized). > > I think a lot of people struggle with the lack of strong typing as > being part of the "API" as such (or, the resource orientation), that > you have to glue a bit instead of having the stack deliver things back > to you in strong typed ways. But is this a technological limitation, > or just a personal preference? > > > Alex Dan.
