Before advent of SOA, enterprises opened up their central systems to a limited set of users, thru initiatives called 'Extranets'. The idea being stakeholders can have a limited visibility into workings of enterprises which would help them in their businesses, which in turn help the enterprise.
So this giant automobile company opened up its inventory to its distributors, and distributors could place orders for spare part based on inventory they saw. Soon the company realised that some distributors were misusing the facility to hoard critical spare parts when inventory was going low, and making extra buck by selling those parts to other distributors for a premium.
Company stopped this facility. To company's dismay some clever distributor found another way around. He started placing orders for ridiculously large number of parts, system started returning error response with a suggestion for maximum number he could order. The maximum number being level in inventory. This was worse than earlier situation. Not only distributor was getting the information he wanted, he was loading the central system unnecessarily - by continuously running this service for different parts and forcing error response.
Then because of some unrelated change, company stopped giving correct level of inventory in error response. So this distributor started making a lot of orders starting with a high number and gradually coming down to correct level, while doing a binary search. This was worse than earlier situation. It has started creating a lot of orders into system, which launched associated work-flows and then cancelling them - which launched even more work flows.
Till the last situation arose, the problem was handled as IT capacity problem and mis-deeds of distributors were not caught. The last hack tried by distributor nearly broke the back of central systems. Which launched massive investigation to uncover these mal-practices.
What has this got to do with SOA?
Well, one vision for SOA is that SOA can make enabling services available to consumers. Once consumers have enabling services available, consumers can compose the applications they need. Even if we keep aside the doubts about how does one define these enabling services, the issue of consumer intent is a big issue. It need not be always a malafide intent. Some consumer running an innocuous service, multiple time to get the data set he wants in order to do analysis he wants, can break the back of transactional systems. This has nothing to do with services policy. The consumer is willing to abide by policies set for the service, but his intent is not the one envisaged by service provider. And in this era of 2.0 this is bound to happen. SOA needs to take cognizance of this issue and handle it. No, CAPTCHAs are not a solution when services are meant for consumption by machines rather than humans.
Moral of this story is, in a true SOA, the architecture must
1. have a mechanism to diagnose violation of normal intent by consumers
2. provide alternate service implementations for genuine exceptional intent
3. provide a seamless switchover from normal intent to exceptional intent
4. provide incentives to promote normal intent and disincentives to reduce exceptional intent - when it makes sense to do so.
These are my thoughts about various issues faced by an enterprise architect.
Here you will find thoughts related to enterprise architecture, TOGAF, SOA, BPM, MDA, MDD, Web 2.0 etc.
Subscribe to:
Post Comments (Atom)
Friday, November 30, 2007
SOA Fable: Do you know the intent?
Before advent of SOA, enterprises opened up their central systems to a limited set of users, thru initiatives called 'Extranets'. The idea being stakeholders can have a limited visibility into workings of enterprises which would help them in their businesses, which in turn help the enterprise.
So this giant automobile company opened up its inventory to its distributors, and distributors could place orders for spare part based on inventory they saw. Soon the company realised that some distributors were misusing the facility to hoard critical spare parts when inventory was going low, and making extra buck by selling those parts to other distributors for a premium.
Company stopped this facility. To company's dismay some clever distributor found another way around. He started placing orders for ridiculously large number of parts, system started returning error response with a suggestion for maximum number he could order. The maximum number being level in inventory. This was worse than earlier situation. Not only distributor was getting the information he wanted, he was loading the central system unnecessarily - by continuously running this service for different parts and forcing error response.
Then because of some unrelated change, company stopped giving correct level of inventory in error response. So this distributor started making a lot of orders starting with a high number and gradually coming down to correct level, while doing a binary search. This was worse than earlier situation. It has started creating a lot of orders into system, which launched associated work-flows and then cancelling them - which launched even more work flows.
Till the last situation arose, the problem was handled as IT capacity problem and mis-deeds of distributors were not caught. The last hack tried by distributor nearly broke the back of central systems. Which launched massive investigation to uncover these mal-practices.
What has this got to do with SOA?
Well, one vision for SOA is that SOA can make enabling services available to consumers. Once consumers have enabling services available, consumers can compose the applications they need. Even if we keep aside the doubts about how does one define these enabling services, the issue of consumer intent is a big issue. It need not be always a malafide intent. Some consumer running an innocuous service, multiple time to get the data set he wants in order to do analysis he wants, can break the back of transactional systems. This has nothing to do with services policy. The consumer is willing to abide by policies set for the service, but his intent is not the one envisaged by service provider. And in this era of 2.0 this is bound to happen. SOA needs to take cognizance of this issue and handle it. No, CAPTCHAs are not a solution when services are meant for consumption by machines rather than humans.
Moral of this story is, in a true SOA, the architecture must
1. have a mechanism to diagnose violation of normal intent by consumers
2. provide alternate service implementations for genuine exceptional intent
3. provide a seamless switchover from normal intent to exceptional intent
4. provide incentives to promote normal intent and disincentives to reduce exceptional intent - when it makes sense to do so.
So this giant automobile company opened up its inventory to its distributors, and distributors could place orders for spare part based on inventory they saw. Soon the company realised that some distributors were misusing the facility to hoard critical spare parts when inventory was going low, and making extra buck by selling those parts to other distributors for a premium.
Company stopped this facility. To company's dismay some clever distributor found another way around. He started placing orders for ridiculously large number of parts, system started returning error response with a suggestion for maximum number he could order. The maximum number being level in inventory. This was worse than earlier situation. Not only distributor was getting the information he wanted, he was loading the central system unnecessarily - by continuously running this service for different parts and forcing error response.
Then because of some unrelated change, company stopped giving correct level of inventory in error response. So this distributor started making a lot of orders starting with a high number and gradually coming down to correct level, while doing a binary search. This was worse than earlier situation. It has started creating a lot of orders into system, which launched associated work-flows and then cancelling them - which launched even more work flows.
Till the last situation arose, the problem was handled as IT capacity problem and mis-deeds of distributors were not caught. The last hack tried by distributor nearly broke the back of central systems. Which launched massive investigation to uncover these mal-practices.
What has this got to do with SOA?
Well, one vision for SOA is that SOA can make enabling services available to consumers. Once consumers have enabling services available, consumers can compose the applications they need. Even if we keep aside the doubts about how does one define these enabling services, the issue of consumer intent is a big issue. It need not be always a malafide intent. Some consumer running an innocuous service, multiple time to get the data set he wants in order to do analysis he wants, can break the back of transactional systems. This has nothing to do with services policy. The consumer is willing to abide by policies set for the service, but his intent is not the one envisaged by service provider. And in this era of 2.0 this is bound to happen. SOA needs to take cognizance of this issue and handle it. No, CAPTCHAs are not a solution when services are meant for consumption by machines rather than humans.
Moral of this story is, in a true SOA, the architecture must
1. have a mechanism to diagnose violation of normal intent by consumers
2. provide alternate service implementations for genuine exceptional intent
3. provide a seamless switchover from normal intent to exceptional intent
4. provide incentives to promote normal intent and disincentives to reduce exceptional intent - when it makes sense to do so.
2 comments:
-
Todd Biske said...
-
Great story Vilas. It also demonstrates the need for a formal contract between service consumer and service provider that is more than just the functional interface, but instead includes information on expected/allowed usage, for example. Interestingly, in these B2B scenarios, there should be a direct relationship between the legal contract that governs the relationship between supplier and distributor and the service contract the governs the technical interaction.
-
9:56 PM
-
Vilas said...
-
Agreed. This story is about outright malafide intent. But there are usage intent which appear legit, but cause havoc for supplier. In normal enterprise IT , this would be your worst case capacity problem. Occurs only when you hit a demand spike, you just take it on chin and bear it. But in 2.0 world it may happen frequently and cause more problems. A IT solution to handle this would be a necessity in 2.0 world, is my take. On demand capacity expansion, and license on use of capacity kind of models may help. These are not mainstream in enterprises yet. More of dot com solutions are in order.
-
9:47 PM
Subscribe to:
Post Comments (Atom)
2 comments:
Great story Vilas. It also demonstrates the need for a formal contract between service consumer and service provider that is more than just the functional interface, but instead includes information on expected/allowed usage, for example. Interestingly, in these B2B scenarios, there should be a direct relationship between the legal contract that governs the relationship between supplier and distributor and the service contract the governs the technical interaction.
Agreed. This story is about outright malafide intent. But there are usage intent which appear legit, but cause havoc for supplier. In normal enterprise IT , this would be your worst case capacity problem. Occurs only when you hit a demand spike, you just take it on chin and bear it. But in 2.0 world it may happen frequently and cause more problems. A IT solution to handle this would be a necessity in 2.0 world, is my take. On demand capacity expansion, and license on use of capacity kind of models may help. These are not mainstream in enterprises yet. More of dot com solutions are in order.
Post a Comment