On Sun, 2006-12-10 at 14:17, Steve Jones wrote: > On 09/12/06, Andrew S. Townley <[EMAIL PROTECTED]> wrote:
> > On Fri, 2006-12-08 at 20:41, Steve Jones wrote: > > > On 08/12/06, Andrew S. Townley <[EMAIL PROTECTED]> wrote: > > > > On Fri, 2006-12-08 at 15:27, Steve Jones wrote: > > > > > On 08/12/06, Andrew S. Townley <[EMAIL PROTECTED]> wrote: > > 5 min backgrounder/refresher on the REACH project: [snip] > > Sounds like an ESB.... It fits what I believe is the ESB concept, but none of the realities that I've seen to date. > > > > End of background/refresher > > > > This was our version of the uniform interface: send messages (somehow) > > to a destination, and, based on the service interface application > > protocol defined by that destination, one or messages would be delivered > > back to the original message source via whatever transfer mechanism made > > the most sense. > > > > The formal definition of the service interface application protocols are > > expressed as documents. An example of one of the core ones is here: > > http://sdec.reach.ie/rigs/rigm029/. To me this looks like a formal > > enough specification, even if it could be improved in some areas. > > 502 - Bad Gateway.... Me too... It worked when I wrote the email... :( Unfortunately, that server's software stack in its current state isn't quite as robust as could be desired. To save you the trouble, it's a document. The normative version is in ODF, but it's still a document. [snip] > It makes them less formal at the application level as they cannot be > used to implement automatic contract enforcement and they require a > degree of human interpretation which is therefore open to error and > differences. Yes, but in a lot of cases, the cost of that automatic contract enforcement is ending up with something that's pretty un-resilient to change. They *can* be made flexible, but most tools don't, because it's kinda hard, because the tools can't really understand how that's to be done. Back to those error-prone people again, unfortunately... [snip] > Eh? I'm a member of a few standards bodies and I'm well aware of what > it takes, I'm not seeing the same formalism in the REST world, indeed > its used as an advantage of REST that it hasn't been defined by a > commitee. What is your point? I know. My point was here ----v > > > > You're still going to need this agreement anyway if you're going to bet > > your business (or your partners') on your SOA, WSDL or not. What the > > WSDL provides to an SOA in my view is such a minor piece of the puzzle, > > Its a bit more than minor as it provides an agreement of format and > function, if not the full semantics of the interface. This document > can then be versioned, which is a good thing. The formalism isn't needed at the REST level (although, as mentioned, more patterns and guidelines would be useful), it's needed at the application level. The application level is the only part that matters because that's the only part that varies. > > I'm a bit surprised that you're so dead-set convinced that REST is not > > viable because there's nothing machine processable that's been specified > > and is in de-facto use. > Given a commercial project and picking an approach where it is "roll > your own" or "start with this" I'll always pick the later having done > a bunch of the former. A roll your own approach will be obsolete in 5 > years, a standards based one has a better chance of being supported > (e.g. CORBA might be "dead" but I can still bridge to it, I dare > anyone to have a crack at the Unix Pipe stuff I did in the early 90s). I did a bunch of stuff on Unix (pipes, sockets & shared memory), so bring it on! ;) I'll only do the latter if I believe you aren't going to end up in a bigger mess in 5 years with it than you would without it. A lot of times I do, sometimes I don't (and I don't like *either* Mounds or Almond Joy, so don't ask). > > > > The business-level semantic agreement of both the messages and the > > interaction protocols is what's going to make or break the SOA, not the > > technical invocation mechanisms. > > I 100% agree, which is why I'd like to see work concentrate on this > level rather than the current REST v WS debate, as I've said before > lets just back a horse (WS) and fix the real problems, rather than > optimise the non-problems. There's that pesky "cost of change" problem that I'd still like to see a way to address, but maybe that's just me. > > WSDL describes a more complex > > invocation mechanism, therefore it has tools to help developers hide > > that complexity. > And provides the developer with a formal specification of what they > have to develop or invoke. Which saves them maybe 15-30 minutes of Eclipse time that could've also been *saved* by giving them a UML diagram--especially if you're from the OMG. They're still going to have to fill in the blanks correctly based on an understanding they get from where? Formal specification of the interface does not equal formal specification of the application or the architecture. > > REST has a straightforward invocation mechanism, so > > your toolkit can simply be XMLHttpRequest. > > But with no standard way of sharing specification between consumer and > producer... so its simpler because it has less. Because that's not the part that matters when you're developing either end of the service. > > What is it exactly that I don't understand about what you're saying? > > Possibly nothing, but what I'm after is two things to help me understand REST > > 1) What is the "official" URI definition policy (I like Mark's > readable HTML formable approach, but not everyone else does in the > REST world) > 2) How do I formally define the business level interface, or even the > application level interface between consumer and producer. As I mentioned in the message before this, I'm not sure I can help you there--I don't have all the answers. Peace. ast -- Andrew S. Townley <[EMAIL PROTECTED]> http://atownley.org
