Book Author: Nicolai M. Josuttis Chapter One: MotivationIT-Slideshares http://it-slideshares.blogspot.com/
1.0 Introduction Social Market economy is being replaced by a global market economy The key is flexibility (maintainability tradeoff) Processes and Systems are becoming more complex with heterogeneity that lead to decentralization. Old ways of dealing with scalability and distribution failed to work (no longer centralization, harmony, control) Business/IT gaps due to semantics (different meanings) SOA is what needed (scalable, flexible, understandable) Services: self-contained business functionalities Infrastructure: Enterprise Service Bus (ESB) - flexible Policies and Processes: deal with management changes
1.0 Infamous Hockey-Stick SOA is often explained with brief statements and prototypes, which leads to a problem illustrated by the infamous “hockey stick function”. Up to a certain level of complexity, the amount of effort required is low, and things look fine. But when this level of complexity is exceeded, the amount of effort required suddenly begins to rise faster than the benefit you gain, and finally, things collapse. Just introducing an infrastructure like Web Services might help us to a certain level of complexity, but this is not enough to guarantee scalability. The whole architecture, dealing with services, infrastructure, policies, and processes, must match.
1.1 Characteristics of LargeDistributed System SOA has characteristics of large distributed system Large system deal with ‘Legacies’ (old platforms, back-ward compatibility …) Heterogeneous, decentralized, fault-tolerant ? Different programming languages Different platforms Different design/programming paradigms Different middlewares Can harmonization of heterogeneous systems help in this constant changing world ?. (depends on the frequencies of changes) Different owners (teams, departments, budgets, schedules …). Organizations are complex business systems, within which a change in and one component is likely to have an impact on other components. May contain redundancy intentionally to manage runtime penalties. Managed redundancy is not so bad to avoid bottlenecks Need master of data sources where all redundancy derived from it.
1.2 The Tale of the Magic Bus Buses represent high interoperability. The idea behind them is that instead of creating and maintaining individual communication channels between different systems, each system only has to connect to the bus to be able to connect to all other systems N x (N-1)/2 connections in n systems reduced by factor of (n-1) Enterprise Application Integration Bus (EAI bus) replaced by Enterprise Service Bus (ESB).
1.2.1 The Tale of the Magic Bus
1.3 What can we learn from theTale of the Magic Bus There is no ‘Magic Bus’ without careful control of service dependencies and interactions chaos ESB represents high interoperability that simplifies connectivity but it will fail if it has unstructured design Why do we replace global variable with procedures ? Or Using modules/components instead of business object model ? Lesson learnt: Need structures provided by technical and organizational rules and patterns.
1.4 History of SOA 1994- Alexander Pasik: coined the term SOA to stress “server orientation” in Client/Server concepts 1996- Gartner analysts, Roy W. Schulte Web Services is NOT SOA and vice versa 2000- Microsoft’s web services bring SOA to mainstream 2K+: Other vendors participation: IBM, Oracle, HP, SAP, and SUN. (B2B hype) Booch: SOA strategy requires time and effort.
1.5.1 SOA in five slides: Slide 1 SOA Service-oriented architecture (SOA) is a paradigm for the realization and maintenance of business processes that span large distributed systems. It is based on three major technical concepts A service is a piece of self-contained business functionality that bridges IT/Business gap. E.g Simple service: store/retrieve customer data Complex service: business process of customer’s order An enterprise service bus (ESB) is the infrastructure that enables high interoperability between distributed systems, platforms, technologies for services. Loose coupling is the concept of reducing system dependencies. NOTE: Loosely coupled distributed systems are harder to develop, maintain, and debug.
1.5.2 Slide 2 Policies and Processes Distributed processing requires collaboration from every functional units of the company Roles, Policies, and processes, Lifecycle…etc must be set and requires lot of efforts Setting up the appropriate policies and processes usually takes more time than working out the initial technical details. Implementing model-driven service development policy
1.5.3 Slide 3: Web Services Web Services are one possible way of realizing the technical aspects of SOA. (Note: there are more important things than technical aspects) Web Services inherent issues Not yet mature to guarantee ‘interoperability’ Insufficient to achieve loosely coupling approach Web Services therefore should ‘not’ be the final standard for system integration. (Only use in specific infrastructure aspects)
1.5.4 SOA in Practice In theory, theory and practice are the same. In practice, they are not. General business cases and concepts might not work as well as expected when factors such as performance and security come into play You will have to build your specific SOA—you cant buy it. To craft it, youll need time and an incremental and iterative approach Whether you introduce SOA is not whats important. The important thing is that the IT solution you introduce is appropriate for your context and requirements.IT-Slideshares http://it-slideshares.blogspot.com/
1.5.5 Slide 5: SOA Governance andManagement Support You need a central team that will determine general aspects of your specific SOA. Balance governance You need the right people. Large systems are different from small systems, and you need people who have experience with such systems First things first. Dont start with the management of services. You need management when you have many services. You need support from the CEO and CIO. SOA is a strategy that affects the company as a whole. You need money for the long run. Cutting SOA budgets when only half of the homework is complete is a recipe for disaster.