Thanks and point taken :). I am also comfortable with tinkering the runtime and extensions to make this scenario work. I'd rather take note of the gaps and discuss them to resolution in a wholistic manner.
- Venkat On Nov 30, 2007 11:50 PM, Raymond Feng <[EMAIL PROTECTED]> wrote: > 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] > >
