Preface
Arguably, distributed computing is the most complex concept in computer science. The practical realization of this concept in the form of service-oriented computing further adds to this complexity. Generally, there are two reasons: firstly, because of a compound architectural approach, SOA is based on already complex techniques, and secondly, to stay on the cutting edge of computing technology, SOA must appeal to non-IT businesses to be successfully adopted in modern enterprises. To achieve this goal of successful adoption, SOA architects must combine a vendor-neutral approach to systems design with a deep knowledge of platforms on which the solution will be realized. This combination will allow service-oriented solutions to be flexible and resilient at the same time.
Maintaining the right balance of these two success factors is quite a challenge in the multilayered, multiframework, and compound environments of SOA. Since there are several success factors with a magnitude of problems associated with their implementation, SOA adoption requires a structural and pattern-based approach. In this book, our task is a practical demonstration of pattern-oriented problem solving based on the concrete implementation of service collaboration and integration systems in different industries (telecom, shipping, and logistics). The book goes for the most complex and, at the same time, the most common use cases. Conceivably, the most challenging problems in SOA are related to dynamic service compositions, usually assembled on runtime and in a business-agnostic way. This is the ultimate realization of the SOA Composability principle. This principle is, in turn, the foundation of the main service-orientation promise: keeping businesses agile and adaptive to any type of environmental shifts by assembling new compositions (that is, business processes) out of existing atomic services.
The general approach to achieve this, also used in every chapter of this book, is as follows:
- Find the root cause of the problem and analyze it in strong relevance to the SOA design principles.
- Speculate the decomposition of the problem into smaller, more manageable parts that could be implemented as separate atomic components or services.
- Identify the ways of standardizing the decomposed components/services, focusing on the improvement of their reuse.
- Propose various vendor-neutral solutions (not exactly Oracle) based on the identified components/services and, again, diligently analyze them using the SOA design principles, focusing on the desired SOA characteristics.
- Present the most optimal solution based on an Oracle platform and compare it to other alternatives proposed during the analysis phase. Since we are vendor-neutral and focus primarily on the preferred solution's characteristics, we cannot guarantee that Oracle realization will always win, but it will be the closest bet for most of the discussed use cases.
In order to make the first step (the problem analysis) consistent, verifiable, and undisputable, in Chapter 1, SOA Ecosystem – Interconnected Principles, Patterns, and Frameworks, we introduce you to the SOA principles and the areas of their application. It is important to see these principles interconnected as their relations are not always straightforward and we should be very careful in balancing them in different frameworks and service layers. Some key SOA standards will also be discussed with the focus on those employed in the composition controllers design.
Logically, following the architectural two-folded task, after discussing the vendor-neutral SOA aspects, we look at the Oracle product's portfolio and see how it can help us in achieving the goals of service orientation. The introduction to the characteristics of Oracle Fusion Middleware will help us in the chapters to follow, when building practical solutions around Agnostic Composition controllers for different companies. Importantly, we will not jump into Oracle realization at the very beginning of every chapter (this part is dedicated to a certain SOA framework). Instead, we will look very closely at every alternative, check its feasibility, and see how common solutions (in the form of patterns) can help us in mitigating common problems for these frameworks.
