Jan Algermissen wrote:
> Go for HTTP/1.1; the server will tell you what it is using in the
> response.
But, how do I know that the user using my HTTP client will use it with an http
1.1 server? 1.1 servers are much more expensive to create in total code that
1.0 servers. Remeber, I'm talking about things you do on restricted
programming
environments. We can by a Microchip PIC uP for $0.12 that has less than 12
bytes of RAM memory. How can we get that device to store a complete HTTP
inbound request? I can, buy something for $10.00 or so that has more space and
will have the ability to do HTTP. But look at the difference in price point.
The next generation of massive communications development is happening to small
devices with limited resources.
> > 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:
Then why use HTTP?
> "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]
This is an acceptable statement to make, but the reality is that it requires
device side resources that are not always available.
> > 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.
But you can't guarentee that every HTTP server that I try to download something
from isn't misconfigured with mime-type verses file type. Thus, users will
have
bad experiences and will get unexpected results that are created by the system
and faulty configurations. There's no additional value that HTTP is providing,
if it still has't fixed this kind of data integrity. With more tightly typed
data, I don't have the type problem.
> > 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?
As I've posted here before, we just drop in an appropriate endpoint for the
wire
protocol, and then an invocation layer factory that translates the native API
into appropriate modbus exchanges. Thus, the application is not coupled to the
protocol, only the required deployment pieces have that coupling.
Gregg Wonderly
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/
