news / tech talk

At a certain level of corporate business, the concept of Service Oriented Architecture (SOA) has enjoyed buzzword popularity. The common definition of SOA is a design pattern that is based on loosely coupled services and relationships between producers and consumers. The concept of SOA is not based on any particular technology but simply the idea that certain kinds of services are required and various types of consumers need those services. It is vaguely akin to software module re-use in that the theory is that if you develop useful services in a loosely coupled framework, then other service modules or direct consumers can use the service for many purposes without having to re-write or even re-implement the service repeatedly. That should make things more efficient and protect the integrity of basic data since there are common ways to access it and even change it.

For the technical-minded, this SOA interaction will sound like an Application Programming Interface (API) in software development terms. An API is an interface that supports communications from a “black box” system to the outside world for a defined set of parameters. However, a SOA consists of a larger model than an API is intended to handle, it includes a universal registry of available services as well as service definitions. The intent is to provide a big catalog of services to be automatically searched and understood by consumers, consumer avatars, or other services. Again, the loose coupling is intended to provide a highly flexible system of services that lives by changing, growing, and even eliminating old or un-used services.

Note that I am careful to use words like “should” and “is intended to” when discussing SOA. I take a pragmatic view of technology. The SOA concept is interesting but the implementation tends to be complex and there are some fundamental issues with a universal catalog that I cannot place much faith in at this point. Regarding the implementation, remember that SOA relies on a “black box” approach to the particular service provided so it that it does not matter what technology or technologies are being used under the covers, only that services are provided in a very defined way. That “defined way” is typically through an explicit XML schema that must be shared between loosely coupled objects. Detailed XML-based definitions of anything non-trivial tend to be rather slow to parse and work with compared to binary interfaces. To combat this issue, technologies are evolving to convert XML into a binary form for faster interaction. However, the basic issue is that making a system work in this fashion requires several layers of abstraction, and each of these layers of abstraction consists of applied technologies themselves. This creates an overall system that was meant to simplify data transfer through common services but which must be built on several complex layers of abstraction to achieve. It is also dependent on careful maintenance of the registration catalog. The catalog must provide exactly what services are available, what they provide, and how to access them including what security parameters (if any) are required.

In software development, it is usually the case that to develop something to be “re-useable” requires much greater development time. So, one must be careful in considering the expenditure of time and effort for re-use versus the speed and simplicity of writing for the task at hand; in other words, the return on the investment. Keep that in mind when considering the dedication of resources to a full-on SOA project as opposed to less grandiose alternatives like specific web services for specific purposes.

Lee Le Clair is the CTO at Ephibian. His Tech Talk column appears the third week of each month in Inside Tucson Business