hivemind-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrea Chiumenti <>
Subject Re: suggestion request!
Date Mon, 12 Sep 2005 21:02:10 GMT
Thank you for support, after a small 'pit-stop' to think about a possible 
solution I think that the best solution is to have a proxy service over 
the original service so that the business logic to pass the user remains 
tied to the proxy. So for example to retrieve a user print list the code 
will be something similar to the following :

class MyProxyService extends Hessian... implements IMyProxyService {
public Collection getUserReportQueue() {
return getMyService().getUserReportQueue( getUserPrincipal().getName() ):

This is the only method I've found to keep code clean and I can also use 
hivemind to inject service into proxies so that I can avoid using hessian 
when working into the same jvm and I could even map the service into ejb 
(who wants this ?).

Thanks again,

On 9/12/05, Jean-Francois Poilpret <> wrote:
>  Hi Andrea,
>  [For HiveMind list readers, sorry for the noise here, but I think this is 
> a general architectural problem that deserves broad discussion and other 
> HiveMind users might be interested too]
>  OK, I see now. In this case, what you need is not really a Principal (a 
> Principal is not supposed to contain information about printer format, only 
> user information, such as the UserId as you mentioned, except if the printer 
> format is part of the information of the user and that information is not 
> explicitely sent by the client everytime the user logs in).
>  1st case (simplest):
> - you manage the user info (including printer format info) in a 
> centralized way (stored on your DB) and this info can be changed only by an 
> administrator (or kinda).
> - Then you can use Principal to store all this info (and 
> HiveLock/SecurityFilter can help you fill in this specific Principal)
>  2nd case (harder):
> - the printer info is completely dynamic (and decided by the user on the 
> client application)
> - what you need here (if you do not want to add this info to each of your 
> service methods) is to have some kind of "context passing" (the context 
> would be all the printer format info).
> - Normally, Hessian supports this kind of context passing through "Hessian 
> headers", however, as of hessian 3.0.13 (latest) this does not workL (see 
> my mails on the hessian mailing list to see why)
> - In hiveremoting.caucho (0.4.6 and 0.5.0-B3 only), I implemented some 
> kinda "context passing" over hessian without using hessian headers, but 
> using http headers instead. The drawback of this method is you can pass only 
> string context(s), not structured Objects as one would like. This feature 
> has been used in HiveBoard 0.2.0 for checking versions between client and 
> server, you may take a look at it (check for occurrences of 
> RemoteContextHandler in HiveBoard classes).
> - What you would have to do is to create, on the server side, a special 
> RemoteContextHandler that would put those context strings in a ThreadLocal 
> so that your services can access them (possibly your RemoteContextHandler 
> would also pre-format these context string into one context object, easier 
> to handel by your services).
>  I hope this helps you finding your way to your own solution.
>  Cheers
>  Jean-Francois
>    ------------------------------
> *From:* Andrea Chiumenti [] 
> *Sent:* Monday, September 12, 2005 1:07 PM
> *To:*
> *Subject:* Re: suggestion request!
>  Jean-Francois, *
> *Thank you for the prompt reply, but yes, you missed something, I didn't 
> probably explained myself in the proper way.
> When printing a report I need to know its type (A4, Label, A3, ...) so 
> that user can address it to the right printer, and need to know the user id 
> too, so that only reports belonging to the requireing user are handled. It 
> seems to me that hivelock, that I want to use, only handles the 
> authentication/authorization layer.
> I hope this can clarify what I missed.
> kiuma
> On 9/12/05, *Jean-Francois Poilpret* <> wrote:
> Hello Andrea,
>  I don't understand why the principal has to be passed by the client.
> If you use hiveremoting.caucho with hivelock and SecurityFilter (I have 
> done this in hiveboard already) then the only extra info to be passed by the 
> client is the session identifier. This session identifier is stored in a 
> cookie so it is transparent for the service calls. In this case, the 
> authentication happens only once and occurs through normal http 
> athentication scheme (hiveremoting.caucho already supports this).
>  Does this answer your problem, or is there something I have missed?
>  Cheers
>  Jean-Francois
>   ------------------------------
> *From:* Andrea Chiumenti [] 
> *Sent:* Monday, September 12, 2005 12:26 AM
> *To:*
> *Subject:* suggestion request!
>  Hello,
> I wanto to create a web project that has a service named 
> AsynchronousRemotePrinting.
> This service grants to you to directly send reports to your local printer 
> simply clicking on a web-link on your browser, this will be a feature of an
> OS project that will make heavy use of hivemind(and hivetranse) and 
> tapestry.
> The way i can make possible to print on the user local printer from a web 
> browser is relatively simple:
> 1) When the user log into the application for the first time he starts a 
> client application via webstart, and identifies himself.
> 2) Asking for a report to print ( click on a link on the browser), means 
> to save the report by email or webdav.
> 3) The webstart application has a chron job that periodically asks to the 
> server if the user has some report to print
> 4) If yes, then, throught Hessian, the local application downloads the 
> report and prints it to the preferred printer.
> Now my implementation problem is this:
> 1) If I implement the service as an hessian service, I can define clean 
> service methods (no user credentials are requested as parameters) but the 
> service will 
> remain tied to caucho (the service class can be only a caucho servlet, 
> since in methods I have to distinguish between users to transmit the right 
> reports).
> 2) If I don't want my service to be strongly tied to caucho the I have to 
> adopt the hiveremoting.caucho solution, but then I have to transimt 
> somehow the principal
> as method parameter. I also think that principal has to be validated at 
> each service call since it doesn't come from server side,.
> So I don't know what should be a better solution: caucho tiding or 
> Principal passed as parameter ? 
> Currently I've not been able to think to other possible solutions and I'm 
> actually more interested in the caucho heavy tie solution.
> I'd like to have some suggestion or opinion if possible.
> Thanks in advance,
> kiuma

View raw message