[news.eclipse.technology.riena] Re: Release 1.0.0.M1

[Christian Campo <christian.campo@xxxxxxxxxxxx>]

Scott Lewis schrieb:
> Hi Christian,
>
> Christian Campo wrote:
> <stuff deleted>
>
>
> > > One possibility for doing this would be to create a new ECF namespace 
> > > extension (i.e. a 'riena' namespace), which would allow you to do 
> > > things like uniqueness checking on construction, create your own 
> > > factory for your type of IEndpoint, etc.
> > Currently we thought that using strings is the simplest syntax to 
> > create a proxy. We currently want
> > no dependency to ECF (as discussed earlier) and so no ECF namespace. 
>
>
> OK.  Just FYI, this extension point/service will be in p2/Ganymede so 
> there will be no extra cost in distribution/size, etc.
Not sure about that since Riena apps don't necessarily have the whole IDE in but just
a selected list of bundles. But I keep my eyes open.
> > What you can do is call createAndRegisterProxy
> > with a RemoteServiceDescription object. That requires you create the 
> > RSD first, but that is an alternative approach.
> > > 3) What if the client doesn't have this endpoint information in 
> > > advance?  I assume that that's where any discovery mechanisms come 
> > > in, correct?
> > We currently don't use discovery that much and assume that a client 
> > nows where the web service endpoint is located that
> > it wants to call.
>
>
> OK.
>
>
> > > I don't know anything/much about Hessian, but
> > >
> > > 4) I assume that the actual http request/response is made at service 
> > > invocation time, correct?
> > correct
> > > 5) Does it have any connection caching/etc to improve performance?
> > its pretty fast already :-) Hessian uses HttpURLConnection from the 
> > JDK which has some connection reuse.
> > nothing more than that. we have a productive system that uses Hessian 
> > with 30.000 users and performance in webservices is quite ok.
>
>
> You might want to also test it with/on clients that have very 
> slow/unreliable network connections as well.
Our production system where we use Hessian has clients on:
LAN, WLAN, Router, ISDN, DSL (multiple speeds), UMTS, GPRS, Sky-DSL, Cable-modem......

So I thought we covered that area mostly...... :-)
> > > 6) What about multiple simultaneous thread access to a given service 
> > > method?  How is this handled?
> > it works.:-).....all objects that are call based are local variables, 
> > some are stored in ThreadLocals
>
>
> Doesn't the ThreadLocal usage make it difficult to non-blocking calls 
> (i.e. calls based upon transports other than hessian/http)?
The ThreadLocals are within the publisher and factories for hessian. So if you
use another transport than you can choose what you like to use. Also (as discussed
in earlier threads) we prefer synchron calls and placing them in background threads
using the jobs api, rather than making a asychronous call. Riena communication only
does synchron calls since you call a business related method in an interface and expect
the result to be available when the call returns.
> > > 7) If someone wanted to replace hessian with a connection-oriented 
> > > middleware (e.g. JMS, private protocol, etc), would they be able to 
> > > do this without modifying riena itself?
> > should be, havn't tried.....
> > > 8) Are there any ways to specify timeouts associated with remote 
> > > invocations (other than setting the JRE-wide http connect and read 
> > > timeouts)?
> > not yet.....this is M1 :-)
>
>
> Understood...just asking :)
>
> OK...thanks!
>
>
> Scott
christian