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
----- Original Message -----
From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Tuesday, November 27, 2007 11:44 AM
Subject: Using security policies in the Bigbank scenario, was Re: Policy
Framework Scenarios.
Jean-Sebastien Delfino wrote:
[snip]
I'll propose a scenario in a separate email.
Here it goes:
- We have support for SCA security policies.
- We have a Bigbank application.
- A bank application should be secure.
Looks like a perfect fit to me.
Going through a real world like scenario and trying and showing how to use
SCA policies in an application like Bigbank will help our users understand
how to use policies. It will also help us improve what we have, mature our
policy story and provide feedback to the spec if necessary.
To make it real, I'd suggest to look at the Bigbank application and first
think about where it'll make business sense to apply authentication,
confidentiality, integrity or nothing.
To make the scenario a little more interesting we could split checking and
savings account management in two divisions of the Bank running different
composites. We'll then have to consider:
- exchanges within a department
- exchanges across departments
- exchanges with the outside world
...with different security requirements for each.
--
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]
