<<On Friday, the SOA Chief <http://www.ebizq.net/blogs/itgumbo/soachief>
(Tim Vibbert), Brenda Michelson <http://www.elementallinks.com>, and I
had a conversation on Twitter regarding SOA governance and anonymous
service consumers. Specifically, how do you provide run-time governance
for a service that is accessed anonymously?
If you've read this blog or my book, you'll know that my take on
run-time SOA governance is the enforcement and/or monitoring of
compliance with the policies contained within the service contract.
Therein lies the biggest problem: if the service consumer is anonymous,
is there a contract? There's certainly the functional interface, which
is part of the contract, but there isn't any agreement on the allowed
request rates, hours of usage, etc. So what do we do?
The first thing to recognize is that while there may not be a formal
contract that all consumers have agreed to, there should always be an
implied contract. When two parties come to the table to establish an
agreement, it's likely that both sides comes with a contract proposal,
and the final contract is a negotiation between the two. The same thing
must be considered here. If someone starts using a service, they have
some implicit level of service that they expect to receive. Likewise,
the service provider knows both the capacity they currently can handle
as well as what how they think a typical consumer will use the service.
Unfortunately, these implied contracts can frequently be wrong. The
advice here is that even if you are trying to lower the barrier for
entry by having anonymous access, you still need to think about service
contracts and design to meet some base level of availability.
The second thing to do, which may seem obvious, is to avoid anonymous
access in the first place. It's very hard to enforce anything when you
don't know where it's coming from. Your authorization policy can simply
be that you must be an authenticated user to use the service. Even in an
internal setting, having some form of identity on the message, even if
there are no authentication or authorization policies, becomes critical
when you're trying to understand how the systems are interacting,
perform capacity planning, and especially in a troubleshooting scenario.
Even services with low barriers to entry, like the Twitter API, often
require identity.
The next thing you should do is leverage a platform with elasticity.
That is, the available capacity should grow and shrink with the demand.
If it's anonymous, and new consumers can start using it simply by
getting the URLs from someone else, you have no control over the rate at
which usage will scale. If the implied level of availability is that the
service is always available, you'll need on-demand resources.
Finally, you still need to protect your systems. No request is
completely anonymous, and there are things you can do to ensure the
availability of your service against rogue consumers. Requests will have
source IP addresses on them, so you can look for bad behavior at that
level. You can still do schema validation, look for SQL injection, etc.
In other words, you still need to do DoS protection. You also should be
looking at the usage metrics on a frequent basis to understand the
demand curve, and making decisions accordingly.>>
You can find Todd's blog at: http://www.biske.com/blog/
Gervas
