Steve Jones wrote: > > > On 19 July 2010 21:13, Alexander Johannesen > <[email protected] > <mailto:alexander.johannesen%40gmail.com>> wrote: > > Hi, > > > > Meh. I find it very silly to blame "cool" REST for the state of > "trad" WS-*. > > > > Steve mentions "If you had to do an integration between 20 different > > programmes and over 300 systems in a heavily regulated area then you'd > > use REST?" Yes, why not, since a lot of people are actually doing so? > > Where? Seriously give me a few examples where people are integrating > 300 systems in a heavily regulated industry using REST. > > > > > Maybe the problem is one of context; maybe Steve and the Enterprise > > world (although I suspect a very specific version of it) are missing > > out on something? Maybe it's standing a bit still because there's only > > so far you can go within it? > > Yup that'll be it. Its because we don't "get" REST. Or could the > fact, and it is a fact, that the vast vast majority of integrations > out there are being done via WS-* indicate that REST hasn't in anyway > shape or form become as popular in the last 5 years as Web Services > did in its first 5 years. This to me would indicate that the > challenge is more a case of the solution not fitting the real actual > problems.
From a simple perspective, this is a reflection of the view that REST, as of yet, is not viewed as anything other than a "transport" technology, in the form of HTTP. Yes there is the WWW, but we are talking about SOA, not just about the WWW. From the outside, we see so many other network application protocols use HTTP (the defacto example of REST) as a transport (and I know it's mostly because of port 80 being open through firewalls). So, because there is not a "toolset" that builds REST applications. In the end, I really think that there is a lot of REST going on, but people just don't see the bigger picture. As I've said here before, technologies as basic as RPC are RESTful, because you can consider their "verbs" to just be "invoke". The rest of the data that says what remote object and what method and with what arguments are exactly the same bits and types of information that an HTTP POST request reflects. URL == remote object reference - the resource Request Content == The Method indication and the parameter values Return Response == Result from method invocation Hyperlink == A return value that is a remote proxy to another object. There are all kinds of things which map into the structure of an HTTP/REST request/response. If you look at, for example, a Jini service registration, lookup and use, you can see that the ServiceRegistrar returns a ServiceItem which packages all of the details for using the service. The ServiceItem.service value may or may not actually be a remote reference. It might be a smart proxy which wraps one or more remote references. It might be a smart proxy which looks up the service to use dynamically to provide automatic fail over. I suppose we could even have the discussion of whether or not any application protocol running on top of HTTP was inherently restful. If it's not, should we venture to say that HTTP is really just a transport since its use doesn't make something inherently RESTful? Gregg Wonderly > Steve > > > > > Just a thought. > > > > > > Alex > > > > > > > > > > > > On Mon, Jul 19, 2010 at 7:27 PM, <[email protected] > <mailto:ashley.mcneile%40metamaxim.com>> wrote: > >> > >> > >> > >> Hi All > >> > >> I am entirely with Steve in this post on the importance of contracts > >> (Contracts really matter - without them everything becomes tightly bound > >> no matter what people claim about "dynamism"). > >> > >> However, I wonder whether the concept of "contract" that we have > (based on > >> stating pre- and post-conditions) is sufficiently general and > flexible to > >> handle all the situations we face in defining and building service > >> software. I have been thinking about this for a while, specifically > in the > >> context of extended service collaborations, and written a short paper > >> (available at > http://www.metamaxim.com/download/documents/contracts.pdf ). > >> > >> I would be interested to know what others on this list think about > this -- > >> in particular whether there is any experience of devising or using other > >> kinds of software behaviour contract. > >> > >> Rgds > >> Ashley > >> > >> > > >> > > >> > You can read this at: > >> > > http://service-architecture.blogspot.com/2010/06/rest-has-put-enterprise-it-back-five.html > >> > > >> > Gervas > >> > > >> > Reply to sender | Reply to > >> > group | Reply via web post | > >> > Start a New Topic > >> > Messages in this topic (1) > >> > Recent Activity: > >> > New Members 4 > >> > > >> > Visit Your Group > >> > MARKETPLACE > >> > Stay on top of your group activity without leaving the page you're > on - > >> > Get the Yahoo! Toolbar now. > >> > >> > > > > > > -- > > Project Wrangler, SOA, Information Alchemist, UX, RESTafarian, Topic > Maps > > --- http://shelter.nu/blog/ > ---------------------------------------------- > > ------------------ > http://www.google.com/profiles/alexander.johannesen --- > > > > > > ------------------------------------ > > > > Yahoo! Groups Links > > > > > > > > > > ------------------------------------ Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/service-orientated-architecture/join (Yahoo! ID required) <*> To change settings via email: [email protected] [email protected] <*> To unsubscribe from this group, send an email to: [email protected] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
