Rocky talks about the problem of duplicated business logic in a pure SOA design. This is an important conversation that must be had in order to make SOA a real life opportunity. Here are my thoughts on this.
Rocky refers right now to the validation rules that are the first and most likely candidates for duplication across layers (because layers can't trust each other).
One way to find a solution would be to look elsewhere in the software world to see where such duplication might occur, and how it is prevented there. A good place to start would be a windows domain with multiple servers and services, and a user identity. As a user, I'd like to just sign in to my machine and get all the services I need from my domain (email, domain shares, printing etc..) without needing to re-enter my password every time. I want it to be transparent. And it is. The interesting thing is that the identity validation scheme does not have much duplication in it. [putting it very very simply] There is one central repository handling authorization, and it gives out tokens verifying that the user's service is indeed who it says it is. This token is the entrance ticket for all services on the domain, so every service just needs to do one validation: "Is this token signed by my trusted partner?".
So what we have here is one trusted service inside a closed domain that is authorized to give away signed certificates for authorization. These certificates can be time bound too, and encrypted, and a whole lot of "safe" things. Taking this view into SOA we can perhaps think of something like this:
- In the GUI, the user inputs some data and presses submit.
- The web/winform application does basic validation of inputs. If validation succeeds, it requests a certificate of validation from a trusted validation service. This will be a certificate with a validation level of 1. The GUI will now call the workflow service along with the certificate.
- The workflow service will check to make sure the request contains the level > 1 certificate and if it does, passes the message on to the next service.
- Somewhere along the line, there might be a need to do more validation (deep logic validation and so on). At this point the service which is processing and does the new validation (which already assumed that level 1 validation has passed, so it does not repeat it) gets a new level 2 certificate from the validation server and passes the data on.
- At each point in time there are N certificates in the request (perhaps a combined certificate would be in order). These can be used to make sure validation does not need to occur.
- This approach means that some services require a validation certificate as part of their logical contract, and will fail if none is supplied. They will have no validation inside them that can be verified using an expected certificate.
Stuff to think about:
- Are we willing to add a little coupling to our design to remove duplication?
- Does coupling mean creating a trusted services domain? ("Service Garden"?)
- What does this mean for WS-Security and single sign on initiatives?