Elias Sinderson wrote:
> Someone quipped:
>
> >>Yes, but because the data, in the end, defines the semantics of the
> >>operation, HTTP is really immaterial. It doesn't provide a bit of
> >>extra anything to the applications overall ability to "work."
Which was me...
> >>
> To which Patrick Logan replied:
>
> >Tell that to the people who use a browser every day. See, a browser is
> >this application that... Oh, you probably know what a browser is.
> >
> And I say, +1 and here, here. :-)
>
> To ignore the contributions that an appropriate transfer / transport
> protocol selection makes to a distributed system is, well, ignorant.
My comment was a bit uninformative relative to the issues that I considered
prior to making it. I said 'the applications overall ability to "work."', and
didn't explain the context that I was thinking of.
I did say that HTTP was really immaterial. Other protocols can provide the
same
semantic features as HTTP. My reference point of view is as a Jini architect.
I don't think about protocol as a primary issue any longer. All I think about
is the logical architecture that I need. Later, near deployment, I plug in the
protocol that best solves a particular transport need. Because my application
is not toting around URIs, I am not focused on that level of implementation
detail. Instead, I'm carrying around the application data and the things that
matter to the application. Some of that data might in fact be a URI, but
that's
not the "transport" detail, that the "data" detail.
So, yes, I might have to use an URI to get to something that is only available
from a web server. In Java, a document can be represented by an InputStream
that I can create from lots of choices. I have a RemoteSocketStream class that
I use to stream data into Jini clients via an API call that might look like:
public InputStream getData(...) throws IOException;
On the grand scale of things, its the HTML or other content that the user
needs.
The transport is an interesting part of the puzzle, but focusing on a
specific
transport instead of the semantics that you need from the transport is another
point of coupling.
The above interface is about getting the data, not about how is it transported.
With mobile code in Jini, I can do this with an implementation in a smart
proxy How the clients get it can be important in the sense of the way the data
is available, but the protocol for transport or invocation semantics is not
always the best place to throw all your dependencies. In a smart proxy, I can
do
return new URL(url).openConnection().getInputStream();
or
return new StringBufferInputStream( document );
or
return new Socket( host, port ).getInputStream();
and the client won't have to worry about what brings them the data. If I'm
worried about retrying on error, and the client usage can facilitate such, I
can
do some other things to provide retries, restarts etc. But the client API is
not about all those semantic details of transport. It's just about getting the
data for the client to use and the API doesn't push the transport into the API.
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/
