book

Service-Oriented Architecture: A Field Guide to Integrating XML and Web Services

Name: Service-Oriented Architecture: A Field Guide to Integrating XML and Web Services
Author: Thomas Erl
ISBN: 0131428985

by Thomas Erl

April 2004

Intermediate to advanced

560 pages

12h 10m

English

Pearson

Read now

Unlock full access

Copyright
About Prentice Hall Professional Technical Reference
Preface
Acknowledgments
1. Introduction
1.1. Why this guide is important1.1.1. The hammer and XML1.1.2. XML and Web services1.1.3. Web services and Service-Oriented Architecture1.1.4. Service-Oriented Architecture and the hammer1.1.5. The hammer and you1.2. The XML & Web Services Integration Framework (XWIF)1.3. How this guide is organized1.3.1. Part I: The technical landscape1.3.2. Part II: Integrating technologyIntegrating XML into applications (Chapter 5)Integrating Web services into applications (Chapter 6)Integrating XML and databases (Chapter 7)1.3.3. Part III: Integrating applicationsThe mechanics of application integration (Chapter 8)Service-oriented architectures for legacy integration (Chapter 9)Service-oriented architectures for enterprise integration (Chapter 10)Service-oriented integration strategies (Chapter 11)1.3.4. Part IV: Integrating the enterpriseThirty best practices for integrating XML (Chapter 12)Thirty best practices for integrating Web services (Chapter 13)Building the service-oriented enterprise (SOE) (Chapter 14)1.3.5. The extended enterprise1.4. www.serviceoriented.ws1.5. Contact the author
I. The technical landscape
2. Introduction to XML technologies
2.1. Extensible Markup Language (XML)2.1.1. ConceptsElements, Documents, and Vocabularies2.1.2. Schemas2.1.3. Programming models2.1.4. Syntax2.2. Document Type Definitions (DTD)2.2.1. Concepts2.2.2. Syntax2.3. XML Schema Definition Language (XSD)2.3.1. Concepts2.3.2. Syntax2.4. Extensible Stylesheet Language Transformations (XSLT)2.4.1. ConceptsStructural transformationAesthetic transformation2.4.2. Syntax2.5. XML Query Language (XQuery)2.5.1. Concepts2.5.2. Syntax2.6. XML Path Language (XPath)2.6.1. Concepts2.6.2. Syntax
3. Introduction to Web services technologies
3.1. Web services and the service-oriented architecture (SOA)3.1.1. Understanding services3.1.2. XML Web services3.1.3. Service-oriented architecture (SOA)3.1.4. Web service rolesService providerService requestorIntermediaryInitial senderUltimate receiver3.1.5. Web service interactionMessage pathMessage exchange patternCorrelationChoreographyActivity3.1.6. Service models3.1.7. Web service description structureAbstractConcreteService definitionService description3.1.8. Introduction to first-generation Web services3.2. Web Services Description Language (WSDL)3.2.1. Abstract interface definition3.2.2. Concrete (implementation) definition3.2.3. Supplementary constructs3.3. Simple Object Access Protocol (SOAP)3.3.1. SOAP messaging frameworkSOAP nodesSOAP node types3.3.2. SOAP message structureSOAP node roles3.4. Universal Description, Discovery, and Integration (UDDI)
4. Introduction to second-generation (WS-*) Web services technologies
4.1. Second-generation Web services and the service-oriented enterprise (SOE)4.1.1. Problems solved by second-generation specificationsContext and transaction managementBusiness processesSecurityReliable messagingPoliciesAttachments4.1.2. The second-generation landscape4.2. WS-Coordination and WS-Transaction4.2.1. ConceptsAtomic transactionsBusiness activities4.2.2. Syntax4.3. Business Process Execution Language for Web Services (BPEL4WS)4.3.1. Recent business process specifications4.3.2. ConceptsBPEL4WS and WSDLBPEL4WS and WS-Coordination/WS-TransactionBPEL4WS and other specificationsPartner servicesProcess instancesProcess descriptionsBasic activitiesStructured activitiesService interaction4.3.3. SyntaxProcess elementpartnerLinks elementVariables elementfaultHandlers elementSequence element4.4. WS-Security and the Web services security specifications4.4.1. General security conceptsIdentificationAuthenticationAuthorizationIntegrityConfidentiality4.4.2. Specifications4.4.3. XML Key Management (XKMS)4.4.4. Extensible Access Control Markup Language (XACML) and Extensible Rights Markup Language (XrML)4.4.5. Security Assertion Markup Language (SAML) and .NET Passport4.4.6. XML-Encryption and XML-Digital Signatures4.4.7. Secure Sockets Layer (SSL)4.4.8. The WS-Security frameworkEnd-to-end and message-level securitySpecificationsWS-PolicyWS-TrustWS-PrivacyWS-SecureConversationWS-FederationWS-Authorization4.4.9. Concepts and syntaxClaims and security tokens4.5. WS-ReliableMessaging4.5.1. WS-Addressing4.5.2. ConceptsSequencesDelivery assurances4.5.3. Acknowledgements4.5.4. SyntaxSequenceSequenceAcknowledgement4.6. WS-Policy4.6.1. Concepts4.6.2. Syntax4.7. WS-AttachmentsSOAP Messages with Attachments (SwA)
II. Integrating technology
5. Integrating XML into applications
5.1. Strategies for integrating XML data representation5.1.1. Positioning XML data representation in your architectureXML as a data transport format within applicationsXML as a data transport format between applicationsXML as a data bridge within applicationsXML as a data bridge across applications5.1.2. Think “tree” (a new way of representing data)5.1.3. Easy now… (don't rush the XML document model)5.1.4. Design with foresight5.1.5. Focus on extensibility and reusability5.1.6. Lose weight while modeling! (keeping your documents trim)5.1.7. Naming element-types: performance vs. legibility5.1.8. Applying XML consistently5.1.9. Choosing the right API (DOM vs. SAX vs. Data Binding)5.1.10. Securing XML documents5.1.11. Pick the right toolsReview auto-generated markup and codeIdentify proprietary markup and codeLook for proprietary file typesUnderstand the orientation of the toolAssess the quality of conversion featuresEvaluate functional featuresUnderstand programmatic extensionsLook for quality feedbackConsider existing toolsets5.1.12. Don't try this at home (fringe optimization strategies)Write your own, stripped down XML parser or XSLT processorCustom program everythingRemove validation5.2. Strategies for integrating XML data validation5.2.1. XSD schemas or DTDs?When to use DTDs instead of XSD schemasWhen to use XSD schemas instead of DTDsAnother option: use both (side-by-side)Another option: use both (together)Another option: use neither5.2.2. Positioning DTDs in your architecture5.2.3. Positioning XSD schemas in your architectureXSD schemas as a validation layer within an applicationXSD schemas as a validation layer for cross-application communicationXSD schemas as an ancillary data technology5.2.4. Understand the syntactical limitations of XSD schemas5.2.5. Understand the performance limitations of XSD schemas5.2.6. Other fish in the sea (more schema definition languages)5.2.7. Supplementing XSD schema validationUse XSLT to enforce validationCustom program validation routines within application componentsApplication-specific annotations5.2.8. Integrating XML validation into a distributed architecture5.2.9. Avoiding over-validation5.2.10. Consider targeted validation5.2.11. Building modular and extensible XSD schemas5.2.12. Understand the integration limitations of your databaseDatabases with no XML supportDatabases for which third-party products provide XML supportDatabases with XML extensionsDatabases with native XML support5.3. Strategies for integrating XML schema administration5.3.1. XML schemas and the silent disparity pattern5.3.2. A step-by-step XWIF processStep 1: Assign ownershipStep 2: Identify sources of auto-generated schemas and standardize the relevant tool setStep 3: Standardize on official XML schemasStep 4: Create an application review processStep 5: Create a development and maintenance processStep 6: Communicate the process, standards, and technologyStep 7: Version control your schemas5.4. Strategies for integrating XML transformation5.4.1. Positioning XSLT in your architectureXSLT as a transformation technology within an applicationXSLT as a presentation unifier for a single applicationXSLT as a transformation technology between applicationsXSLT as a presentation unifier for multiple applications5.4.2. Pre-transform for static caching5.4.3. Create dynamic XSLT style sheets5.4.4. Simplify aesthetic transformation with CSS5.4.5. Understand the scalability limitations of XSLT5.4.6. Strategic redundancy5.5. Strategies for integrating XML data querying5.5.1. Positioning XQuery in your architectureXQuery as a query technology within an applicationXQuery as a query technology across application data sources5.5.2. Multi-data source abstraction5.5.3. Establishing a data policy management layer5.5.4. Unifying documents and data

6. Integrating Web services into applications
6.1. Service models6.1.1. Utility services6.1.2. Business services6.1.3. Controller services6.2. Modeling service-oriented component classes and Web service interfaces6.2.1. Designing service-oriented component classes (a step-by-step XWIF process)Step 1: Take inventory of business component classesStep 2: Identify logic for which Web service support is limitedStep 3: Identify opportunities for reuseStep 4: Identify interface dependenciesStep 5: Determine levels of interoperabilityStep 6: Create granular, task-oriented classesStep 7: Group methods based on typeStep 8: Identify service encapsulation candidatesStep 9: Review non-service classesStep 10: Identify cross-task consolidation opportunities6.2.2. Designing Web service interfaces (a step-by-step XWIF process)Step 1: Choose a service modelStep 2: Establish the scope of the service's business functionStep 3: Identify known and potential service requestorsStep 4: Identify the required data bodiesStep 5: Explore application pathsStep 6: Define the encapsulation boundaryStep 7: Model the service interfaceStep 8: Map out interaction scenariosStep 9: Design the message payloadStep 10: Refine the service model6.3. Strategies for integrating service-oriented encapsulation6.3.1. Define criteria for consistent logic encapsulation and interface granularity6.3.2. Establish a standard naming convention6.3.3. Parameter-driven vs. operation-oriented interfaces6.3.4. Designing for diverse granularity6.3.5. Utilize generic services consistently6.3.6. Establish separate standards for internal and external servicesInternal servicesExternal servicesStructuring enterprise standards6.3.7. Considering third-party Web services6.4. Strategies for integrating service assemblies6.4.1. Everything in moderation, including service assembliesDependenciesPerformance6.4.2. Modeling service assemblies6.4.3. Compound service assemblies6.5. Strategies for enhancing service functionality6.5.1. Outputting user-interface information6.5.2. Caching more than textual data6.5.3. Streamlining the service design with usage patternsAnticipated cachingProcess refinementReducing usage errorsUsage patterns for service requestors6.6. Strategies for integrating SOAP messaging6.6.1. SOAP message performance management6.6.2. SOAP message compression techniques6.6.3. Security issues with SOAP messaging6.6.4. SOAP data types6.6.5. Easing into SOAP
7. Integrating XML and databases
7.1. Comparing XML and relational databases7.1.1. Data storage and security7.1.2. Data representation7.1.3. Data integrity and validation7.1.4. Data querying and indexing7.1.5. Additional features7.2. Integration architectures for XML and relational databases7.2.1. Storing XML documents as database records7.2.2. Storing XML document constructs as database records7.2.3. Using XML to represent a view of database queries7.2.4. Using XML to represent a view of a relational data model7.2.5. Using XML to represent relational data within an in-memory database (IMDB)7.3. Strategies for integrating XML with relational databases7.3.1. Target only the data you needPerformanceTask-oriented data representation7.3.2. Avoiding relationships by creating specialized data views7.3.3. Create XML-friendly database modelsAvoid granular tables and relationshipsSupport preformatted XML viewsConsider descriptive column namesAvoid composite keys7.3.4. Extending the schema model with annotations7.3.5. Non-XML data models in XML schemas7.3.6. Developing a caching strategy7.3.7. Querying the XSD schema7.3.8. Control XML output with XSLT7.3.9. Integrate XML with query limitations in mind7.3.10. Is a text file a legitimate repository?7.3.11. Loose coupling and developer skill sets7.4. Techniques for mapping XML to relational data7.4.1. Mapping XML documents to relational dataTable-based mappingTemplate-based mappingClass-based mapping7.4.2. The Bear Sightings application7.4.3. Intrinsic one-to-one and one-to-many relationships with XML7.4.4. Mapping XML to relational data with DTDsBasic table mapping with DTDsData type restrictions with DTDsNull restrictions with DTDsRepresenting relational tables with DTDsPrimary keys with DTDsForeign keys with DTDsRelationships with DTDsReferential integrity restrictions within DTDs7.4.5. Mapping XML to relational data with XSD schemasBasic table mapping with XSD schemasNull restrictions with XSD schemasPrimary keys with XSD schemasForeign keys with XSD schemasComposite keys with XSD schemasRelationships with XSD schemas7.5. Database extensions7.5.1. Proprietary extensions to SQL7.5.2. Proprietary versions of XML specifications7.5.3. Proprietary XML-to-database mapping7.5.4. XML output format7.5.5. Stored procedures7.5.6. Importing and exporting XML documents7.5.7. Encapsulating proprietary database extensions within Web services7.6. Native XML databases7.6.1. Storage of document-centric data7.6.2. Integrated XML schema models7.6.3. Queries and data retrieval7.6.4. Native XML databases for intermediary storage
III. Integrating applications
8. The mechanics of application integration
8.1. Understanding application integration8.1.1. Types of integration projects8.1.2. Typical integration requirements8.1.3. Progress versus impact8.1.4. Types of integration solutionsExtensions to an existing applicationNew business processes8.2. Integration levels8.2.1. Data-level integration8.2.2. Application-level integration8.2.3. Process-level integration8.2.4. Service-oriented integration8.3. A guide to middleware8.3.1. “EAI” versus “middleware”8.3.2. Shredding the Oreo8.3.3. Common middleware services and productsData access technologyDistributed technologyMessage queues and message-oriented middlewareApplication servers and transaction monitorsIntegration brokers8.3.4. A checklist for buying middlewareUnderstand the range of supported integration modelsBeware industry-specific middleware solutionsMake sure the product manufacturer is progressiveBusiness process mapping features are criticalDeployment and integration effortMaintenance considerationsUsability of administration tools are importantScalability considerations8.4. Choosing an integration path8.4.1. Two paths, one destination8.4.2. Moving to EAI8.4.3. Common mythsMyth #1: The sooner the betterMyth #2: If you buy, you comply8.4.4. The impact of an upgradeUpgrading integration solutions is expensiveUpgrading integration solutions is time-consumingUpgrading integration solutions is disruptiveThe value may not always outweigh the cost8.4.5. Weighing your options
9. Service-oriented architectures for legacy integration
9.1. Service models for application integration9.1.1. Proxy services9.1.2. Wrapper services9.1.3. Coordination services (for atomic transactions)9.2. Fundamental integration components9.2.1. Adapters9.2.2. Intermediaries9.2.3. Interceptors9.3. Web services and one-way integration architectures9.3.1. Batch export and importTraditional architectureEncapsulating import and export functions within Web servicesArchitectural comparison matrix9.3.2. Direct data accessTraditional architectureEncapsulating data access within a Web serviceArchitectural comparison matrix9.4. Web services and point-to-point architectures9.4.1. Tightly coupled integration between homogenous legacy applicationsTraditional architectureEncapsulating legacy interfaces within Web servicesArchitectural comparison matrix9.4.2. Tightly coupled integration between heterogeneous applicationsTraditional architectureLoosely coupled integration with service integration layersArchitectural comparison matrix9.4.3. Integration between homogenous component-based applicationsTraditional architectureComponent-based architecture with Web servicesArchitectural comparison matrix9.4.4. Integration between heterogeneous component-based applicationsTraditional architectureComponent-based architecture with Web servicesArchitectural comparison matrix9.5. Web services and centralized database architectures9.5.1. Traditional architecture9.5.2. Using a Web service as a data access controllerArchitectural comparison matrix9.6. Service-oriented analysis for legacy architecturesStep 1: Define business requirements and expectationsStep 2: Assess adapter qualityStep 3: Identify required functionalityStep 4: Evaluate development tool supportStep 5: Estimate usage requirementsStep 6: Identify additional integration opportunitiesStep 7: Define a high level test strategyStep 8: Gauge the required skill setStep 9: Estimate the impactStep 10: Determine the costStep 11: Understand the alternativesStep 12: Justify the project
10. Service-oriented architectures for enterprise integration
10.1. Service models for enterprise integration architectures10.1.1. Process services10.1.2. Coordination services (for business activities)10.2. Fundamental enterprise integration architecture components10.2.1. BrokerData exchange with a broker componentStep 1: retrieve requested data from the source database (Figure 10.8)Step 2: validate source data using source schema (Figure 10.9)Step 3: broker the data format (Figure 10.10)Step 4: validate target data using target schema (Figure 10.11)Step 5: insert data into target database (Figure 10.12)10.2.2. OrchestrationData exchange with orchestrationStep 1: request data from orchestration (Figure 10.15)Step 2: request data from application (Figure 10.16)Step 3: return response to orchestration (Figure 10.17)Step 4: process orchestration logic (Figure 10.18)Step 5: forward data to requesting application (Figure 10.19)10.3. Web services and enterprise integration architectures10.4. Hub and spoke10.4.1. Traditional architecture10.4.2. Adding integration layers with Web services10.5. Messaging bus10.5.1. Traditional architecture10.5.2. Messaging bus solutions that utilize Web services10.6. Enterprise Service Bus (ESB)
11. Service-oriented integration strategies
11.1. Strategies for streamlining integration endpoint interfaces11.1.1. Make interfaces more generic11.1.2. Consolidate legacy interfaces11.1.3. Consolidate proxy interfaces11.1.4. Supplement legacy logic with external logic11.1.5. Add support for multiple data output formats11.1.6. Provide alternative interfaces for different SOAP clients11.2. Strategies for optimizing integration endpoint services11.2.1. Minimize the use of service intermediaries11.2.2. Consider using service interceptors11.2.3. Data processing delegation11.2.4. Caching the provider WSDL definition11.3. Strategies for integrating legacy architectures11.3.1. Create a transition architecture by adding partial integration layers11.3.2. Data caching with an IMDB11.3.3. Utilizing a queue to counter scalability demands11.3.4. Adding a mini-hub11.3.5. Abstract legacy adapter technology11.3.6. Leveraging legacy integration architectures11.3.7. Appending Web services to legacy integration architectures11.4. Strategies for enterprise solution integration11.4.1. Pragmatic service-oriented integration11.4.2. Integrating disparate EAI products11.4.3. Respect your elders (building EAI around your legacy environments)11.4.4. Build a private service registry11.5. Strategies for integrating Web services security11.5.1. Learn about the Web services security specifications11.5.2. Build services with a standardized service-oriented security (SOS) model11.5.3. Create a security services layer11.5.4. Beware remote third-party services11.5.5. Prepare for the performance impact11.5.6. Define an appropriate system for single sign-on11.5.7. Don't over-describe your services11.5.8. Fortify or retreat integrated legacy systems11.5.9. Take advantage of granular security11.5.10. Web services and port 8011.5.11. SOAP attachments and viruses11.5.12. Consider the development of security policies11.5.13. Don't wait to think about administration
IV. Integrating the enterprise
12. Thirty best practices for integrating XML
12.1. Best practices for planning XML migration projects12.1.1. Understand what you are getting yourself into12.1.2. Assess the technical impactA migration project is like a development projectWhat to look out forOne more thing…12.1.3. Invest in an XML impact analysisOne more thing…12.1.4. Assess the organizational impact12.1.5. Targeting legacy dataXML-enabling a legacy applicationMaking legacy applications XML-compliantOne more thing…12.2. Best practices for knowledge management within XML projects12.2.1. Always relate XML to dataClarity of conceptsCreate a custom glossaryOne more thing…12.2.2. Determine the extent of education required by your organization12.2.3. Customize a training planTake a course to learn XML fundamentalsDefine roles before assigning further trainingMake resources available to your technical staffSpend your training budget wiselyBring outside experts in for specialized knowledge transfer12.2.4. Incorporate mentoring into development projectsArrange a consult-and-mentor programGet suitable mentors12.3. Best practices for standardizing XML applications12.3.1. Incorporate standards12.3.2. Standardize, but don't over-standardize12.3.3. Define a schema management strategyUnderstand the importance of XML schemasAssign an XML data custodianOwnership of vocabulariesOwnership of data modelsNamespace domain administration12.3.4. Use XML to standardize data access logic12.3.5. Evaluate tools prior to integration12.4. Best practices for designing XML applications12.4.1. Develop a system for knowledge distribution12.4.2. Remember what the “X” stands for12.4.3. Design with service-oriented principles (even if not using Web services)12.4.4. Strive for a balanced integration strategyTightening the screwStripping the screw12.4.5. Understand the roles of supplementary XML technologiesDefine a core technology setIdentify second-tier technologies12.4.6. Adapt to new technology developments
13. Thirty best practices for integrating Web services
13.1. Best practices for planning service-oriented projects13.1.1. Know when to use Web services13.1.2. Know how to use Web services13.1.3. Know when to avoid Web services13.1.4. Moving forward with a transition architecture13.1.5. Leverage the legacyBuild on what you haveUnderstand the limitations of a legacy foundation13.1.6. Sorry, no refunds (Web services and your bottom line)13.1.7. Align ROIs with migration strategiesROIs open eyesIterating through ROI and migration strategy documents13.1.8. Build toward a future state13.2. Best practices for standardizing Web services13.2.1. Incorporate standards13.2.2. Label the infrastructureOne more thing13.2.3. Design against an interface (not vice versa)13.2.4. Service interface designer13.2.5. Categorize your services13.3. Best practices for designing service-oriented environments13.3.1. Use SOAs to streamline business models13.3.2. Research the state of second-generation specifications13.3.3. Strategically position second-generation specifications13.3.4. Understand the limitations of your platformProprietary extensions (the potholes)Exclusive proprietary extensions (the roadblocks)13.3.5. Use abstraction to protect legacy endpoints from changeUse abstraction to improve configuration managementUse abstraction to support wholesale application changes13.3.6. Build around a security modelSecurity requirements define boundaries, real boundariesDefine the scope of the security model13.4. Best practices for managing service-oriented development projects13.4.1. Organizing development resources13.4.2. Don't underestimate training for developers13.5. Best practices for implementing Web services13.5.1. Use a private service registryCentralize service descriptions in a service repositoryMake the use of a service registry mandatoryAssign a resource to maintain the registry13.5.2. Prepare for administration13.5.3. Monitor and respond to changes in the service hosting environments13.5.4. Test for the unknown
14. Building the service-oriented enterprise (SOE)
14.1. SOA modeling basics14.1.1. ActivitiesPrimitive business activityProcess activityBusiness activity14.1.2. ServicesPrimitive business serviceProcess serviceBusiness service14.1.3. Processes14.2. SOE building blocks14.2.1. SOE business modeling building blocksPrimitive business activityPrimitive business serviceThe primitive business processThe extended business processThe enterprise domain business processThe enterprise business process14.2.2. SOE technology architecture building blocksWeb service operationWeb serviceService-oriented application architectureService-oriented integration architectureService-oriented EAI architectureService-oriented enterprise integration architecture14.2.3. Service-oriented security model14.3. SOE migration strategy14.3.1. Overview of the Layered Scope Model (LSM)Obstacles to using the LSMApplying the LSMBefore you begin14.3.2. Intrinsic LayerThe service-oriented architecture (SOA) wedgeSo, why bother?Processes, best practices, and strategiesService modelsTechnologiesSOE building blocks14.3.3. Internal layerBuilding for a future stateThe service-oriented security (SOS) model wedgeProcesses, best practices, and strategiesService modelsTechnologiesSOE building blocks14.3.4. A2A layerBuilding for a future stateProcesses, best practices and strategiesService modelsTechnologiesSOE building blocks14.3.5. EAI layerBuilding for a future stateProcesses, best practices and strategiesService modelsTechnologiesSOE building blocks14.3.6. Enterprise layer14.3.7. The extended enterprise14.3.8. Customizing the LSM14.3.9. Alternatives to the LSM
About the Author
About the Photographs

Content preview from Service-Oriented Architecture: A Field Guide to Integrating XML and Web Services

Chapter 13. Thirty best practices for integrating Web services

Web services introduce technology layers that reside over those already established by the XML platform. Therefore, the best practices for XML provided in the previous chapter also apply to service-oriented environments. Additionally, the contents of this ...

Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.

Read now

Unlock full access

More than 5,000 organizations count on O’Reilly

O’Reilly covers everything we've got, with content to help us build a world-class technology community, upgrade the capabilities and competencies of our teams, and improve overall team performance as well as their engagement.

Julian F.

Head of Cybersecurity

I wanted to learn C and C++, but it didn't click for me until I picked up an O'Reilly book. When I went on the O’Reilly platform, I was astonished to find all the books there, plus live events and sandboxes so you could play around with the technology.

Addison B.

Field Engineer

I’ve been on the O’Reilly platform for more than eight years. I use a couple of learning platforms, but I'm on O'Reilly more than anybody else. When you're there, you start learning. I'm never disappointed.

Amir M.

Data Platform Tech Lead

I'm always learning. So when I got on to O'Reilly, I was like a kid in a candy store. There are playlists. There are answers. There's on-demand training. It's worth its weight in gold, in terms of what it allows me to do.

Mark W.

Embedded Software Engineer

Web Services Platform Architecture: SOAP, WSDL, WS-Policy, WS-Addressing, WS-BPEL, WS-Reliable Messaging, and More

Publisher Resources

ISBN: 0131428985Purchase book

Cloud Computing

Data Engineering

Data Science

AI & ML

Programming Languages

Software Architecture

IT/Ops

Security

Design

Business

Soft Skills

Service-Oriented Architecture: A Field Guide to Integrating XML and Web Services

by Thomas Erl

Chapter 13. Thirty best practices for integrating Web services

Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.