Hi,
I suggest that we not expand too quickly into other bindings such as RMI.
Let's focus on getting your previous proposal (StockQuote, AccountData
services) implemented first.
Thanks,
Raymond
----- Original Message -----
From: "Venkata Krishnan" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Friday, November 30, 2007 7:41 AM
Subject: Re: Using security policies in the Bigbank scenario, was Re: Policy
Framework Scenarios.
Hi,
Going ahead, I am starting with the calculator service. Since we have our
calculator service hosted as an rmi service, I have started to look into
how
security could be provided in an RMI Binding.
- Venkat
On Nov 30, 2007 1:17 PM, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
Hi,
Heres what I am intending to do for the secure-bigbank into which I have
copied over the exiting calculator, stockquote and account demos into
secure-bigbank...
- The Calculator and StockQuote services need to exchange data that
cannot
be tampered with since the AccountService heavily 'relies' on their
results. So interaction with these two services should have 'integrity'.
I
don't think there is a need for authentication or confidentiality for the
interactions with these services.
- The AccountData service is right now accessed only by the
AccountService. I'd like to open this out and put in the following
security
constraints :-
- just keep authentication when accessed from the AccoutService
locally say over binding.sca
- enforce authentication, confidentiality and integrity when
accessed from outside say over binding.ws
- Finally the AccountService should enforce authentication,
confidentiality and integrity.
Does this sound ok ?
After an iteration with interaction policies, I'll start working on some
implementation policies. For example having 'authorization' enforced on
the
AccountDataService's operations.
Thanks
- Venkat
On Nov 30, 2007 1:41 AM, Jean-Sebastien Delfino <[EMAIL PROTECTED]>
wrote:
> Raymond Feng wrote:
> > Hi,
> >
> > I propose to add the following to the BigBank scenario too to cover
> > transaction policies and JMS binding.
> >
> > 1) Have separate components to represent the SavingsAccountService
> > and
>
> > CheckingAccountService. The two services will be backed by two
> different
> > resource managers (Database or JMS queue). Please see the code at [1]
> > and diagrams at [2].
> >
> > 2) Add a TransferService to transfer money between accounts. The
> > operations will be executed in a global transaction.
> >
> > 3) The TransferService will be exposed over binding.jms. The request
> of
> > money transfer from the web front will be served by the
> TransferService
> > over JMS.
> >
> > [1]
> >
https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/transaction
>
> >
> > [2]
> >
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Transaction+Intents+and+Policies
>
> >
> >
> > Thanks,
> > Raymond
> >
>
> Sounds good to me. The other aspect that this scenario will allow us to
> explore is interaction between the JMS binding and databindings (as
> Bigbank flows complex types).
>
> I'd suggest to work on these two versions of Bigbank in parallel in
> different modules:
> a) secure bigbank with security policies
> b) reliable transfers with JMS and transactions
> i.e. two different copies of BigBank.
>
> And then bring the two together at some point later.
> --
> Jean-Sebastien
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
