Note: The title is *Web services* infrastructural considerations as opposed to SOA infrastructural considerations. Designing SOA would take a lot more consideration, this article should give you a head start for services exposed as web services within your SOA 

Of course you have to consider a lot of things when exposing a piece of functionality as a web service or as any service within soa for that matter. But today, I am going to focus on some system considerations only.

SQL attack

This problem is not specific to web services, this could occur even for any service implementation. SQL attack refers to the search criteria that result in a long running query (e.g. select *.* or select * from customer). It might be too late to implement a mechanism to detect a sql attack in the service implementation or persistence layer because by the time the service is invoked, the system may have unnecessarily parsed xml, logged the request, gone through a mediation, gone through some kind of transformation or even done a protocol switch.

Very large or hierarchical soap request

SOAP requests could get large - especially if the service allows any valid xml document to be embedded within the soap request. XML parser built into the web service container may perform poorly or even crash (especially when it is heavily loaded) if it has to parse a very large soap request. XML documents containing heavily convoluted hierarchies are also not recommended for the same reasons.

Large attachment

This is situation is similar to the one described above. A soap request with a large attachment increases the size of the message payload adding significant processing overhead and consuming a lot of bandwidth. Plus, parsing the separating out the attachment could become the bottleneck for the message flow within the system.

Repeated requests attempts

Some applications require the system to keep trying for certain time period or for several number of attempts if the first invocation fails. This especially happens in soap over jms environments. Such recurring attempts could slow down the service or could even bring down the server.

Too much reuse negatively impacting the SLAs

The soa approach often recommends implementing a business process by combining existing services. This means without a proper governance a service may be reused by many different clients negatively impacting the SLAs of the existing clients.

SOA infrastructure as the watchdog

A well conceived and well designed soa architecture provides infrastructure components to monitor and control the soa environment. Such monitoring may include: 

• inspecting soap requests for size and input parameters before delegating them to service providers
• redirecting requests with heavy resource requirements to dedicated service provider
• detecting failure and applying retry logic (e.g. retry only for certain types of failures)
• routing requests to appropriate geographic location (e.g. routing eastern customer request to the East service center to take advantage of data processing within LAN)
• and more...

Products aside, when introducing soa in an organization, the architect must consider,

• who is calling services
• what is the volume, type and frequency of data exchange among the services
• what SLA the services must support and how that resolves to the infrastructure requirements
• where things could go wrong and how they must be handled
• what are the routing requirements between service providers and service consumers