Greg, > > When I send my "GET /", what kind of server am I talking to? How > do I know what > type of GET command to send it?
Go for HTTP/1.1; the server will tell you what it is using in the response. > How do I know what response to expect? I have > to expect any all all possibilities, or I have to reduce my > expectations from > the server so that I only have to deal with 1.0 for example. > >>> Thus the binding of the protocol into the application which I find >>> unacceptable >>> as a general SOA practice. >> >> But it is an illusion that you can have delivery semantics without an >> application protocol (see Mark's reply). So why not use an existing, >> well deployed one instead of rolling yet another one and (ab)using >> the existing application protocols as transport? > > The limited "application protocol" that http supports is not > sufficent to allow > me to talk to a device that speaks MODBUS, without a "proxy" > service in the HTTP > server for example. How is http anything more than a "transport" > in that realm? It is more than a transport because it provides HTTP access to the non HTTP application. You'd implement a gateway to interact with the MODBUS device: "HTTP is also used as a generic protocol for communication between user agents and proxies/gateways to other Internet systems, including those supported by the SMTP [16], NNTP [13], FTP [18], Gopher [2], and WAIS [10] protocols. In this way, HTTP allows basic hypermedia access to resources available from diverse applications." [1] > I can generalize RMI based programming to be document oriented, > MODBUS oriented > or some other protocol because there is no expected structure to > the application > protocol which would confine my opportunities. If I choose HTTP as > the only > 'network' protocol, then I am limited to what it can do as an > application Yes, the architectural constraints impose restrictions on the design - providing the benefit of guarranteed system properties. It is a tradeoff, sure. > and > interface, and ALL of my clients are now HTTP centric, instead of > protocol > agnostic. I wonder: how does a Jini client talk to a MODBUS device? Where is the mediator located between the two worlds? Jan > [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec1.html#sec1 > Gregg Wonderly > > > > > > > Yahoo! Groups Links > > > > > > 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/
