A treatise on the Service Oriented Architecture.
This document is work in progress.
The term SOA is at a minimum a description for systems with functionality deployed to multiple services that may be invoked remotely. However, some users of the term intend a deeper meaning, that the services are web services and that they may be discovered dynamically because they publish information about themselves in a way that can be interrogated remotely. For this discussion the lighter definition is sufficient. The discussion covers several important features in the following sections.
Sharing information is essential in most systems, but also problematic. A prime candidate for a service is any functionality with the objective of controlling access to information there is only one instance of, typically serialising that access. The classic example of such a service is the DBMS.
A single host is usually the most efficient way to execute functionality because load distribution is no concern. Where failover is essential to guarantee continued availability of functionality, load can be balanced between service instances running on multiple hosts. Executing functionality as a service that can be replicated on multiple hosts is a good technique for failover provision.
Reducing complexity reduces risk and increases stability, enabling more ambitious systems to be created. Unfortunately, complexity is proportional to sophistication, because both are proportional to the amount of the three fundamental features of a system: functionality, information, interconnectedness. However, there are some forms of interconnectedness that are consequential to the evolution of technologies, programming languages and techniques that do not contribute to the sophistication of the system. They provide scope to reduce complexity and so increase sophistication. Of those SOA makes use of the concept of demarcation by objective and communication.
Clients and services are distinct islands of functionality that should have different objectives and require few, simple and narrow connections between them. This demarcation by objective and narrowness of interconnection reduces the potential for unintended side effects cascading through functionality. That in turn reduces overall complexity and so reduces risk without reducing sophistication. This demarcation by objective and communication into distinct functional units may however have a negative impact on performance because network communication is slower than communication within a single functional unit. The latter is an equally valid approach and is often practiced by creating classes with small interfaces. In effect the SOA functional uses the same concept but introduces it at a level where it may be executed in isolation, creating a functionality stability benefit to functionality with a distinct objective at the expense of communication performance.
The most important difference between a web service and a net service is that in a web service socket communication is handled by a web server, where in a net service socket communication is considerably less managed. There are advantages and disadvantages to each approach. The choice is then a matter of assessing the relative merits of each for any given set of requirements.
The web server introduces a number communication defaults which can either simplify or frustrate communication. Obviously they are intended to do the former and are tuned for typical web site use. As requirements deviate for the standard usage pattern of a web server the defaults tend to become more problematic. Net services are mostly agnostic providing few defaults because they provide little standard service functionality to default.
A well recognised encoding scheme from the W3C has been established for text communication over HTTP with web servers. No such encoding is incumbent on net services, although the same scheme and library utilities can be employed.
A number of communication encryption schemes exist and are implemented in various web servers. Unfortunately they are often non-trivial to use and well understood by the type of people that they are designed to protect against. If security is a major issue nothing is better than a well constructed bespoke encryption based around some good library code. If however, encryption requirements are not that stringent those provided by web servers are sufficient, but remember web servers are a popular target for those with malicious intent.
Standardisation is a good way to improve the development efficiency of products, but is only as good as it widely used. Use of web servers as a hub for invoking service functionality is now widespread and the details of the usage mechanisms are also become better standardised. However, there a range of popular web servers and the details of using each are still quite varied.
Clearly net services have the potential to provide the most efficient communication because of their minimalism. However, if a range of sophisticated features is required that are provided by a web server the differential benefit reduces. All other things being equal the communication efficiency of the net service will never be worse than that of the web service.
As there are no limitations and presumptions made by the net service it is always able to provide the more flexible solution.