SOA服務(wù)設(shè)計(jì)原則

內(nèi)容概要

　　本書(shū)主要介紹了SOA基礎(chǔ)和SOA設(shè)計(jì)原則，包括服務(wù)協(xié)議、服務(wù)耦合、服務(wù)抽象、服務(wù)可重用、服務(wù)自治、服務(wù)狀態(tài)管理、服務(wù)發(fā)現(xiàn)、服務(wù)組合的設(shè)計(jì)原則和應(yīng)用案例，最后對(duì)SOA和面向?qū)ο蟮脑O(shè)計(jì)方法進(jìn)行了對(duì)比，在附錄中給出SOA的服務(wù)交付、分析、服務(wù)建模、服務(wù)設(shè)計(jì)等參考流程。本書(shū)對(duì)業(yè)務(wù)工程進(jìn)行了徹底的研究，引領(lǐng)讀者學(xué)習(xí)了綜合的、深入的、可視化的面向服務(wù)設(shè)計(jì)范例，精確地揭示了現(xiàn)實(shí)中的SOA服務(wù)應(yīng)該如何設(shè)計(jì)。

作者簡(jiǎn)介

作者：(美國(guó))Thomas Erl

書(shū)籍目錄

PrefaceChapter 1:Introduction1.1 Objectives of this Book1.2 Who this Book Is For1.3 What this Book Does Not CoverTopics Covered by Other BooksSOA Standardization Efforts1.4 How this Book Is OrganizedPart I:FundamentalsPart II:Design PrinciplesPart III:SupplementalAppendices1.5 Symbols,Figures,and Style ConventionsSymbol LegendHow Color Is UsedThe Service Symbol1.6 Additional InformationUpdates,Errata,and Resources(www.soabooks.com)Master Glossary(www.soaglossary.com)Referenced Specifications(www.soaspecs.com)Service-Oriented Computing Poster(www.soaposters.com)The SOA Magazine(www.soamag.com)Notification ServiceContact the AuthorChapter 2:Case Study2.1 Case Study Background:Cutit Saws LtdHistoryTechnical Infrastructure and Automation EnvironmentBusiness Goals and ObstaclesPART I:FUNDAMENTALSChapter 3:Service-Oriented Computing and SOA3.1 Design FundamentalsDesign CharacteristicDesign PrincipleDesign ParadigmDesign PatternDesign Pattern LanguageDesign StandardBest PracticeA Fundamental Design Framework3.2 Introduction to Service-Oriented ComputingService-Oriented ArchitectureService-Orientation,Services,and Service-Oriented Solution LogicService CompositionsService InventoryUnderstanding Service-Oriented Computing ElementsService ModelsSOA and Web ServicesService Inventory BlueprintsService-Oriented Analysis and Service ModelingService-Oriented DesignService-Oriented Architecture:Concepts,Technology,and Design3.3 Goals and Benefits of Service-Oriented ComputingIncreased Intrinsic InteroperabilityIncreased FederationIncreased Vendor Diversification OptionsIncreased Business and Technology Domain AlignmentIncreased ROIIncreased Organizational AgilityReduced IT Burden3.4 Case Study BackgroundChapter 4:Service-Orientation4.1 Introduction to Service-OrientationServices in Business AutomationServices Are Collections of CapabilitiesService-Orientation as a Design ParadigmService-Orientation and Interoperability4.2 Problems Solved by Service-OrientationLife Before Service-OrientationThe Need for Service-Orientation4.3 Challenges Introduced by Service-OrientationDesign ComplexityThe Need for Design StandardsTop-Down RequirementsCounter-Agile Service Delivery in Support of Agile Solution DeliveryGovernance Demands4.4 Additional ConsiderationsIt Is Not a Revolutionary ParadigmEnterprise-wide Standardization Is Not RequiredReuse Is Not an Absolute Requirement4.5 Effects of Service-Orientation on the EnterpriseService-Orientation and the Concept of"Application"Service-Orientation and the Concept of"Integration"The Service CompositionApplication,Integration,and Enterprise Architectures4.6 Origins and Influences of Service-OrientationObject-OrientationWeb ServicesBusiness Process Management(BPM)Enterprise Application Integration(EAI)Aspect-Oriented Programming(AOP)4.7 Case Study BackgroundChapter 5:Understanding Design Principles5.1 Using Design PrinciplesIncorporate Principles within Service-Oriented AnalysisIncorporate Principles within Formal Design ProcessesEstablish Supporting Design StandardsApply Principles to a Feasible Extent5.2 Principle Profiles5.3 Design Pattern References5.4 Principles that Implement vs.Principles that Regulate5.5 Principles and Service Implementation Mediums"Capability"vs."Operation"vs."Method"5.6 Principles and Design GranularityService GranularityCapability GranularityData GranularityConstraint GranularitySections on Granularity Levels5.7 Case Study BackgroundThe Lab Project Business ProcessPART II:DESIGN PRINCIPLESChapter 6:Service Contracts(Standardization and Design)6.1 Contracts ExplainedTechnical Contracts in AbstractOrigins of Service Contracts6.2 Profiling this Principle6.3 Types of Service Contract StandardizationStandardization of Functional Service ExpressionStandardization of Service Data RepresentationStandardization of Service Policies6.4 Contracts and Service DesignData Representation Standardization and Transformation AvoidanceStandardization and GranularityStandardized Service Contracts and Service ModelsHow Standardized Service Contract Design Affects Other Principles6.5 Risks Associated with Service Contract DesignVersioningTechnology DependenciesDevelopment Tool Deficiencies6.6 More About Service ContractsNon-Technical Service Contract Documents"Web Service Contract Design for SOA"6.7 Case Study ExamplePlanned ServicesDesign StandardsStandardized WSDL Definition ProfilesStandardized XML Schema DefinitionsStandardized Service and Data Representation LayersService DescriptionsConclusionChapter 7:Service Coupling(Intra-Service and Consumer Dependencies)7.1 Coupling ExplainedCoupling in AbstractOrigins of Software Coupling7.2 Profiling this Principle7.3 Service Contract Coupling TypesLogic-to-Contract Coupling(the coupling of service logic to the service contract)Contract-to-Logic Coupling(the coupling of the service contract to its logic)Contract-to-Technology Coupling(the coupling of the service contract to its underlying technology)Contract-to-Implementation Coupling(the coupling of the service contract to its implementation environment)Contract-to-Functional Coupling(the coupling of the service contract to external logic)7.4 Service Consumer Coupling TypesConsumer-to-Implementation CouplingStandardized Service Coupling and Contract CentralizationConsumer-to-Contract CouplingMeasuring Consumer Coupling7.5 Service Loose Coupling and Service DesignCoupling and Service-OrientationService Loose Coupling and GranularityCoupling and Service ModelsHow Service Loose Coupling Affects Other Principles7.6 Risks Associated with Service Loose CouplingLimitations of Logic-to-Contract CouplingProblems when Schema Coupling Is"too loose"7.7 Case Study ExampleCoupling Levels of Existing ServicesIntroducing the InvLegacyAPI ServiceService Design OptionsChapter 8:Service Abstraction(Information Hiding and Meta Abstraction Types)8.1 Abstraction ExplainedOrigins of Information Hiding8.2 Profiling this PrincipleWhy Service Abstraction Is Needed8.3 Types of Meta AbstractionTechnology Information AbstractionFunctional AbstractionProgrammatic Logic AbstractionQuality of Service AbstractionMeta Abstraction Types and the Web Service Regions of InfluenceMeta Abstraction Types in the Real World8.4 Measuring Service AbstractionContract Content Abstraction LevelsAccess Control LevelsAbstraction Levels and Quality of Service Meta Information8.5 Service Abstraction and Service DesignService Abstraction vs.Service EncapsulationHow Encapsulation Can Affect AbstractionService Abstraction and Non-Technical Contract DocumentsService Abstraction and GranularityService Abstraction and Service ModelsHow Service Abstraction Affects Other Principles8.6 Risks Associated with Service AbstractionMulti-Consumer Coupling RequirementsMisjudgment by HumansSecurity and Privacy Concerns8.7 Case Study ExampleService Abstraction LevelsOperation-Level Abstraction ExamplesChapter 9:Service Reusability(Commercial and Agnostic Design)9.1 Reuse ExplainedReuse in AbstractOrigins of Reuse9.2 Profiling this Principle9.3 Measuring Service Reusability and Applying Commercial DesignCommercial Design ConsiderationsMeasures of Planned ReuseMeasuring Actual ReuseCommercial Design Versus Gold-Plating9.4 Service Reuse in SOAReuse and the Agnostic ServiceThe Service Inventory Blueprint9.5 Standardized Service Reuse and Logic CentralizationUnderstanding Logic CentralizationLogic Centralization as an Enterprise StandardLogic Centralization and Contract CentralizationCentralization and Web ServicesChallenges to Achieving Logic Centralization9.6 Service Reusability and Service DesignService Reusability and Service ModelingService Reusability and GranularityService Reusability and Service ModelsHow Service Reusability Affects Other Principles9.7 Risks Associated with Service Reusability and Commercial DesignCultural ConcernsGovernance ConcernsReliability ConcernsSecurity ConcernsCommercial Design Requirement ConcernsAgile Delivery Concerns9.8 Case Study ExampleThe Inventory Service ProfileAssessing Current CapabilitiesModeling for a Targeted Measure of ReusabilityThe New EditItemRecord OperationThe New ReportStockLevels OperationThe New AdjustItemsQuantity OperationRevised Inventory Service ProfileChapter 10:Service Autonomy(Processing Boundaries and Control)10.1 Autonomy ExplainedAutonomy in AbstractOrigins of Autonomy10.2 Profiling this Principle10.3 Types of Service AutonomyRuntime Autonomy(execution)Design-Time Autonomy(governance)10.4 Measuring Service AutonomyService Contract Autonomy(services with normalized contracts)Shared AutonomyService Logic Autonomy(partially isolated services)Pure Autonomy(isolated services)Services with Mixed Autonomy10.5 Autonomy and Service DesignService Autonomy and Service Modeling

章節(jié)摘錄

版權(quán)頁(yè):Learning from one’s mistakes is one of the most essential principles of life. As the old saying goes, “One cannot achieve success without failure.” When I hear that saying I sometimes mentally append it with “…unless one happens to be lucky.” While there may be some truth to this, the fact is that luck is not something we want to ever have to depend on when building service-oriented architecture (SOA). Optimistic project plans or risk assessments qualified with “…as long as we get lucky” won’t have much success instilling confidence (or receiving funding).Apersonal mantra of mine that has emerged from involvement in numerous SOA projects preaches that “the key to successfully doing something is in successfully understanding what you’re doing.” Again, disregarding the luck factor, this philosophy is very relevant to service-oriented computing and forms the basis and purpose of this book.The content provided in the upcoming chapters is intended to help you become a “true” SOA professional. By that I mean someone who has a clear vision of what it means for a software program to be “service-oriented,” who can speak about service-oriented computing from a real-world perspective, and who approaches the design of services with a deep insight into the dynamics behind service-orientation.Furthermore, such an individual requires the ability to assess options in technology, design, development, delivery, and governance―all important success factors in SOA initiatives. What this translates into for the SOA professional is a need for an increased level of judgment.Judgment can be seen as a combination of common sense plus a sound knowledge of whatever is being judged. In the world of SOA projects, this points to two specific areas: a need to understand service-oriented computing with absolute clarity and a need to understand your own environments, constraints, and strategic goals just as well. With this range of knowledge, you can leverage what the service-oriented computing platform has to offer in order to fulfill your strategic goals within whatever boundaries you are required to operate.In theory this makes sense, but there is still something important missing from this formula. Nothing helps raise the level of one’s judgment more than actual experience. There’s no better way to truly appreciate the strategic potential of service-oriented computing and the spectrum of challenges that come with its adoption, than to personally go through the motions of a typical enterprise SOA project. This book can’t replace real-world experience, but it strives to be the next best thing.1.1 Objectives of this Book The focus of this book is first and foremost on the design of services for SOA. There is a constant emphasis on how and where design principles can and should be applied with the ultimate goal of producing high quality services.Specifically, this book has the following objectives: . to clearly establish the criteria for solution logic to be classified as “service-oriented” . to provide complete coverage of the service-orientation design paradigm . to document specific design characteristics realized by the application of individual design principles . to describe how the application of each principle affects others . to explain the link between the design characteristics realized by serviceorientation and the strategic goals associated with SOA and service-oriented computing . to establish the origins of service-orientation and identify how this paradigm differs from other design approaches Essentially, this guide intends to provide practical, comprehensive, and in-depth coverage of the service-orientation design paradigm, which encompasses the official definition and detailed explanation of eight key principles, each of which is explored in a separate chapter.1.2 Who this Book Is ForAs a guide dedicated to service design, this book will be useful to IT professionals interested in or involved with technology architecture, systems analysis, and solution design. Specifically, this book will be helpful to developers, analysts, and architects who: . want to know how to design services for SOA so that they fully support the goals and benefits of service-oriented computing . want to understand the service-orientation design paradigm . want to learn about how SOA and service-orientation relate to and can be implemented through Web services . want in-depth guidance for designing different types of services . want an understanding of how services need to be designed in support of complex service aggregation and composition . want to learn about design considerations that apply not just to the entire service, but also to individual service capabilities . want to better comprehend how services can and should relate to each other . want deep insight into how service contracts should be shaped in support of service-orientation . want to know how to determine the appropriate levels of service, apability, data, and constraint granularity . want an awareness of how WSDL, XML schema, and WS-Policy definitions are best positioned within service designs . want to understand the origins of service-orientation and how specifically it differs from object-orientation . will be involved with creating design standards for SOA-based solutions 1.3 What this Book Does Not Cover SOA and service-oriented computing represent broad subject matters. Many books can be written to explore various aspects of technology, architecture, analysis, and design.This book is focused solely on service engineering and the science of service design. Topics Covered by Other Books Aprimary objective of the Prentice Hall Service-Oriented Computing Series from Thomas Erl is to establish a library of complementary books dedicated to service-oriented computing.To accomplish this, an effort has been made to minimize overlap between this title and others in the series.For example, even though service design touches upon numerous architectural issues, it is important to acknowledge that this is a book about designing services for SOA, not about designing SOA itself. The companion title, SOA: Design Patterns, provides a catalog of patterns, many of which deal directly with architectural design.1.3 What this Book Does Not Cover 5Furthermore, this book is not a tutorial about Web services or SOA fundamentals. Several books have already covered this ground sufficiently. Although some chapters provide introductory coverage of service-oriented computing, they do not go into detail.A number of sections also assume some knowledge of WSDL, XML schema, and WSPolicy.Basic tutorials for these technologies and structured “how-to” content for SOA is provided in Service-Oriented Architecture: Concepts, Technology, and Design, another official companion guide also part of this book series.Finally, although this book includes a number of case study examples, it does not provide full code samples of implemented services or service contracts. The book Web Service Contract Design for SOA is wholly dedicated to the design of Web service contracts and provides both basic and advanced tutorials for WSDL, XML schema, WS-Policy, SOAP, and WS-Addressing. Additionally, several other series titles in development are dedicated to supplying comprehensive coverage of how to build services using different development platforms, such as .NET and Java.

編輯推薦

《SOA服務(wù)設(shè)計(jì)原則(英文版)》對(duì)業(yè)務(wù)工程進(jìn)行了徹底的研究，引領(lǐng)讀者學(xué)習(xí)了綜合的、深入的、可視化的面向服務(wù)設(shè)計(jì)范例，精確地揭示了現(xiàn)實(shí)中的SOA服務(wù)應(yīng)該如何設(shè)計(jì)。可供SOA領(lǐng)域的軟件架構(gòu)師、高級(jí)軟件工程師、分析師、應(yīng)用科研人員等參考學(xué)習(xí)。

圖書(shū)封面

圖書(shū)標(biāo)簽Tags

無(wú)

評(píng)論、評(píng)分、閱讀與下載

---

    SOA服務(wù)設(shè)計(jì)原則 PDF格式下載

---