SOA Antipatterns

The following subsections explore some SOA thinking that should be avoided.

SOA Is Everything. Infrastructure Is Nothing.

An SOA of any sort a generic SOA or Web services runs on the network and is hosted on servers. For an SOA to work, you need the following:

• Sufficient network bandwidth to provide adequate throughput.

• Redundant network connections to increase availability.

• Dedicated machines (Hardware that is hosting mission critical components should be used for that purpose and that purpose only. In addition, this hardware should be totally under the control of the people responsible for the service SLA. If that is not possible, then the group providing the hardware should agree to SLAs that are at least as restrictive as the SLA that pertains to the service that is being run on those machines.

Every increase in the size and complexity of the SOA should come with the dollars to beef up the infrastructure.

Web Services Are All We Need to Know About SOA

Web services are a very important SOA implementation and will be the preferred method of business-to-business interoperability. However, as discussed previously, Web services have limitations and are, in many cases, a less-than-optimal method of providing services. In most cases, enterprises that take the time and make the effort to build their own SOAs on the plans laid down by the generic SOA implementation will have SOAs that are much better fits for the totality of their needs.

Web service RAD tools are a particular nuisance. Some maverick downloads a Web services development tool and suddenly a manager is informing the architecture team that the company already has Web services. The manager's group has built five and has eight more ready to come online. Rogue Web service development must be squashed quickly and ruthlessly.

This is otherwise known as the service junk drawer.

SOA Is About Technology

UDDI and SOAP, HTTP and WSDL: This is what SOA is about. Wrong! SOA is about architecture. SOA incorporates many of the best practices of business and enterprise architecture and modeling.

Everything Is a Service

This stems from the concept that more is better. If one service is good, a hundred is better, and a thousand even better. Not exactly.

Development of an SOA should proceed from business priorities and fit into a well-thought-out architecture. As part of that thinking, you must ask the following questions:

• Can we stand the performance hit that will come from having this functionality accessed via a distributed connection? In the case of Web services, the performance issue will have to be looked at with particular care.

• What are the security implications of plugging this into the network? In the case of Web services, what are the security implications of opening this application to the world?

• Is our infrastructure capable of handling this extra load?

• How are we going to manage this service?

SOA strategies have a great advantage in that services can be brought online in a series of small, three- to six-month projects, rather than requiring one huge effort. The ease of adding services should not blind you to the fact that the architecture is everything. Every service development project should be based on sound business thinking, compliance to the desired future state of the enterprise architecture and leverage the best practices of software architecture.