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

[Christian Campo <christian.campo@xxxxxxxxxxxx>]

Scott Lewis schrieb:
> Hi Christian,
>
> Congrats to the team on the M1.
thanks....
> I have some technical questions about the getting started examples and 
> about Riena in general.
>
> 1) In your getting started under "Accessing the remote OSGi Service" you 
> have:
>
>         pingPongReg = rsf.createAndRegisterProxy(IPingPong.class, url, 
> protocol);
>
> And in the plugin 
> org.eclipse.riena.communication.sample.pingpong.client.config (which 
> seems to be the source):
>
>         pingPongReg = rsf.createAndRegisterProxy(serviceInterface, url, 
> protocol, "de.compeople.pingpong.config");
>
> 1) What is this fourth parameter?
The fourth parameter is the Config ID. You can leave it null. If you specify it the proxy is not only
registered with the serviceInterface but also with the interface ManagedService and the configid
as SERVICE_PID. That way you can change configuration parameters using the ConfigurationAdmin.
We have currently implemented to change the URL of the proxy. So you can redirect the client at runtime
using CM. We also using ConfigurationPlugin (another feature of CM) to replace variables in URLs with
actual values like http://{host}/hessian/PingPongWS could be configured to http://172.157.2.2:8080/hessian/PingPongWS
> 2) A thought:  wouldn't it be a cleaner/simpler/less error prone to have 
> the 'createAndRegisterProxy' call combine the url and protocol Strings 
> into some sort of 'IEndpoint' object that includes both info about the 
> wire protocol (e.g. http), and info about the service publisher-level 
> protocol (hessian in this case)?
>
> 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. 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.
> 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.
> 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
> 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 :-)
> OK, I see that some of the real remote service invocation action is in 
> HessianProxy.invoke/3.  This seems to be where the actual connection is 
> created, the parameters marshalled, the http request/response handled, 
> and a result returned.
right....which is then done in Hessian2Output and Hessian2Input and so on.
> I think it will be straightforward to create an Riena-based provider for 
> the ECF remote services API...I'll be starting on this soon.
>
> Hopefully some more questions as we go.
>
> Thanks,
you are welcome (as always)
> Scott
christian