Before we can begin exploring the details of service-oriented computing or service-oriented architecture – SOA, we first need to establish some basic design terminology. The books in this series use a common vocabulary comprised of the following design-related terms:
– Design Characteristic
– Design Principle
– Design Paradigm
– Design Pattern
– Design Standard
– Best Practice
Depending on your sources, you will find differing definitions for these terms. More often than not, though, you will notice that they all are somewhat intertwined. The upcoming pages explain each term and the following figure illustrates how they inter-relate.
Design Characteristic in SOA
A characteristic of something is simply an attribute or quality. An automated business solution will have numerous unique characteristics that were established during its initial design. Hence, the type of design characteristic we are interested in is a specific attribute or quality of a body of solution logic that we document in a design specification and plan to realize in development.
Figure: In this simple example, three distinct application designs (A, B, C) are established, each with its own distinct list of design characteristics. We will continue to reference these applications in the upcoming pages. (Note that the small squares represent units of solution logic, solid arrows represent reuse or shared access, and dashed arrows represent state data transfer.)
Service-orientation emphasizes the creation of very specific design characteristics, while also de-emphasizing others. It is important to note that almost every design characteristic we explore is attainable to a certain measure. This means that it is generally not about whether solution logic does or does not have a certain characteristic; it is almost always about the extent to which a characteristic can or should be realized.
Although each system can have its own unique characteristics, we are primarily interested in establishing common design characteristics. Increased commonality ensures an increased degree of consistency, making different kinds of solution logic more alike. When things are more alike they become more predictable. In the world of distributed, shareable logic, predictability is a good thing. Predictable design characteristics lead to predictable behavior. This, in turn, leads to increased reliability and the opportunity to leverage solution logic in many different ways.
Much of service-orientation is dedicated to providing a means of establishing a specific collection of design characteristics that spread consistency, predictability, and reliability on many levels and for different purposes.
Design Principle in SOA
A principle is a generalized, accepted industry practice. In other words, it’s something others are doing or promoting in association with a common objective. You can compare a principle with a best practice, in that both propose a means of accomplishing something based on past experience or industry-wide acceptance.
When it comes to building solutions, a design principle represents a highly recommended guideline for shaping solution logic in a certain way and with certain goals in mind. These goals are usually associated with establishing one or more specific design characteristics (as a result of applying the principle).
Figure: The repeated application of design principles increases the amount of common design characteristics. In this case, the coupling between solution logic units A and B has been loosened (as indicated by a reduction of connection points).
For example, we can have a principle as fundamental as one that states that solution logic should be distributable. Applying this principle results in the solution logic being partitioned into individually distributable units. This then establishes the distinct design characteristic of the solution logic becoming componentized. This is not only an example of a very broad design principle, it is also the starting point for service-orientation.
The eight design principles documented in SOA: Principles of Service Design provide rules and guidelines that help determine exactly how solution logic should be decomposed and shaped into distributable units. A study of these principles further reveals what design characteristics these units should have to be classified as “quality” services capable of fulfilling the vision and goals associated with SOA and service-oriented computing.
Design Paradigm in SOA
There are many meanings associated with the term “paradigm.” It can be an approach to something, a school of thought regarding something, or a combined set of rules that are applied within a predefined boundary.
A design paradigm within the context of business automation is generally considered a governing approach to designing solution logic. It normally consists of a set of complementary rules or principles that collectively define the overarching approach represented by the paradigm.
Figure: Because a design paradigm represents a collection of design principles, it further increases the degree of commonality across different bodies of solution logic. In the example, the amount of reuse in A and B has increased.
Object-orientation (or object-oriented design) is a classic example of an accepted design paradigm. It provides a set of principles that shape componentized solution logic in certain ways so as to fulfill a specific set of goals.
Along those very same lines, service-orientation represents its own distinct design paradigm. Like object-orientation, it is a paradigm that applies to distributed solution logic. However, its principles differ from those associated with object-orientation, which results in the creation of different types of design characteristics.
Note that the service-orientation design paradigm is documented separately at www.soaprinciples.com.
Design Pattern in SOA
We’ve established that service-orientation is a design paradigm comprised of a set of design principles, each of which provides a generalized rule or guideline for realizing certain design characteristics. The paradigm itself sounds pretty complete, and it actually is. However, to successfully apply it in the real world requires more than just a theoretical understanding of its principles.
Service designers will be regularly faced with obstacles and challenges when attempting to apply a design paradigm in the real world. This is because the realization of desired design characteristics is frequently complicated by various factors, including:
– Constraints imposed by the technology being used to build and/or host the units of solution logic.
– Constraints imposed by technology or systems that reside alongside the deployed units of solution logic.
– Constraints imposed by the requirements and priorities of the project delivering the units of solution logic.
A design pattern describes a common problem and provides a corresponding solution. It essentially documents the solution in a generic template format so that it can be repeatedly applied. Knowledge of design patterns not only arms you with an understanding of the potential problems designs may be subjected to, it provides answers as to how these problems are best dealt with.
Figure: Patterns provide recommended solutions for common design problems. In this simplified example, a pattern suggests we reduce external access to a database to increase application autonomy.
Design patterns are born out of experience. Pioneers in any field had to undergo cycles of trial and error and by learning from what didn’t work, approaches that finally did achieve their goals were developed. When a problem and its corresponding solution were identified as sufficiently common, the basis of a design pattern was formed. Design patterns can be further combined into compound patterns that solve larger problems and a series of patterns can form the basis of a pattern language, as explained next.
Design Standard in SOA
For an organization to successfully apply a design paradigm, it will require more than an adherence to the associated design principles and a knowledge of supporting design patterns. Every organization will have unique strategic goals and unique enterprise environments. These form a distinct set of requirements and constraints that need to be accommodated within solution designs.
Design standards are (usually mandatory) design conventions customized to consistently pre-determine solution design characteristics in support of organizational goals and optimized for specific enterprise environments. It is through the use of internal design standards that organizations can consistently deliver solutions tailored to their environments, resources, goals, and priorities.
As with design principles, the application of design standards results in the creation of specific design characteristics. As with design patterns, design standards foster and refine these characteristics to avoid potential problems and strengthen the overall solution design. In fact, it is recommended for design standards to be based upon or even derived from industry design principles and patterns.
Figure: In this case, a design standard requires that C’s original design be altered to remove access to a shared, external state database.
Can you have design standards without design principles? Yes, it is actually common to have many design standards. Only some may need to relate back to principles in order to see through the application of the overall design paradigm. Different design standards may also be created to simply support other goals or compensate for constraints imposed by specific environmental, cultural, or technology-related factors. Although some standards may have no direct association with accepted design principles, there should always be an effort to keep all standards in relative alignment.
Can you have design principles without design standards? It usually depends on how committed an organization is to the governing design paradigm. If it sees potential in only using a subset of the paradigm’s principles, then some principles may not be supported by corresponding design standards. However, this approach is not common. Essentially, as with design principles, through standardization we want to build consistency into specific design characteristics – consistency in the quality of the characteristics and in how frequently they are implemented.
Note that one point of clarification worth making when discussing standards is the difference between design standards and industry standards. The former, as we just described, refers to internal or custom standards that apply to the design of solution logic and systems for a particular enterprise. The latter generally represents open technology standards, such as those that comprise the XML and Web services platforms.
Sometimes organizations assume that if they use industry standards they will end up with a standardized IT enterprise. While those XML and Web services specifications that have become ratified and accepted industry standards do establish a level of technology standardization, it is still up to an organization to consistently position and apply these technologies. Without design standards, industry standards can easily fail in achieving their potential.
SOA Best Practice
A best practice is generally considered a technique or approach to solving or preventing certain problems. It is usually a practice that has industry recognition and has emerged from past industry experience.
How then is a best practice differentiated from a design principle? In this book we make a clear distinction in that a design principle is limited to design only. A best practice can relate to anything from project delivery to organizational issues, governance, or process. A design principle could be considered a best practice associated only with solution design.
Note: These definition were copied from www.SOAGlossary.com.