I asked some folks in my talk before the US Partner Senior Architects Summit yesterday if they had created services that no one used.  Not surprisingly, some hands went up.  One architect piped up with this “I’ve seen a service that was used improperly and it brought down the enterprise.”

Um, OK.  Sure.  I can write a service badly.  I’m sure you can too, without much effort.

Some folks would say “that’s why we need SOA Runtime Management Tools!” 

Bunk.

Every app is completely responsible for protecting itself. 

Whether it is from a Denial of Service Attack to the web site, or an attempt at unauthorized access to the data, or an improper use of the service interface, apps must manage their own stability.  We need to realize that a service has the same flaws and foibles as any app.  It can be used.  It can be misused.

Plenty of ways to solve for this.  A subset, off the top of my head:

  • test the heck out of your service interface.  Testing is our friend.
  • configure for DoS attacks against the service interface
  • use intermediaries that support throttling, so that you can manage the inbound traffic
  • secure the interface, so that only members of known groups or even specific system accounts, have actual access.
  • don’t advertise.  Don’t flag your ‘service’ entry in the repository as ‘public’ or ‘feely callable’ if you aren’t. 

That is not a SOA Governance problem.  This is a training problem.