Mailing-List: contact tuscany-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: tuscany-dev@ws.apache.org
Received-SPF: pass (athena.apache.org: domain of for.svkrish@gmail.com
 designates 209.85.146.183 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=cuG3QzC+OGSq7TBsAVOaphKASTai0GO9T1YiwPxdWvT3rNx4FxaZkdG0IUPh46AxoyPqiD5CFsR0uxiaKckOQ0riVgUXC68gfsWpVnYDZNWAmCM2PHShyVkWv55RZZCh0TU4/dDZEiPAcVbiQOjFnHYrsyP4Q9/moLvh0i2/A2c=
Message-ID: <33e260400712010217j42543b76wde614b1307631406@mail.gmail.com>
Date: Sat, 1 Dec 2007 15:47:49 +0530
From: "Venkata Krishnan" <for.svkrish@gmail.com>
To: tuscany-dev@ws.apache.org
Subject: Re: Using security policies in the Bigbank scenario,
 was Re: Policy Framework Scenarios.
In-Reply-To: <008f01c8337d$b0633780$28584c09@rfengt60p>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_3812_18976029.1196504269773"
References: <33e260400711260251m78aa11e0xd1a4e9c675e89806@mail.gmail.com>
	 <474C6E20.2070309@apache.org> <474C73B8.2050706@apache.org>
	 <001801c832ac$b3e433e0$7cb14109@rfengt60p>
	 <474F1CD8.3060207@apache.org>
	 <33e260400711292347w2299865fraab075146bb42396@mail.gmail.com>
	 <33e260400711300741t4081d177r77fb92845609ce11@mail.gmail.com>
	 <008f01c8337d$b0633780$28584c09@rfengt60p>

------=_Part_3812_18976029.1196504269773
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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 <enjoyjava@gmail.com> 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" <for.svkrish@gmail.com>
> To: <tuscany-dev@ws.apache.org>
> 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 <for.svkrish@gmail.com> 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 <jsdelfino@apache.org>
> >> 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: tuscany-dev-unsubscribe@ws.apache.org
> >> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >> >
> >> >
> >>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>

------=_Part_3812_18976029.1196504269773--