Contention Management in the WSA

Hello, I subscribed to this list to address some issues observed in the
planning of the use of Web Services in the organization where I work.
I sent a few emails related to this issue to other places, without a
concrete response. I don't know if it's because my ignorance, my poor 
english explaining the problem, or the issue is really important but it's 
not addressed yet.
Finally I decided to subscribe to this mailing-list to post it here.


I read the whole Web Service Architecture Requirements and I will expose
te following things to argument about the necessity (IMHO) of Contention 
Management in the WSA:

- Scenario.
- A Possible Solution called Contention Management.
- Concrete technology solutions where I have or haven't Contention
Management.
- Contention in the WSA


SCENARIO

Players: Many big government organizations

(for example the Revenue Service, Intelligence Organizations, etc)

Description or Tale:

The different organizations has thousands of applications running, the
issue came when one organization needs data from another, sometimes one 
organization granted applications users for users on another oganization, 
but this wasn't a "pretty" solution, so all the Chiefs met together and all 
of them magically were speaking about the same solution: Web Services (and 
all of them bought a different IT magazine!)

The solution was to analyze all the requirements from one organization
to another and put a "web service frontend" to be the visible face of the 
organization. Each organization internally solved the web service logic to 
bring services to another one.

A lot of services were created for this purpose generating a lot of
transactions on a lot of different platforms.

But this new approach stalled practically one of the organizations,
because this new architecture propagates the web service request into
a lot of decentralized transactions on a lot of machines in a organization 
not ready or not planned for this new heavy load.



POSSIBLE SOLUTION

One approach or possible solution to this scenario is the feature called
"Contention Management", not the approach: "eat all while you can".

Using Contention Management you can size all your IT Infrastructure to
new needs, if your internal system doesn't support more than <k> 
transactions, then you can put on the queue the rest of it, solving it on 
chunks of <k>

This solution was not sense in the normal www world, where some user in
the world is the other peer, but in the
web services approach a (for example) batch process can wait the result
for a while.



CONCRETE TECHNOLOGY SOLUTIONS

Oddly I didn't see many real solutions glued to the web service world.

A very concrete commercial and good piece of software is BEA Tuxedo:  
http://www.bea.com/products/tuxedo/index.shtml

BEA has a product for the web services approach too.

But I didn't see (for example) Apache adding this features to the
Apache-httpd, so you can configure per "web service" a limit of requests and 
enqueueing the rest.
You can configure the MaxClients but it's a global configuration.



CONTENTION IN THE WSA

On AC006 in the requirements section I think it's important to add the
Contention Management approach.

On AR006.1: "the WG should consider the threat of Accessibility attacks
([D]DOS, DNS spoofing, etc.) in the
security framework", The [D]DoS or unintentionally [D]DoS may be the
consecuence if you have not a Contention Management, but I think it needs to 
be addressed explicitly as something like:

"The WS security framework should provide the ability to manage the
contention of each web service individually to maintain bounded the impact 
on the infrastructure on your organization"

I use the "Should" word because it's not applicable in all scenarios.


I will be very grateful to receive comments about this topic.


Thank You
Sebastian Wain

--
Sebastian Wain - http://swain.webframe.org




_________________________________________________________________
Unlimited Internet access -- and 2 months free!  Try MSN. 
http://resourcecenter.msn.com/access/plans/2monthsfree.asp

Received on Friday, 25 October 2002 11:22:06 UTC