You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by se...@bnpparibas.com on 2007/08/27 15:40:10 UTC
3 tier separation and Jetspeed services
Hi,
I am working in a web project in a company where security is really strict.
Web applications must have a clean 3 tier separation and the presentation
layer accessed by internet users have no direct access to the database.
Accesses to the database must be done by calling remotely the application
layer behind a firewall.
I was investigating how this could be implemented into Jetspeed and my
first idea was to use Spring Remoting. The simple HttpRemoteInvoker would
be my first choice since it demands no special ports else than HTTP.
My problem is that if I consider proxyfying all Jestpeed services that
access the database, I think I will get problems with transactional
propagation. From the Spring configuration files, some of the services
methods use transactional attribute "PROPAGATION_REQUIRED" witch means that
I can run into an already created transaction (created by an other
service?).
So, to help me on this task, I am asking you, the Jestpeed gurus, if there
is a right place where transactions starts and ends, something that I could
proxyfy with a remoting proxy. Are there few guidelines that you could
provide me to achieve this?
With your help, I am willing to implements some or all modifications that
could be necessary and will return the code to the project if you consider
it relevant.
I hope what I want to achieve is clear enough. Thanks for your help.
Regards,
Sebastien
This message and any attachments (the "message") is intended solely for the addressees and is confidential.
If you receive this message in error, please delete it and immediately notify the sender. Any use not in accord with
its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval.
The internet can not guarantee the integrity of this message.
BNP PARIBAS (and its subsidiaries) shall (will) not therefore be liable for the message if modified.
Do not print this message unless it is necessary, consider the environment.
---------------------------------------------
Ce message et toutes les pieces jointes (ci-apres le "message") sont etablis a l'intention exclusive de ses destinataires et sont confidentiels. Si vous recevez ce
message par erreur, merci de le detruire et d'en avertir immediatement l'expediteur.
Toute utilisation de ce message non conforme a sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite, sauf autorisation expresse.
L'internet ne permettant pas d'assurer l'integrite de ce message, BNP PARIBAS (et ses filiales) decline(nt) toute responsabilite au titre de ce message, dans l'hypothese ou il aurait ete modifie.
N'imprimez ce message que si necessaire, pensez a l'environnement.
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: 3 tier separation and Jetspeed services
Posted by David Sean Taylor <da...@bluesunrise.com>.
On Aug 27, 2007, at 6:40 AM, sebastien.doyon@bnpparibas.com wrote:
>
> Hi,
>
> I am working in a web project in a company where security is really
> strict.
> Web applications must have a clean 3 tier separation and the
> presentation
> layer accessed by internet users have no direct access to the
> database.
> Accesses to the database must be done by calling remotely the
> application
> layer behind a firewall.
>
> I was investigating how this could be implemented into Jetspeed and my
> first idea was to use Spring Remoting. The simple HttpRemoteInvoker
> would
> be my first choice since it demands no special ports else than HTTP.
>
> My problem is that if I consider proxyfying all Jestpeed services that
> access the database, I think I will get problems with transactional
> propagation. From the Spring configuration files, some of the services
> methods use transactional attribute "PROPAGATION_REQUIRED" witch
> means that
> I can run into an already created transaction (created by an other
> service?).
>
> So, to help me on this task, I am asking you, the Jestpeed gurus,
> if there
> is a right place where transactions starts and ends, something that
> I could
> proxyfy with a remoting proxy. Are there few guidelines that you could
> provide me to achieve this?
>
> With your help, I am willing to implements some or all
> modifications that
> could be necessary and will return the code to the project if you
> consider
> it relevant.
>
> I hope what I want to achieve is clear enough. Thanks for your help.
Were you planning on running the OJB-based Jetspeed services on a 3rd
tier, or writing your own services?
I don't think that HttpRemoteInvoker supports distributed
transactions. You may want to check and let us know
So you would have to somehow implement your own transactions
Take a look at transaction.xml:
<!-- Transaction manager for a single OJB PersistenceBroker
(alternative to JTA) -->
<bean id="transactionManager"
class="org.springframework.orm.ojb.PersistenceBrokerTransactionManager"/
>
Re: 3 tier separation and Jetspeed services
Posted by Aaron Evans <aa...@gmail.com>.
Wouldn't it just be enough to host the database on a different box and
put firewall rules between the jetspeed app server and the database?
If you want to take it a step further, put apache on a box in front of
your app server and put firewall rules between those as well.
On 8/27/07, sebastien.doyon@bnpparibas.com
<se...@bnpparibas.com> wrote:
>
> Hi,
>
> I am working in a web project in a company where security is really strict.
> Web applications must have a clean 3 tier separation and the presentation
> layer accessed by internet users have no direct access to the database.
> Accesses to the database must be done by calling remotely the application
> layer behind a firewall.
>
> I was investigating how this could be implemented into Jetspeed and my
> first idea was to use Spring Remoting. The simple HttpRemoteInvoker would
> be my first choice since it demands no special ports else than HTTP.
>
> My problem is that if I consider proxyfying all Jestpeed services that
> access the database, I think I will get problems with transactional
> propagation. From the Spring configuration files, some of the services
> methods use transactional attribute "PROPAGATION_REQUIRED" witch means that
> I can run into an already created transaction (created by an other
> service?).
>
> So, to help me on this task, I am asking you, the Jestpeed gurus, if there
> is a right place where transactions starts and ends, something that I could
> proxyfy with a remoting proxy. Are there few guidelines that you could
> provide me to achieve this?
>
> With your help, I am willing to implements some or all modifications that
> could be necessary and will return the code to the project if you consider
> it relevant.
>
> I hope what I want to achieve is clear enough. Thanks for your help.
>
> Regards,
>
> Sebastien
> This message and any attachments (the "message") is intended solely for the addressees and is confidential.
> If you receive this message in error, please delete it and immediately notify the sender. Any use not in accord with
> its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval.
> The internet can not guarantee the integrity of this message.
> BNP PARIBAS (and its subsidiaries) shall (will) not therefore be liable for the message if modified.
> Do not print this message unless it is necessary, consider the environment.
> ---------------------------------------------
> Ce message et toutes les pieces jointes (ci-apres le "message") sont etablis a l'intention exclusive de ses destinataires et sont confidentiels. Si vous recevez ce
> message par erreur, merci de le detruire et d'en avertir immediatement l'expediteur.
> Toute utilisation de ce message non conforme a sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite, sauf autorisation expresse.
> L'internet ne permettant pas d'assurer l'integrite de ce message, BNP PARIBAS (et ses filiales) decline(nt) toute responsabilite au titre de ce message, dans l'hypothese ou il aurait ete modifie.
> N'imprimez ce message que si necessaire, pensez a l'environnement.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org