Thomas Erl is the world''s top-selling SOA author,the Series Editor of the Prentice Hall Service-Oriented Computing Series from Thomas Erl,and Editor of The SOA Magazine.
With over 80,000 copies in print world-wide,his books have become international bestsellers and have been formally endorsed by senior members of major software organizations,such as IBM,Microsoft,Oracle,BEA,Sun,Intel,SAP,and HP.His most recent titles are SOA:Principles of Service Design and SOADesign Patternswww.soabooks.com.
Thomas is also the founder of SOA Systems Inc.www.soasystems.com,a company specializing in SOA training and strategic consulting services with a vendor-agnostic focus.Through his work with standards organizations and independent research efforts,Thomas has made significant contributions to the SOA industry,most notably in the areas of service-orientation and SOA methodology.
Thomas is a speaker and instructor for private and public events,and has delivered many workshops and keynote speeches.He has also developed an industry-recognized SOAtraining and certification program.For more information,see www.soaschool.com and www.soatraining.com.
Papers and articles written by Thomas have been published in numerous industry trade magazines and Web sites,and he has delivered Webcasts and interviews for many publications,including the Wall Street Journal.
For more information,visit www.thomaserl.com.
目錄：
Preface
Chapter 1 Introduction
1.1 Why this book is important
1.1.1 The false SOA
1.1.2 The ideal SOA
1.1.3 The real SOA
1.2 Objectives of this book
1.2.1 Understanding SOA,service-orientation,and Web services
1.2.2 Learning how to build SOA with Web services
1.3 Who this book is for
1.4 What this book does not cover
1.5 How this book is organized
1.5.1 Part Ⅰ:SOA and Web Services Fundamentals
1.5.2 Part Ⅱ:SOA and WS-* Extensions
1.5.3 Part Ⅲ:SOA and Service-Orientation
1.5.4 Part Ⅳ:Building SOAPlanning and Analysis
1.5.5 Part Ⅴ:Building SOATechnology and Design
1.5.6 Conventions
1.6 Additional information
1.6.1 The XML & Web Services Integration FrameworkXWIF
1.6.2 www.serviceoriented.ws
1.6.3 Contact the Author
Chapter 2 Case Studies
2.1 How case studies are used
2.1.1 Style characteristics
2.1.2 Relationship to abstract content
2.1.3 Code samples
2.2 Case #1 background:RailCo Ltd.
2.2.1 History
2.2.2 Technical infrastructure
2.2.3 Automation solutions
2.2.4 Business goals and obstacles
2.3 Case #2 background:Transit Line Systems Inc
2.3.1 History
2.3.2 Technical infrastructure
2.3.3 Automation solutions
2.3.4 Business goals and obstacles
Part Ⅰ SOA and Web Services Fundamentals
Chapter 3 Introducing SOA
3.1 Fundamental SOA
3.1.1 A service-oriented analogy
3.1.2 How services encapsulate logic
3.1.3 How services relate
3.1.4 How services communicate
3.1.5 How services are designed
3.1.6 How services are built
3.1.7 Primitive SOA
3.2 Common characteristics of contemporary SOA
3.2.1 Contemporary SOA is at the core of the service-oriented computing platform
3.2.2 Contemporary SOA increases quality of service
3.2.3 Contemporary SOA is fundamentally autonomous
3.2.4 Contemporary SOA is based on open standards
3.2.5 Contemporary SOA supports vendor diversity
3.2.6 Contemporary SOA promotes discovery
3.2.7 Contemporary SOA fosters intrinsic interoperability
3.2.8 Contemporary SOA promotes federation
3.2.9 Contemporary SOA promotes architectural composability
3.2.10 Contemporary SOA fosters inherent reusability
3.2.11 Contemporary SOA emphasizes extensibility
3.2.12 Contemporary SOA supports a service-oriented business modeling paradigm
3.2.13 Contemporary SOA implements layers of abstraction
3.2.14 Contemporary SOA promotes loose coupling throughout the enterprise
3.2.15 Contemporary SOA promotes organizational agility
3.2.16 Contemporary SOA is a building block
3.2.17 Contemporary SOA is an evolution
3.2.18 Contemporary SOA is still maturing
3.2.19 Contemporary SOA is an achievable ideal
3.2.20 Defining SOA
3.2.21 Separating concrete characteristics
3.3 Common misperceptions about SOA
3.3.1 "An application that uses Web services is service-oriented."
3.3.2 "SOA is just a marketing term used to re-brand Web services."
3.3.3 "SOA is just a marketing term used to re-brand distributed computing with Web services."
3.3.4 "SOA simplifies distributed computing."
3.3.5 "An application with Web services that uses WS-* extensions is service-oriented."
3.3.6 "If you understand Web services you won?t have a problem building SOA."
3.3.7 "Once you go SOA,everything becomes interoperable."
3.4 Common tangible benefits of SOA
3.4.1 Improved integrationand intrinsic interoperability
3.4.2 Inherent reuse
3.4.3 Streamlined architectures and solutions
3.4.4 Leveraging the legacy investment
3.4.5 Establishing standardized XML data representation
3.4.6 Focused investment on communications infrastructure
3.4.7 "Best-of-breed" alternatives
3.4.8 Organizational agility
3.5 Common pitfalls of adopting SOA
3.5.1 Building service-oriented architectures like traditional distributed architectures
3.5.2 Not standardizing SOA
3.5.3 Not creating a transition plan
3.5.4 Not starting with an XML foundation architecture
3.5.5 Not understanding SOA performance requirements
3.5.6 Not understanding Web services security
3.5.7 Not keeping in touch with product platforms and standards development
Chapter 4 The Evolution of SOA
4.1 An SOA timelinefrom XML to Web services to SOA
4.1.1 XML:a brief history
4.1.2 Web services:a brief history
4.1.3 SOA:a brief history
4.1.4 How SOA is re-shaping XML and Web services
4.2 The continuing evolution of SOAstandards organizations and contributing vendors
4.2.1 "Standards" vs"Specifications" vs"Extensions"
4.2.2 Standards organizations that contribute to SOA
4.2.3 Major vendors that contribute to SOA
4.3 The roots of SOAcomparing SOA to past architectures
4.3.1 What is architecture?
4.3.2 SOA vsclient-server architecture
4.3.3 SOA vsdistributed Internet architecture
4.3.4 SOA vshybrid Web service architecture
4.3.5 Service-orientation and object-orientationPart Ⅰ
Chapter 5 Web Services and Primitive SOA
5.1 The Web services framework
5.2 Servicesas Web services
5.2.1 Service roles
5.2.2 Service models
5.3 Service descriptionswith WSDL
5.3.1 Service endpoints and service descriptions
5.3.2 Abstract description
5.3.3 Concrete description
5.3.4 Metadata and service contracts
5.3.5 Semantic descriptions
5.3.6 Service description advertisement and discovery
5.4 Messagingwith SOAP
5.4.1 Messages
5.4.2 Nodes
5.4.3 Message paths
Part Ⅱ SOA and WS-* Extensions
What is "WS-*"?
Chapter 6 Web Services and Contemporary SOAPart Ⅰ:Activity Management and Composition
6.1 Message exchange patterns
6.1.1 Primitive MEPs
6.1.2 MEPs and SOAP
6.1.3 MEPs and WSDL
6.1.4 MEPs and SOA
6.2 Service activity
6.2.1 Primitive and complex service activities
6.2.2 Service activities and SOA
6.3 Coordination
6.3.1 Coordinator composition
6.3.2 Coordination types and coordination protocols
6.3.3 Coordination contexts and coordination participants
6.3.5 The activation and registration process
6.3.5 The completion process
6.3.6 Coordination and SOA
6.4 Atomic transactions
6.4.1 ACID transactions
6.4.2 Atomic transaction protocols
6.4.3 The atomic transaction coordinator
6.4.4 The atomic transaction process
6.4.5 Atomic transactions and SOA
6.5 Business activities
6.5.1 Business activity protocols
6.5.2 The business activity coordinator
6.5.3 Business activity states
6.5.4 Business activities and atomic transactions
6.5.5 Business activities and SOA
6.6 Orchestration
6.6.1 Business protocols and process definition
6.6.2 Process services and partner services
6.6.3 Basic activities and structured activities
6.6.4 Sequences,flows,and links
6.6.5 Orchestrations and activities
6.6.6 Orchestration and coordination
6.6.7 Orchestration and SOA
6.7 Choreography
6.7.1 Collaboration
6.7.2 Roles and participants
6.7.3 Relationships and channels
6.7.4 Interactions and work units
6.7.5 Reusability,composability,and modularity
6.7.6 Orchestrations and choreographies
6.7.7 Choreography and SOA
Chapter 7 Web Services and Contemporary SOAPart Ⅱ:Advanced Messaging,Metadata,and Security
7.1 Addressing
7.1.1 Endpoint references
7.1.2 Message information headers
7.1.3 Addressing and transport protocol independence
7.1.4 Addressing and SOA
7.2 Reliable messaging
7.2.1 RM Source,RM Destination,Application Source,and Application Destination
7.2.2 Sequences
7.2.3 Acknowledgements
7.2.4 Delivery assurances
7.2.5 Reliable messaging and addressing
7.2.6 Reliable messaging and SOA
7.3 Correlation
7.3.1 Correlation in abstract
7.3.2 Correlation in MEPs and activities
7.3.3 Correlation in coordination
7.3.4 Correlation in orchestration
7.3.5 Correlation in addressing
7.3.6 Correlation in reliable messaging
7.3.7 Correlation and SOA
7.4 Policies
7.4.1 The WS-Policy framework
7.4.2 Policy assertions and policy alternatives
7.4.3 Policy assertion types and policy vocabularies
7.4.4 Policy subjects and policy scopes
7.4.5 Policy expressions and policy attachments
7.4.6 What you really need to know
7.4.7 Policies in coordination
7.4.8 Policies in orchestration and choreography
7.4.9 Policies in reliable messaging
7.4.10 Policies and SOA
7.5 Metadata exchange
7.5.1 The WS-MetadataExchange specification
7.5.2 Get Metadata request and response messages
7.5.3 Get request and response messages
7.5.4 Selective retrieval of metadata
7.5.5 Metadata exchange and service description discovery
7.5.6 Metadata exchange and version control
7.5.7 Metadata exchange and SOA
7.6 Security
7.6.1 Identification,authentication,and authorization
7.6.2 Single sign-on
7.6.3 Confidentiality and integrity
7.6.4 Transport-level security and message-level security
7.6.5 Encryption and digital signatures
7.6.6 Security and SOA
7.7 Notification and eventing
7.7.1 Publish-and-subscribe in abstract
7.7.2 One concept,two specifications
7.7.3 The WS-Notification Framework
7.7.4 The WS-Eventing specification
7.7.5 WS-Notification and WS-Eventing
7.7.6 Notification,eventing,and SOA
Part Ⅲ SOA and Service-Orientation
Chapter 8 Principles of Service-Orientation
8.1 Service-orientation and the enterprise
8.2 Anatomy of a service-oriented architecture
8.2.1 Logical components of the Web services framework
8.2.2 Logical components of automation logic
8.2.3 Components of an SOA
8.2.4 How components in an SOA inter-relate
8.3 Common principles of service-orientation
8.3.1 Services are reusable
8.3.2 Services share a formal contract
8.3.3 Services are loosely coupled
8.3.4 Services abstract underlying logic
8.3.5 Services are composable
8.3.6 Services are autonomous
8.3.7 Services are stateless
8.3.8 Services are discoverable
8.4 How service-orientation principles inter-relate
8.4.1 Service reusability
8.4.2 Service contract
8.4.3 Service loose coupling
8.4.4 Service abstraction
8.4.5 Service composability
8.4.6 Service autonomy
8.4.7 Service statelessness
8.4.8 Service discoverability
8.5 Service-orientation and object-orientationPart Ⅱ
8.6 Native Web service support for service-orientation principles
Chapter 9 Service Layers
9.1 Service-orientation and contemporary SOA
9.1.1 Mapping the origins and supporting sources of concrete SOA characteristics
9.1.2 Unsupported SOA characteristics
9.2 Service layer abstraction
9.2.1 Problems solved by layering services
9.3 Application service layer
9.4 Business service layer
9.5 Orchestration service layer
9.6 Agnostic services
9.7 Service layer configuration scenarios
9.7.1 Scenario #1:Hybrid application services only
9.7.2 Scenario #2:Hybrid and utility application services
9.7.3 Scenario #3:Task-centric business services and utility application services
9.7.4 Scenario #4:Task-centric business services,entity-centric business services,and utility application services
9.7.5 Scenario #5:Process services,hybrid application services,and utility application services
9.7.6 Scenario #6:Process services,task-centric business services,and utility application services
9.7.7 Scenario #7:Process services,task-centric business services,entity-centric business services,and utility application services
9.7.8 Scenario #8:Process services,entity-centric business services,and utility application services
Part Ⅳ Building SOAPlanning and Analysis
Chapter 10 SOA Delivery Strategies
10.1 SOA delivery lifecycle phases
10.1.1 Basic phases of the SOA delivery lifecycle
10.1.2 Service-oriented analysis
10.1.3 Service-oriented design
10.1.4 Service development
10.1.5 Service testing
10.1.6 Service deployment
10.1.7 Service administration
10.1.8 SOA delivery strategies
10.2 The top-down strategy
10.2.1 Process
10.2.2 Pros and cons
10.3 The bottom-up strategy
10.3.1 Process
10.3.2 Pros and cons
10.4 The agile strategy
10.4.1 Process
10.4.2 Pros and cons
Chapter 11 Service-Oriented AnalysisPart Ⅰ:Introduction
11.1 Introduction to service-oriented analysis
11.1.1 Objectives of service-oriented analysis
11.1.2 The service-oriented analysis process
11.2 Benefits of a business-centric SOA
11.2.1 Business services build agility into business models
11.2.2 Business services prepare a process for orchestration
11.2.3 Business services enable reuse
11.2.4 Only business services can realize the service-oriented enterprise
11.3 Deriving business services
11.3.1 Sources from which business services can be derived
11.3.2 Types of derived business services
11.3.3 Business services and orchestration
Chapter 12 Service-Oriented AnalysisPart Ⅱ:Service Modeling
12.1 Service modelinga step-by-step process
12.1.1 "Services" versus "Service Candidates"
12.1.2 Process description
12.2 Service modeling guidelines
12.2.1 Take into account potential cross-process reusability of logic being encapsulatedtask-centric business service candidates
12.2.2 Consider potential intra-process reusability of logic being encapsulatedtask-centric business service candidates
12.2.3 Factor in process-related dependenciestask-centric business service candidates
12.2.4 Model for cross-application reuseapplication service candidates
12.2.5 Speculate on further decomposition requirements
12.2.6 Identify logical units of work with explicit boundaries
12.2.7 Prevent logic boundary creep
12.2.8 Emulate process services when not using orchestrationtask-centric business service candidates
12.2.9 Target a balanced model
12.2.10 Classify service modeling logic
12.2.11 Allocate appropriate modeling resources
12.2.12 Create and publish business service modeling standards
12.3 Classifying service model logic
12.3.1 The SOE model
12.3.2 The enterprise business model
12.3.3 "Building Blocks" versus "Service Models"
12.3.4 Basic modeling building blocks
12.4 Contrasting service modeling approachesan example
Part Ⅴ Building SOATechnology and Design
Chapter 13 Service-Oriented DesignPart Ⅰ:Introduction
13.1 Introduction to service-oriented design
13.1.1 Objectives of service-oriented design
13.1.2 "Design standards" versus "Industry standards"
13.1.3 The service-oriented design process
13.1.4 Prerequisites
13.2 WSDL-related XML Schema language basics
13.2.1 The schema element
13.2.2 The element element
13.2.3 The complexType and simpleType elements
13.2.4 The import and include elements
13.2.5 Other important elements
13.3 WSDL language basics
13.3.1 The definitions element
13.3.2 The types element
13.3.3 The message and part elements
13.3.4 The portType,interface,and operation elements
13.3.5 The input and output elementswhen used with operation
13.3.6 The binding element
13.3.7 The input and output elementswhen used with binding
13.3.8 The service,port,and endpoint elements
13.3.9 The import element
13.3.10 The documentation element
13.4 SOAP language basics
13.4.1 The Envelope element
13.4.2 The Header element
13.4.3 The Body element
13.4.4 The Fault element
13.5 Service interface design tools
13.5.1 Auto-generation
13.5.2 Design tools
13.5.3 Hand coding
Chapter 14 Service-Oriented DesignPart Ⅱ:SOA Composition Guidelines
14.1 Steps to composing SOA
14.1.1 Step 1:Choose service layers
14.1.2 Step 2:Position core standards
14.1.3 Step 3:Choose SOA extensions
14.2 Considerations for choosing service layers
14.3 Considerations for positioning core SOA standards
14.3.1 Industry standards and SOA
14.3.2 XML and SOA
14.3.3 The WS-I Basic Profile
14.3.4 WSDL and SOA
14.3.5 XML Schema and SOA
14.3.6 SOAP and SOA
14.3.7 Namespaces and SOA
14.3.8 UDDI and SOA
14.4 Considerations for choosing SOA extensions
14.4.1 Choosing SOA characteristics
14.4.2 Choosing WS-* specifications
14.4.3 WS-BPEL and SOA
Chapter 15 Service-Oriented DesignPart Ⅲ:Service Design
15.1 Service design overview
15.1.1 Design standards
15.1.2 About the process descriptions
15.1.3 Prerequisites
15.2 Entity-centric business service designa step-by-step process
15.2.1 Process description
15.3 Application service designa step-by-step process
15.3.1 Process description
15.4 Task-centric business service designa step-by-step process
15.4.1 Process description
15.5 Service design guidelines
15.5.1 Apply naming standards
15.5.2 Apply a suitable level of interface granularity
15.5.3 Design service operations to be inherently extensible
15.5.4 Identify known and potential service requestors
15.5.5 Consider using modular WSDL documents
15.5.6 Use namespaces carefully
15.5.7 Use the SOAP document and literal attribute values
15.5.8 Use WS-I Profiles even if WS-I compliance isn''t required
15.5.9 Document services with metadata
Chapter 16 Service-Oriented DesignPart Ⅳ:Business Process Design
16.1 WS-BPEL language basics
16.1.1 A brief history of BPEL4WS and WS-BPEL
16.1.2 Prerequisites
16.1.3 The process element
16.1.4 The partnerLinks and partnerLink elements
16.1.5 The partnerLinkType element
16.1.6 The variables element
16.1.7 The getVariableProperty and getVariableData functions
16.1.8 The sequence element
16.1.9 The invoke element
16.1.10 The receive element
16.1.11 The reply element
16.1.12 The switch,case,and otherwise elements
16.1.13 The assign,copy,from,and to elements
16.1.14 faultHandlers,catch,and catchAll elements
16.1.15 Other WS-BPEL elements
16.2 WS-Coordination overview
16.2.1 The CoordinationContext element
16.2.2 The Identifier and Expires elements
16.2.3 The CoordinationType element
16.2.4 The RegistrationService element
16.2.5 Designating the WS-BusinessActivity coordination type
16.2.6 Designating the WS-AtomicTransaction coordination type
16.3 Service-oriented business process designa step-by-step process
16.3.1 Process description
Chapter 17 Fundamental WS-* Extensions
You mustUnderstand this
17.1 WS-Addressing language basics
17.1.1 The EndpointReference element
17.1.2 Message information header elements
17.1.3 WS-Addressing reusability
17.2 WS-ReliableMessaging language basics
17.2.1 The Sequence,MessageNumber,and LastMessage elements
17.2.2 The SequenceAcknowledgement and AcknowledgementRange elements
17.2.3 The Nack element
17.2.4 The AckRequested element
17.2.5 Other WS-ReliableMessaging elements
17.3 WS-Policy language basics
17.3.1 The Policy element and common policy assertions
17.3.2 The ExactlyOne element
17.3.3 The All element
17.3.4 The Usage attribute
17.3.5 The Preference attribute
17.3.6 The PolicyReference element
17.3.7 The PolicyURIs attribute
17.3.8 The PolicyAttachment element
17.3.9 Additional types of policy assertions
17.4 WS-MetadataExchange language basics
17.4.1 The GetMetadata element
17.4.2 The Dialect element
17.4.3 The Identifier element
17.4.4 The Metadata,MetadataSection,and MetadataReference elements
17.4.5 The Get message
17.5 WS-Security language basics
17.5.1 The Security elementWS-Security
17.5.2 The UsernameToken,Username,and Password elementsWS-Security
17.5.3 The BinarySecurityToken elementWS-Security
17.5.4 The SecurityTokenReference elementWS-Security
17.5.5 Composing Security element contentsWS-Security
17.5.6 The EncryptedData elementXML-Encryption
17.5.7 The CipherData,CipherValue,and CipherReference elementsXML-Encryption
17.5.8 XML-Signature elements
Chapter 18 SOA Platforms
18.1 SOA platform basics
18.1.1 Basic platform building blocks
18.1.2 Common SOA platform layers
18.1.3 Relationship between SOA layers and technologies
18.1.4 Fundamental service technology architecture
18.1.5 Vendor platforms
18.2 SOA support in J2EE
18.2.1 Platform overview
18.2.2 Primitive SOA support
18.2.3 Support for service-orientation principles
18.2.4 Contemporary SOA support
18.3 SOA support in .NET
18.3.1 Platform overview
18.3.2 Primitive SOA support
18.3.3 Support for service-orientation principles
18.3.4 Contemporary SOA support
18.4 Integration considerations
Appendix A Case Studies:Conclusion
A.1 RailCo Ltd
A.2 Transit Line Systems Inc
A.3 The Oasis Car Wash
Appendix B Service Models Reference
Glossary
About the Author
About the Photographs
Index
內容試閱：
1.1 Why this book is important
One of my favorite quotes came from an exchange I overheard while preparing
to speak at a conference. Two IT professionals were discussing their respective
environments, when one asked the other if his team was building a serviceoriented
architecture. The individual responded by saying "My architect thinks it''s
service-oriented, my developers insist it''s object-oriented, and my analysts wish it
would be more business-oriented. All I can tell you is that it isn''t what it was before
we started building Web services."
This candid statement is a sign of the times. Service-oriented architecture SOA has
become the focal point of the IT industry, yet few fully understand it. This book aims to
fill this knowledge gap by helping you accomplish the following goals:
? understand SOA, service-orientation, and Web services
? learn how to build SOA with Web services
Let''s begin by identifying the most common obstacle to adopting SOA.
1.1.1 The false SOA
I cannot recall any one term causing as much confusion as "service-oriented." Its apparent
ambiguity has led vendors, IT professionals, and the media to claim their own interpretations.
This, of course, makes grasping the meaning of a technical architecture
labeled as "service-oriented" all the more difficult.
SOA, as an abstract paradigm, has traditionally represented a baseline distributed architecture
with no reference to implementation. While relevant to us, this model represents
only a subset of SOA in its most common and contemporary form.
Coupled with the Web services platform and a set of commonly accepted service-orientation
principles, SOA has emerged as an architectural platform explicitly distinct from
its predecessors. It introduces new concepts supported by select technologies that significantly
augment characteristics of traditional distributed computing platforms―so
much so that service-oriented environments often end up redefining IT infrastructure.
This contemporary variety of SOA has received its share of attention. It has been promoted
as a platform capable of revolutionizing enterprise environments by leveraging
advancements in Web services technology and injecting organizations with hopes of
federation, agility, and cross-platform harmony.
Many have been led to the notion that a technical architecture deemed service-oriented
is simply one comprised of Web services. This is a common but dangerous assumption
that leads to the number one mistake made by organizations intending to adopt SOA―
the perception that the benefits promised by current mainstream SOA are attainable
solely through a deeper investment in the Web services platform.
The reason this is happening is understandable. It is difficult for an organization to
measure the extent of service-orientation possessed by its automation solutions when it
is not clear what it actually means for automation logic to be truly service-oriented.
What is needed is an ideal organizations can use as a target model.
1.1.2 The ideal SOA
We all have ideals that we aspire to attain. Ideals represent a state of excellence that motivate
us to accomplish things beyond what we may have been able to without the ideal
to look up to.
Service-orientation presents an ideal vision of a world in which resources are cleanly
partitioned and consistently represented. When applied to IT architecture, serviceorientation
establishes a universal model in which automation logic and even business
logic conform to this vision. This model applies equally to a task, a solution, an enterprise,
a community, and beyond.
By adhering to this vision, past technical and philosophical disparities are blanketed by
layers of abstraction that introduce a globally accepted standard for representing logic
and information. This level of standardization offers an enormous benefit potential for
organizations, as many of the traditional challenges faced by ever-changing IT environments
can be directly addressed through the application of these standardized layers.
The service-orientation ideal has sparked a movement that has positioned SOA as the
next phase in the evolution of business automation. In the same manner in which mainframe
systems were succeeded by client-server applications, and client-server environments
then evolved into distributed solutions based on Web technologies, the
contemporary, Web services-driven SOA is succeeding traditional distributed architecture
on a global scale.
All major software manufacturers and vendors are promoting support for SOA―some
even through direct involvement in the development of open standards. As a result,
every major development platform now officially supports the creation of serviceoriented
solutions. It would appear as though the realization of the SOA ideal is well
underway. Why, then, is the false SOA so common?
1.1.3 The real SOA
The reality is that the rise of the false SOA has distorted the vision of the ideal SOA. Not
only is the false SOA divergent from the "true path of service-orientation," it reinforces
SOAanti-patterns by extending and further entrenching the traditional distributed computing
model to which SOA offers an alternative. The eventual realization that initial
expectations will not be fulfilled can be further compounded once the costs, effort, and
overall ugliness of a retro-fitting effort are calculated.
All of this can be avoided. What is required is an understanding of service-orientation,
how it shapes technical architecture into SOA, and concrete, step-by-step processes for
realizing SOA in a contemporary form.
Be forewarned, though, that SOA makes some impositions. A change in mindset is
required, as business logic now needs to be viewed within a service-oriented context.
Applying this context also requires a change in automation logic, as solutions now need
to be built in support of service-orientation. Finally, a technical architecture capable of
hosting service-oriented automation logic further introduces new technology and infrastructure
requirements.
Real SOAs demand that an organization undergo this form of top-down transformation.
However, the ideal an organization works toward during this process is not necessarily
part of a universal vision of global service-orientation. It is an ideal based on how the
concept of service-orientation, the architectural model provided by contemporary SOA,
and the feature set offered by supporting technologies can benefit the vision and goals
of your organization.
A real SOA requires real change, real foresight, and real commitment. Most of all,
though, it requires guidance. This last requirement is what this book intends to assist
you with.
1.2 Objectives of this book
Let''s revisit the two primary goals we established earlier and elaborate on each.
1.2.1 Understanding SOA, service-orientation, and Web services
This book is not solely focused on architecture. Service-oriented architecture is a core
part of the service-oriented computing platform that brings with it new concepts, technologies,
and challenges. This book explores key parts of this platform to provide wellrounded
coverage of the multi-faceted world of building service-oriented automation
solutions.
Specifically, the following aspects of the SOA platform are explained:
? Primitive and contemporary variations of SOA are described and defined, establishing
a set of nearly 20 common characteristics that can be fulfilled by current Web
services technologies and design techniques explained in the step-by-step "how to"
processes.
? Fundamental Web services theory is covered, along with a study of how the emergence
of XML and Web services, coupled with the dynamics between standards
organizations and software vendors, have all influenced and contributed to the
evolution of SOA.
? The principles of service-orientation are described in detail. Their influence on Web
service design is explained, and they are further incorporated into the step-by-step
design processes.
? Over 10 WS-* specifications are described in detail. Separate parts of this book are
dedicated to explaining concepts in plain English and then covering the technical
details with code samples.
? Advanced SOA concepts and design issues are discussed, including the creation of
specialized service layers. These allow for the abstraction of business and technology
domains within the enterprise and form the basis for business and applicationcentric
service designs.
1.2.2 Learning how to build SOA with Web services
A large portion of this book is dedicated to providing step-by-step instructions on how
to accomplish the following tasks:
? perform a service-oriented analysis
? model service candidates derived from existing business documentation
? design the composition of an SOA
? design application services for technology abstraction
? design business services for business logic abstraction
? design service-oriented business processes
? assess SOA support provided by J2EE and .NET platforms
1.3 Who this book is for
SOAis a broad subject matter. It represents a new generation architectural platform that
encompasses a series of contemporary technologies both proprietary and vendorneutral.
This book will therefore be useful to various IT professionals who are interested in learning
more about the following:
? how to build SOA
? service-orientation principles
? designing different types of services for SOA
? service-oriented business modeling
? features provided by key WS-* specifications
? orchestration with WS-BPEL
? SOA support in J2EE and .NET platforms
? modeling business-centric services
? creating design standards for SOA-based solutions
? Web services technology within the context of SOA
1.4 What this book does not cover
While issues relating to integration and interoperability are referenced and discussed
throughout this book, service-oriented integration as a specific topic is not covered. This
is to prevent overlap with Service-Oriented Architecture: A Field Guide to Integrating XML
and Web Services, this book''s companion guide. The Field Guide is dedicated to matters of
integration and explores numerous service-oriented integration architectures, strategies,
and best practices.
Also though this book will be useful to developers who want to understand how to
build services for SOA and how different technology platforms support the SOA model,
this is not a book that explains how to program Web services using any particular programming
language. The step-by-step instructions provided focus on building and
orchestrating service endpoints―not the underlying component logic. We therefore
supply tutorials andor code examples for the following open Web services languages:
WSDL, SOAP, XML Schema, WS-BPEL, WS-Coordination, WS-Policy, WS-Metadata-
Exchange, WS-Security, WS-Addressing, and WS-ReliableMessaging.
NOTE
A knowledge of XML is recommended prior to reading this book. Suggested
reading materials are listed at www.serviceoriented.ws, and a collection
of introductory papers can be found at www.xmltechnologyexpert.com.
1.5 How this book is organized
The next 17 chapters contain a mountain of information. Some serious thought was
given to organization so that this book would be easy to read, while maintaining a logical
structure.
Content was finally divided into the following primary parts:
? Part I: SOA and Web Services Fundamentals
? Part II: SOA and WS-* Extensions
? Part III: SOA and Service-Orientation
? Part IV: Building SOA Planning and Analysis
? Part V: Building SOA Technology and Design
Essentially, Parts I, II, and III cover basic and advanced SOA concepts and theory that
prepare you for Parts IV and V, which supply a series of step-by-step "how to" instructions
for building SOA. Part V further contains coverage of WS-* technologies and SOA
platform support provided by J2EE and .NET.
A common thread across all parts of the book is the consistent use of case studies. Over
125 individual case study examples are interspersed throughout the chapters to provide
constant real-life reference points that further demonstrate key topics. Case studies are
introduced in Chapter 2, which establishes background information for two fictional
organizations.
Let''s now take a closer look at what''s covered in the remaining chapters.
購物車/收銀台(0) | 在線留言板
| 付款方式
| 聯絡我們
| 運費計算
| 幫助中心 |
加入書簽
HOME
新書上架
