This post originated from an RSS feed registered with .NET Buzz
by Roy Osherove.
Original Post: Some thoughts on logic duplication in SOA design
Feed Title: ISerializable
Feed URL: http://www.asp.net/err404.htm?aspxerrorpath=/rosherove/Rss.aspx
Feed Description: Roy Osherove's persistent thoughts
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?
Previous Topic
