The actions I listed were ones that should be taken by a service
provider, hence the comment about deploying on a platform that can
adjust to the unknown demand accordingly. I agree that, in general, a
service consumer should not have knowledge of the available capacity.
Their concern should be that the provider actually provides the agreed
level of availability (among other things) in the service contract.
-tb
Todd Biske
http://www.biske.com/blog/
Sent from my iPhone
On Mar 31, 2009, at 4:24 PM, Michael Poulin <[email protected]> wrote:
For last couple of years, after OASIS SOA RM identified service
description and service contract, I posted a few times (even in one
or two articles) the ideas very similar to Todd's ones. The only
difference is that I have recognised from the beginning that service
contract may be explicit and implicit. The former is a direct
agreement between two or more parties performed via negotiation. The
latter is agreement of one party with another party without
negotiation. Example of an implicit contract is a contract with
security service: if you disagree to use it, you do not get anywhere
close to the service.
For such cases, the only publicly available information about the
service is the service description. This document can play the role
of implicit contract for some types of services. It is usually known
up-front if a service description would be used as a service
contract, i.e. the description should be composed appropriately.
Certainly, there is no absolute anonymity. Services as normal
applications has to be protected from different types of attacks
based on the communication channels used in the service interfaces,
i.e. for Web-based interfaces - against Web and network attacks, for
IIOP -based interfaces - against network attacks, and so on.
I a little bit disagree with the words "The next thing you should do
is leverage a platform with elasticity. That is, the available
capacity should grow and shrink with the demand." Service consumers
(demand) do not know about "available capacity", but they do know
about availability. That is, a service can manage its availability
to the consumers while capacity of handling different levels of
availability is service internal thing. Nonetheless, I do understand
what Todd said and agree with him in this too.
- Michael
From: Gervas Douglas <[email protected]>
To: [email protected]
Sent: Tuesday, March 31, 2009 8:42:34 PM
Subject: [service-orientated-architecture] Todd on Governing
Anonymous Service Consumers
<<On Friday, the SOA Chief (Tim Vibbert), Brenda Michelson, 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 comp
liance with the policies contained within the service contract. Ther
ein lies the biggest problem: if the service consumer is anonymous,
is there a contract? There’s certainly the functional interface, whi
ch is part of the contract, but there isn’t any agreement on the all
owed 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 prop
osal, and the final contract is a negotiation between the two. The s
ame thing must be considered here. If someone starts using a service
, they have some implicit level of service that they expect to recei
ve. Likewise, the service provider knows both the capacity they curr
ently can handle as well as what how they think a typical consumer w
ill use the service. Unfortunately, these implied contracts can freq
uently be wrong. The advice here is that even if you are trying to l
ower the barrier for entry by having anonymous access, you still nee
d to think about service contracts and design to meet some base leve
l 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 anyth
ing 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 f
orm of identity on the message, even if there are no authentication
or authorization policies, becomes critical when you’re trying to un
derstand how the systems are interacting, perform capacity planning,
and especially in a troubleshooting scenario. Even services with lo
w 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 simp
ly by getting the URLs from someone else, you have no control over t
he rate at which usage will scale. If the implied level of availabil
ity is that the service is always available, you’ll need on-demand r
esources.
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
n; } #ygrp-msg p span { color: #1E66AE; font-weight: bold; }
div#ygrp-mlmsg #ygrp-msg p a span.yshortcuts { font-family: Verdana;
font-size: 10px; font-weight: normal; } #ygrp-msg p a { font-
family: Verdana; font-size: 10px; } #ygrp-mlmsg a { color:
#1E66AE; } div.attach-table div div a { text-decoration: none; }
div.attach-table { width: 400px; } -->
