You are right Emil, Hessian can be asynchronous in its own rights, I regret I forgot to mention this in my last message. What I had tried to express is the less visibility of message/envelope paradigm I felt from the spec documents, and short of demos around it. I didn't see much descriptions of how streaming model differentiate from normal mode of hessian, so assumed that only serves as a basement for advanced users to build their own higher level protocols.
You are right again that (a)synchronous is more matters of the system design, but not the protocol used. However *web services* are synchronous-tending since people normally invoke them and expect return values, for whether some result data or the status code of success/failure. Web services are normally desiged for such synchronous useage, so does EJBs etc, those I found are "Invocation Based" Better asynchronous system needs client code don't expect any synchronous return from remote invocations, so a series of invocations can be bundled as a single transaction script and executed as an atomic unit at the remote side. And to receive effects of its asychronous invocation, a client also needs to *host* execution of logics from its peer, in an asynchronous fashion. This is why I call it "Hosting Based Interfacing" and have to derive a new protocol from Hessian. The biggest difference from Hessian is a series of invocations are bundled as a single task script, executed as a whole, and may be retried transparently upon certain kinds of failures (e.g. an optimistic commit of database transaction failed). Let's see how it will go. Cheers, Compl On 9/14/07, Emil Ong <[EMAIL PROTECTED]> wrote: > Hi Compl, > > Your framework sounds interesting. I look forward to seeing how it > will develop. > > One thing I will disagree with is that Hessian is a synchronous only > protocol. It does have a request/response model as one of its modes > of operation, but it also has a message/envelope model as another in > Hessian 2.0. Both of these protocol models can support both > synchronous and asynchronous programming models. I would argue that > (a)synchrony is more an issue of implementation of the client or > server stubs if the protocol is designed appropriately, as I believe > Hessian is. > > Take care, > Emil > > --- Compl Yue Still <[EMAIL PROTECTED]> wrote: > > > Hi, > > > > I'm working on a framework seems relevant, and is going to be > > opensource once functional complete. > > > > I think there will need a long streaming http connection from swf > > to > > the server to receive back invocations in realtime; and since http > > normally submit data only once at the beginning, there will also > > need > > short http requests upon invocations from swf to server, or it may > > cause problems with http proxies and caches. > > > > I'm working on a total conversion for such server-push solutions. > > My > > framework derives a binary wire protocol from Hessian, and is > > asynchronous. The coming first public version will leverage Flex > > interface and Java backend. > > > > To my understanding hessian is synchronous due to its web-service > > nature, and realtime/streaming communication should be more natural > > when implemented in asychronous ways. However it doesn't only mean > > asychronous at the protocol level, but backbone of the system > > architecture, i.e. you need to head away from the traditional > > "Invocation Based Interfacing" approaches (which I'm coining to > > refer > > to RPC/RMI based service model, including WS, EJB, ORM, various > > data > > services today etc). Instead we can go "Hosting Based Interfacing" > > (HBI is my framework name ;-) that data manipulation always occur > > at > > where the data is, hosted by the local domain controller. 'domain > > controller' is close to the 'server' concept but an RIA is also a > > domain controller which has its own domain data model at the > > 'client' > > side. Under such an architecture, no "structured-object" will be > > transfered over wire any more, but the code manipulating them and > > manipulation arguments are transfered from an original domain to a > > target domain, and hosted executing by the target domain > > controller. > > So application code always interact with local data (through its > > local > > encapsulating logic if go OO) and local environment. This helps > > performance and elegancy. It aims at "Rich Domain Model" at both > > server and RIA side, in contrast to plain old data service backed > > architectures. > > > > The draft spec of the HBI wire protocol is attached, I hope > > someones > > are interested to have a look at it now. And I'll release full > > source > > code with demos (Apache or BSD license) very soon, then I will be > > glad > > to talk with Resin guys if such a thing can fit into the Resin > > platform. > > > > > > Cheers, > > Compl > > > > > > On 9/13/07, Emil Ong <[EMAIL PROTECTED]> wrote: > > > > > > --- Vic Cekvenich <[EMAIL PROTECTED]> wrote: > > > > > > > http://hessian.caucho.com/ria - Outstanding! I will be using > > this > > > > right away, I was looking for an open source binary protocol > > for > > > > as3, and have used hessian in the past, no more need for Data > > > > Service product and the loads of jars it comes w/. > > > > > > Great! > > > > > > > Question: is there a way to do a push to flex and leverage > > this? > > > > > > > > Ex: Flex pings server to open a connection/socket(ex: w/ > > Mina/Nio > > > > help), and now I keep a list of them, so that I can > > > > "push/invoke/send" a message from Resin server to a specific > > flex > > > > client. So an invoke not from Flex to Resin(which was the > > example) > > > > but a message from Resin to Flex? > > > > Suggestions? > > > > > > Hmm... this is an interesting issue. In the Hessian 2.0 > > protocol, we > > > have support for streaming calls which might be appropriate in > > this > > > situation. On the other hand, I'm not sure that we actually have > > a > > > programming model to support that on the server side yet. (I'll > > have > > > to check that.) It probably would not be a servlet... maybe an > > EJB > > > or something. In other words, the server side would be just as > > much > > > of an issue in the push problem as the client side. > > > > > > Do you know of any examples already in Flex that do push? Does > > Flex > > > Data Services do that? If so, what is their API for it? > > > > > > Thanks, > > > Emil > > > > > > P.S. I cc'd this to hessian-interest. > > > > > > > > > _______________________________________________ > > > hessian-interest mailing list > > > [email protected] > > > http://maillist.caucho.com/mailman/listinfo/hessian-interest > > > > > > > > > _______________________________________________ > hessian-interest mailing list > [email protected] > http://maillist.caucho.com/mailman/listinfo/hessian-interest > _______________________________________________ hessian-interest mailing list [email protected] http://maillist.caucho.com/mailman/listinfo/hessian-interest
