Gregg Wonderly wrote:
>
>
> Steve Jones wrote:
> > +1 from me. This is pretty much what I've been banging on about for a
> > few years. The implementation bit is the secondary concern and then its
> > about "what works best when", the real challenge for for IT to start
> > working at the business service level and its from there that the right
> > implementation decisions will be made.
>
> I haven't had a chance to read everything in the replies that followed
> up my
> previous response on the
>
> Anne on REST (Time for Spring WS v. REST Campaign to Open)
>
> thread. But, I have found some interesting comments that seem to finally be
> comming around to the realization that in software systems, we don't
> like it
> when programmers sprinkle implementation details everywhere, as in
> having the
> following kinds detail everywhere we interact with an HTTP server.
>
> URL u = new URL("http://example.org/people/anne
> <http://example.org/people/anne>");
> URLConnection uc = u.openConnection();
> uc.setUseCaches(true);
> InputStream is = uc.getInputStream();
> BufferedReader rd = new BufferedReader( new InputStreamReader( is ) );
> String str;
> StringBuilder sb = new StringBuilder();
> while( ( str = rd.readLine() ) != null ) {
> sb.append(str);
> sb.append("\n");
> }
>
> instead, systems will have domain specific interfaces that the client
> software
> uses as in.
>
> public interface OrganizationInfo {
> public Person getPerson( String name );
> public List<Person> getPeopleOfAge( int age );
> ...
> }
It's interesting to watch you compare a crufty http access
implementation with an *interface*. Sheesh.
Alternatively:
h = httplib2.Http(".cache")
# ...authentication here...
resp, content = h.request("http://example.org/people/anne ", "GET")
if resp["status"].startswith("2"):
anne = get_person(resp, content)
else:
raise AccessException(resp, content)
ie about somewhat less awkward than hitting a database.
I haven't found domain models any less maintainable than dealing HTTP
(or XML). Maybe that's because domains keep changing as a fucntion of
the business - this should give pause to people who want to model
services as highly business specific and do that up and down layers -
businesses aren't exactly stable domains.
1: you still haven't explained why I can't order a Pizza with Jini. What
went wrong? I won't get into setting Jini up to actually do something,
though that's better now than it was a few years ago.
2: what are these many domains HTTP isn't suitable for? Details please.
I keep hearing this assertion, but without any specifics. I don't doubt
HTTP isn't suited to everything, but surely it can't hard to provide
some examples?
cheers
Bill
