Congratulations on your paper re: KnowNow

Mr. FoRK fork_list@hotmail.com
Fri, 12 Apr 2002 18:56:33 -0700


Their framing of MVC over J2EE misses the point of a 'web' application. In a
Web application, the 'model' is not the internal j2ee entity beans, but
rather the resources addressable outside a single server (or cluster of
servers).
Just considering a J2EE server as the 'bounded object set', the MVC view
does somewhat fit over entity-bean/JSP/session-bean, but it still doesn't
quite feel right.


Mike

----- Original Message -----
From: "Rohit Khare" <Rohit@KnowNow.com>
To: <weiquan.zhao@cs.unisa.edu.au>; <david.kearney@unisa.edu.au>;
<giogy001@students.unisa.edu.au>
Cc: "Richard Taylor" <taylor@ics.uci.edu>; <FoRK@XeNT.Com>
Sent: Friday, April 12, 2002 12:46 AM
Subject: Congratulations on your paper re: KnowNow


> Gentlemen --
>
> I was quite pleased to see your latest work from DSTC:
> http://www.dstc.monash.edu.au/awsa2002/papers/Zhao.pdf
>
> Not least, of course, for your valuable analysis and demonstration of
> the basic insights behind KnowNow's technology. I am perhaps even
> more impressed that these ideas shone through clearly enough you
> could construct this _without_ being indoctrinated by any of our
> employees... !
>
> A few of my first impressions:
>
> * You are indeed correct that there is a bit more to converting a
> J2EE app "back" into a real MVC app than sprinkling r/t widgets into
> JSPs. Entire chunks of functionality have to be rewritten into
> "single-page applications" (a rhetorical flourish I credit to
> OpenTibet, actually). The analogy I originally proposed was to call
> our applications ESPs (event server pages) to convey that sense.
> Another idea bandied about was ACPs (active client pages) to make it
> clear that the processing burden was on the client side. Dialing the
> psychic hotline at 1-800-KNOW-NOW clinched it, though...
>
> * The reason I called them microservers was that they indeed were
> intended to be substitutes for the lack of IP-addressible HTTP
> servers on the client machines. By reducing them to a form that could
> be embedded within a document scripting language (DHTML, VBA) and
> punching out persistent connections, we invented a commercially
> relevant transitional technology that simulated real HTTP
> client/server pairs at each node.
>
> *  One explanatory construct that doesn't come through as clearly in
> our current generation products is the role of active proxies. The
> theoretical extension was that rather than, say, directly POSTing a
> new bid to ebay.com's server, you could proxy that through a KN
> Router, which would _also_ POST it to lots of servers sitting inside
> the pages of other interested bidders' browsers at the same moment.
> In essence, I view our technology as a way to attach subscribing
> servers to the _end_ of a proxy chain. See also Microsoft's proposal
> for WS-Routing and very early work at W3C on PEP. And, of course, a
> proxy can be inserted on a subscriber's path that can filter,
> transform, and analyze message flows as well, which is the basis for
> our plug-in architecture for content routing.
>
> * Finally, the essential aspect of our product that has yet to come
> into its own is why we call it a router: multiprotocol support. Just
> as a Layer 3 router works to interconnect various LAN protocols
> (DECnet, AppleTalk, Novell IPX) by internally casting all traffic as
> IP and dispatching it as IP; our vision for an application-layer
> router is a way to connect user applications that speak HTTP, SMTP,
> NNTP, FTP, and so on by upconverting to a protocol that looks
> suspiciously like SOAP. Hence, SOAP Routing. Of course, that's
> another matter for now... I'll be writing more about it in my PhD
> thesis this summer.
>
> Once again, my thanks for your work! Do let me know how we I can be
> of assistance.
>    Rohit Khare
>    Founder & CTO
>    KnowNow
>    (on leave at UC Irvine)
>
>
> http://xent.com/mailman/listinfo/fork
>