You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@hivemind.apache.org by Andrea Chiumenti <ki...@gmail.com> on 2005/09/11 19:25:34 UTC
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
Re: suggestion request!
Posted by Andrea Chiumenti <ki...@gmail.com>.
Jean-Francois,
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,
kiuma
On 9/12/05, Jean-Francois Poilpret <jf...@hcm.vnn.vn> 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 [mailto:kiuma72@gmail.com]
> *Sent:* Monday, September 12, 2005 1:07 PM
> *To:* hivemind-user@jakarta.apache.org
> *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* <jf...@hcm.vnn.vn> 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 [mailto:kiuma72@gmail.com]
> *Sent:* Monday, September 12, 2005 12:26 AM
> *To:* hivemind-user@jakarta.apache.org
> *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
>
>
RE: suggestion request!
Posted by Jean-Francois Poilpret <jf...@hcm.vnn.vn>.
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
work:-( (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 [mailto:kiuma72@gmail.com]
Sent: Monday, September 12, 2005 1:07 PM
To: hivemind-user@jakarta.apache.org
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 <jf...@hcm.vnn.vn> 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 [mailto:kiuma72@gmail.com]
Sent: Monday, September 12, 2005 12:26 AM
To: hivemind-user@jakarta.apache.org
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
Re: suggestion request!
Posted by Andrea Chiumenti <ki...@gmail.com>.
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 <jf...@hcm.vnn.vn> 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 [mailto:kiuma72@gmail.com]
> *Sent:* Monday, September 12, 2005 12:26 AM
> *To:* hivemind-user@jakarta.apache.org
> *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
>
RE: suggestion request!
Posted by Jean-Francois Poilpret <jf...@hcm.vnn.vn>.
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 [mailto:kiuma72@gmail.com]
Sent: Monday, September 12, 2005 12:26 AM
To: hivemind-user@jakarta.apache.org
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