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 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
