This is the second post in my series about Service Oriented Architecture. After defining what SOA is in my first post, I will discuss the common characteristics of service-oriented solutions:
SOA is fundamentally autonomous
The service-oriented principle of autonomy requires that individual services be as independent and self-contained as possible with respect to the control they maintain over their underlying logic. This is further realized through message-level autonomy where messages passed between services are sufficiently intelligence-heavy that they can control the manner in which they are processed by recipient service.
SOA builds upon and expands this principle by promoting the concepts of autonomy throughout solution environments and the enterprise. Applications comprised of autonomous services, for example, can themselves be viewed as composite, self-reliant services that exercise their own self-governance within service oriented integration environments.
SOA is based on open standards
Perhaps the most significant characteristic of Web Services is the fact that the data exchange is governed by open standards. After a message is sent from one Web Service to another it travels via a set of protocols that is globally standardized and accepted.
Further, the message itself is standardized, both in format and how it represents its payload. The use of SOAP, WSDL, XML and XML Schema allow for messages to be fully self-contained and support the underlying agreement that to communicate, services require nothing more than knowledge of each other’s service description. The use of open, standardized messaging model eliminates the need for the underlying service logic to share dependencies (such as type systems) and support the loosely coupled paradigm.
SOA supports vendor diversity
The open communications standards just explained not only has significant impact for bridging much of the heterogeneity within (and between) corporations, but it also allows organizations to choose best-of-breed environments for specific applications.
For example, regardless of how proprietary a development environment is, as long as it supports the creation of standard Web Services, it can be used to create a non-proprietary service interface layer, opening up interoperability opportunities with other, service capable applications. This, incidentally, has changed the face of integration architectures, which now can encapsulate legacy logic through service adapters, and leverage middleware advancements based on Web Services.
Organizations can certainly continue building solutions with existing development tools and server products. In fact, it may make sense to do so, only to continue leveraging the skill sets of in-house resources. This option is made possible by the open technology provided by Web Services framework and is made more attainable through the standardization and principles introduced by SOA.
SOA promotes discovery
Even though the first generation of Web Services standards included UDDI, few of the early implementations actually used service registries as part of their environments. This may have to do with the fact that not enough Web Services were actually built to warrant a registry. However, another likely reason is that the concept of service discovery was simply not designed into the architecture. When utilized within traditional distributed architectures, Web Services were more often employed to facilitate point-to-point solutions. Therefore, discovery was not a common concern.
SOA supports and encourages the advertisement and discovery of services throughout the enterprise and beyond. A serious SOA will likely rely on some form of service registry or directory to manage service descriptions.
SOA fosters intrinsic interoperability
Further leveraging and supporting the required usage of open standards, a vendor diverse environment, and the availability of a discovery mechanism, is the concept of intrinsic interoperability. Regardless of whether an application actually has immediate integration requirements, design principles can be applied to outfit services with characteristic that naturally promote interoperability.
When building a service-oriented application from the ground up, services with intrinsic interoperability become potential integration endpoints. When properly standardized, this leads to service-oriented integration architectures wherein solutions themselves alleviate the cost and effort of fulfilling future cross-application integration requirements, and evolves the enterprise into one where traditional application boundaries begin to disappear.
SOA fosters inherent reusability
SOA establishes an environment that promotes reuse on many levels. For example, services designed according to service-orientation principles are encouraged to promote reuse, even if no immediate reuse requirements exist. Collections of services that form service compositions can themselves be reused by larger compositions.
The emphasis placed by SOA on the creation of services that are agnostic to both the business process and the automation solutions that utilize them leads to an environment in which reuse is naturally realized as a side benefit to delivering services for a given project.
SOA emphasizes extensibility
When expressing encapsulated functionality through a service description, SOA encourages you to think beyond immediate, point-to-point communication requirements. When service logic is properly partitioned via an appropriate level of interface granularity, the scope of functionality offered by a service can sometimes be extended without breaking the established interface.
Extensibility is also a characteristic that is promoted throughout SOA as a whole. Extending entire solutions can be accomplished by adding services or by merging with other service-oriented applications (which also, effectively, “adds services). Because the loosely coupled relationship fostered among all services minimize inter-service dependencies, extending logic can be achieved with significantly less impact.
SOA implements layers of abstraction
One of the characteristics that tend to evolve naturally through the application of service-orientation design principles is that of abstraction. Typically SOAs can introduce layers of abstraction by positioning services as the sole access points to a variety of resources and processing logic.
When applied through proper design, abstraction can be targeted at business and application logic. For example, by establishing a layer of endpoints that represent entire solutions and technology platforms, all of the proprietary details associated with these environments disappear. The only remaining concern is the functionality offered via the service interfaces.
SOA is a building block
Service-oriented application architecture will likely be one of several within an organization committed to SOA as the standard architectural platform. Organizations standardized on SOA work toward an ideal known as the service-oriented enterprise (SOE), where all business processes are composed of and exist as services, both logically and physically.
When viewed in the context of SOE, the functionality boundary of an SOA represents a part of this future-state environment, either as a standalone unit of business automation or as a service encapsulating some or all of the business automation. In responding to business model-level changes, SOAs can be augmented to change to nature of their automation, or they can be pulled into service-oriented integration architectures that require the participation of multiple applications.
What this all boils down to is that an individual service-oriented application can, in its entirety, be represented by and modeled as a single service. There are no limits to the scope of service encapsulation. An SOA consists of services within services within services, to the point that a solution based on SOA itself is one of many services within SOE.
SOA is an evolution
SOA defines an architecture that is related to but still distinct from its predecessors. It differs from traditional client-server and distributed environments in that it is heavily influenced by the concepts and principles associated with service-orientation and Web Services. It is similar to previous platforms in that it preserves the successful characteristics of its predecessors and builds upon them with distinct design patterns and a new technology set.
For example, SOA supports and promotes reuse and encapsulation, as well as the componentization and distribution of application logic. These and other established design principles that are commonplace in traditional distributed environments are still very much part of SOA.
SOA is still maturing
While the characteristics described so far are fundamental to SOA, this point is obviously more of a subjective statement of where SOA is at the moment. Even though SOA is being positioned as the next standard application computing platform, this transition is not yet complete. Despite the fact that Web Services are being used to implement a great deal of application functionality, the support for a number of features necessary for enterprise-level computing is not yet fully available.
Standards organizations and major software vendors have produced many specifications to address a variety of supplementary extensions. Additionally, the next generation of development tools and application servers promises to support a great deal of these new technologies. When SOA platforms and tools reach an adequate level of maturity, the utilization of Web Services can be extended to support the creation of enterprise solutions, making the ideal of a service-oriented enterprise attainable.
If you need to provide an accurate definition of SOA today, you would not be out of line to mention the state of its underlying technology. Considering the rate at which the IT industry as a whole is adopting and evolving the SOA platform, though, it should not be too long before such a statement would no longer be required.
