Jan Algermissen wrote: > > On Sep 19, 2005, at 4:10 PM, David Forslund wrote: > > > OK. I agree that http is defined as an application protocol and has > > been extended from its original position > > as a hypertext protocol. > > I am not sure at what point the HTTP authors started to see HTTP as > REST interprets it today, but I think it was pretty early if not > right from the beginning. > > See [1] for example > > > The fact that it is stateless is viewed both > > as a strength and weakness. Since > > may systems require state, > > I do not think that any system requires client-server interactions to > be stateful. What kind of state do you have in mind? If you need > state in HTTP, create a resource to hold that state.
Maybe I'm missing something here, but why do we have "sessions" if we don't need state. One has to be able to hook up to the appropriate session at a later time. And state is certainly needed when one is dealing with bank accounts. Cookies is a peculiar invention, it seems to me, to deal with the lack of state. > > > > one must figure out how to add state to a > > stateless protocol when it is needed. > > My point is that it possible to run CORBA over HTTP, if one likes, so > > the boundary here is quite loose. > > The application semantics of http are quite weak and one needs to > > include actual "operation" semantics > > in the http payload if one is to use it in a real SOA application, > > which > > needs to know what to do with data > > that is coming over the "protocol". > > Hmm...and the question is: What is a *real* SOA application? Sounds like a metaphysical question. But I have been using numerous SOA applications with full standards end-to-end for 7-8 years. The API is pretty stable, is internationally standardized, easy to change and the semantics are fully discoverable. It is just that these don't happen to use http. I know SOA seems to be being used to apply to distributed computing services over the web, but that requirement certainly isn't in the term "service-oriented-architecture". > > IIRC nobody has yet presented a use case that cannot be handled with > REST. What's your's given that you say that the "application > semantics of http are quite weak"? The terms being sent and received are not defined an any rigorous manner. And where is the definition of the "operation" being invoked on the data? As a simple example, take the Personn Identification Service specification from the OMG (that has a UML model), and map it to REST. I'm sure it can be done but it will take a lot of additional documentation and agreements to accomplish it. Mapping it to WebServices, for example, expands the interface specification by more than an order of magnitude. Basically, I want to see an interface specification for a service for this type of service in REST. I haven't really seen a rigorous specification of an interface to be used with REST. This would be something that a client can discover and utilize and run without any prior knowledge of the service. Thanks, Dave > > > > > > Jan > > [1] http://www.w3.org/People/Connolly/9703-web-apps-essay.html > > > Dave > > Jan Algermissen wrote: > > > > > >> > >> On Sep 18, 2005, at 2:42 AM, David Forslund wrote: > >> > >> > >>>> Application protocols define application semantics. They are not > >>>> "protocols" in the same sense of the word used in systems like > >>>> CORBA, > >>>> DCOM, RMI, Jini, etc.. IMO, that's the root cause of the > >>>> misunderstanding. If these things had been called "locotorps", > >>>> this > >>>> confusion wouldn't exist; "protocol independence" would be a good > >>>> idea, since protocols just move bits around. But "locotorp > >>>> independence" would be silly, because everybody knows that > >>>> locotorps > >>>> define the application semantics, and how can an applications be > >>>> independent of application semantics?! 8-) > >>>> > >>>> > >>> > >>> Yes. Using "protocol" for how bits on the wire are organization and > >>> application semantics is > >>> a bad idea. http is a protocol. > >>> > >> > >> No, HTTP is defining application semantics. It is an application > >> protocol and not > >> a 'bits on the wire' transport protocol. > >> > >> Jan > >> > >> _____________________________________________________________________ > >> ___ > >> _______________ > >> Jan Algermissen, Consultant & Programmer > >> http://jalgermissen.com > >> Tugboat Consulting, 'Applying Web technology to enterprise IT' > >> http://www.tugboat.de > >> > >> > >> > > > > > > > > > > > > > > ------------------------ Yahoo! Groups Sponsor -------------------- > > ~--> > > Get Bzzzy! (real tools to help you find a job). Welcome to the > > Sweet Life. > > http://us.click.yahoo.com/A77XvD/vlQLAA/TtwFAA/NhFolB/TM > > -------------------------------------------------------------------- > > ~-> > > > > > > Yahoo! Groups Links > > > > > > > > > > > > > > > > ________________________________________________________________________ > _______________ > Jan Algermissen, Consultant & Programmer > http://jalgermissen.com > Tugboat Consulting, 'Applying Web technology to enterprise IT' > http://www.tugboat.de > > > ------------------------ Yahoo! Groups Sponsor --------------------~--> Fair play? Video games influencing politics. Click and talk back! http://us.click.yahoo.com/T8sf5C/tzNLAA/TtwFAA/NhFolB/TM --------------------------------------------------------------------~-> Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> 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/
