[The Prentice Hall Service Technology Series from Thomas Erl 01] • Service-Oriented Architecture · A Field Guide to Integrating XML and Web Services by Erl, Thomas -- Read -- Imperial Library of Trantor

Index

Cover Contents Copyright About Prentice Hall Professional Technical Reference Preface Acknowledgments Chapter 1. Introduction

1.1 Why this guide is important

1.1.1 The hammer and XML 1.1.2 XML and Web services 1.1.3 Web services and Service-Oriented Architecture 1.1.4 Service-Oriented Architecture and the hammer 1.1.5 The hammer and you

1.2 The XML & Web Services Integration Framework (XWIF)

Table 1.1. An Overview of XWIF

1.3 How this guide is organized

Figure 1.1. Three categories representing Parts II, III, and IV of this guide. 1.3.1 Part I: The technical landscape

Table 1.2. Reference Matrix of Technology Tutorials

1.3.2 Part II: Integrating technology

Figure 1.2. The three chapters in Part II roughly correspond to the three backend tiers of a distributed application architecture. Integrating XML into applications (Chapter 5) Integrating Web services into applications (Chapter 6) Integrating XML and databases (Chapter 7)

1.3.3 Part III: Integrating applications

Figure 1.3. The architectural scopes of Part III chapters. The 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 enterprise

Thirty 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 enterprise

1.4 www.serviceoriented.ws 1.5 Contact the author

Part I: The technical landscape

Chapter 2. Introduction to XML technologies

Figure 2.1. Relationship between XML specifications. 2.1 Extensible Markup Language (XML)

2.1.1 Concepts

Elements, Documents, and Vocabularies Figure 2.2. The standard symbol used by this book to represent an XML document.

2.1.2 Schemas

Figure 2.3. How XML schemas relate to XML documents.

2.1.3 Programming models 2.1.4 Syntax

Example 2.1. The XML declaration Example 2.2. A simple parent-child relationship between elements Example 2.3. An element with an attribute Example 2.4. A document type declaration Example 2.5. A complete XML document

2.2 Document Type Definitions (DTD)

2.2.1 Concepts

Figure 2.4. The standard symbol used by this book to represent an XML schema, in this case a DTD.

2.2.2 Syntax

Example 2.6. A declaration of a document type definition Example 2.7. A DOCTYPE definition Example 2.8. Three elements are declared — one as the parent, the other two as its children Example 2.9. The category attribute is provided with a list of allowable values Example 2.10. The closing DOCTYPE statement Example 2.11. A complete document type definition Example 2.12. Look familiar? This document is the same one we built in the previous XML tutorial.

2.3 XML Schema Definition Language (XSD)

2.3.1 Concepts

Figure 2.5. The standard symbol used by this book to represent an XML schema, in this case an XSD schema. Figure 2.6. A schema document hosting multiple schema definitions. Figure 2.7. The schema data model being extended by a supplementary construct. Figure 2.8. Part of a schema definition being overridden by a supplementary construct.

2.3.2 Syntax

Example 2.13. The schema element used to establish the schema Example 2.14. These statements open the construct establishing the parent book element Example 2.15. The child title and author elements have simple types within the complexType construct Example 2.16. The category attribute receives its own simpleType construct wherein a list of allowable values is set Example 2.17. The book element declaration is completed Example 2.18. The schema ends with the closing element Example 2.19. A complete XSD schema definition Example 2.20. An XML document based on our schema definition

2.4 Extensible Stylesheet Language Transformations (XSLT)

Figure 2.9. The standard symbol used by this book to represent XSLT style sheets. 2.4.1 Concepts

Structural transformation Figure 2.10. An XSLT style sheet is used to transform XML document types. Aesthetic transformation Figure 2.11. XSLT style sheets used to transform an XML document into different presentation renditions.

2.4.2 Syntax

Example 2.21. An expanded version of the XML document we've been using in previous tutorials Example 2.22. A style sheet declaration Example 2.23. XSLT template header declarations Example 2.24. A template construct that establishes the scope of the template Example 2.25. A loop construct that supplements filtered data with HTML tags Example 2.26. The final statement in the template Example 2.27. The complete template

2.5 XML Query Language (XQuery)

2.5.1 Concepts

Figure 2.12. The standard symbol used by this book to represent an XQuery module. Figure 2.13. An XQuery module hosting multiple XQuery functions. Figure 2.14. An XQuery expression embedded within an XML document. Figure 2.15. A single query against multiple data sources returns an XML document with a unique context.

2.5.2 Syntax

Example 2.28. A for clause starting off our query statement Example 2.29. The where keyword used to define search criteria Example 2.30. The return keyword specifying the requested output values Example 2.31. A complete XQuery statement Example 2.32. The XML document acting as our data source Example 2.33. The query result

2.6 XML Path Language (XPath)

2.6.1 Concepts

Figure 2.16. XPath expressions used within XQuery modules and XSLT style sheets. Figure 2.17. The XPath 2.0, XQuery 1.0 and XSLT 2.0 specifications sharing the same data model.

2.6.2 Syntax

Example 2.34. A statement identifying elements or nodes within a document Example 2.35. An expression restricting the criteria to the title element(s) Example 2.36. An example of a slightly more complex XPath expression

Chapter 3. Introduction to Web services technologies

Figure 3.1. The relationship between first-generation specifications. 3.1 Web services and the service-oriented architecture (SOA)

3.1.1 Understanding services 3.1.2 XML Web services

Figure 3.2. Web services swapping roles during a conversation.

3.1.3 Service-oriented architecture (SOA)

Figure 3.3. A logical representation of a service-oriented architecture (for a single multi-tier application). Figure 3.4. A logical representation of a service-oriented integration architecture.

3.1.4 Web service roles

Service provider Figure 3.5. A service provider receiving a request from a service requestor. Service requestor Figure 3.6. A service requestor initiating a request to a service provider. Intermediary Figure 3.7. An intermediary service transitioning through two roles while relaying a message. Initial sender Figure 3.8. The first Web service is identified as the initial sender. Ultimate receiver Figure 3.9. A service acting as the ultimate receiver.

3.1.5 Web service interaction

Message path Figure 3.10. A message path consisting of three Web services. Figure 3.11. A message determined dynamically by a routing intermediary. Message exchange pattern Figure 3.12. Example of a request and response message exchange pattern. Correlation Figure 3.13. Correlation used in a request and response message exchange pattern. Choreography Figure 3.14. The interaction sequence of a group of services being governed by a choreography. Activity Figure 3.15. A service activity involving three services.

3.1.6 Service models

Table 3.1. Service models and the locations of their respective descriptions within this book

3.1.7 Web service description structure

Figure 3.16. Contents of a service description. Abstract Concrete Service definition Service description

3.1.8 Introduction to first-generation Web services

3.2 Web Services Definition Language (WSDL)

Figure 3.17. WSDL documents representing Web services to applications. Example 3.1. A service definition, as expressed by the definitions construct Figure 3.18. The contents of a WSDL document, as they relate to a service definition. 3.2.1 Abstract interface definition

Example 3.2. A Web service interface represented by the interface element Example 3.3. The input element within an operation construct referencing a message block Example 3.4. A message block with part constructs representing operation parameters

3.2.2 Concrete (implementation) definition

Example 3.5. The endpoint element Example 3.6. The binding element representing an existing operation

3.2.3 Supplementary constructs

Example 3.7. The types element establishing XSD data types Example 3.8. The documentation element allows you to supplement service definitions with annotations

3.3 Simple Object Access Protocol (SOAP)

Figure 3.19. SOAP establishes two primary standard message formats. Figure 3.20. The symbol used to represent a SOAP message with a document-centric payload. Figure 3.21. The symbol used to represent a SOAP message with an RPC-centric payload. Figure 3.22. The symbol used to represent a SOAP message delivering its data as an attachment. 3.3.1 SOAP messaging framework

SOAP nodes Figure 3.23. A SOAP node. SOAP node types Figure 3.24. Fundamental SOAP node types along a message path. Figure 3.25. SOAP nodes with multiple types. Figure 3.26. A SOAP node going through the transition of being a SOAP receiver and sender during the processing of a SOAP message.

3.3.2 SOAP message structure

Example 3.9. A skeleton envelope construct Example 3.10. The Header construct with a header block Example 3.11. The Body construct Example 3.12. A sample fault construct providing error information SOAP node roles Figure 3.27. Roles that can be assumed by receiving SOAP nodes

3.4 Universal Description, Discovery, and Integration (UDDI)

Figure 3.28. Service descriptions centralized in a private UDDI registry Example 3.13. An actual business entity document retrieved from a public service registry Example 3.14. The parent businessEntity element with a number of attributes Example 3.15. The discoveryURLs construct containing the original URL Example 3.16. The name element providing the business name Example 3.17. The businessServices construct Example 3.18. The businessService element's serviceKey and businessKey attributes Example 3.19. The name element with the service name Example 3.20. The bindingTemplates construct housing concrete location information Example 3.21. The categoryBag element providing a categorization using the nested keyedReference element Example 3.22. The find_business construct encasing a command for the UDDI inquiry API

Chapter 4. Introduction to second-generation (WS-*) Web services technologies

4.1 Second-generation Web services and the service-oriented enterprise (SOE)

Figure 4.1. Second-generation specifications and the SOE. 4.1.1 Problems solved by second-generation specifications

Context and transaction management Business processes Security Reliable messaging Policies Attachments

4.1.2 The second-generation landscape

Figure 4.2. High-level relationships between first- and second-generation standards.

4.2 WS-Coordination and WS-Transaction

4.2.1 Concepts

Figure 4.3. A WS-Coordination service keeping track of an activity's coordination context. Figure 4.4. A coordinator service used to manage a coordination context. Atomic transactions Business activities

4.2.2 Syntax

Example 4.1. A message construct used to request the creation of a context

4.3 Business Process Execution Language for Web Services (BPEL4WS)

4.3.1 Recent business process specifications 4.3.2 Concepts

Figure 4.5. Two applications integrated and managed through the introduction of a BPEL4WS process service. BPEL4WS and WSDL BPEL4WS and WS-Coordination/WS-Transaction Figure 4.6. A coordination service used to manage a coordination context for long running business activities. BPEL4WS and other specifications Partner services Figure 4.7. An external partner service accessing a process service. Figure 4.8. After being accessed by the external partner service, the process service invokes another service. Process instances Process descriptions Basic activities Structured activities Service interaction Figure 4.9. Basic activities involved in a simple interaction scenario.

4.3.3 Syntax

Process element Example 4.2. A skeleton BPEL4WS process definition partnerLinks element Example 4.3. Definition of service partners within a BPEL4WS process description Variables element Example 4.4. A variable declaration within the variables construct faultHandlers element Example 4.5. The faultHandlers construct consisting of nested catch constructs Sequence element Example 4.6. The sequence parent construct establishing the order of nested basic activities Figure 4.10. Basic activities involved in a simple interaction scenario.

4.4 WS-Security and the Web services security specifications

4.4.1 General security concepts

Identification Figure 4.11. The identification of the sender by the recipient. Authentication Figure 4.12. The authentication of the sender by the recipient. Authorization Figure 4.13. The recipient assesses the authorization level of the sender. Integrity Figure 4.14. The integrity of a message is questioned by the recipient. Confidentiality Figure 4.15. The confidentiality of a message is questioned by the recipient.

4.4.2 Specifications

Table 4.1. Web services security specifications and their roles

4.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 Passport 4.4.6 XML-Encryption and XML-Digital Signatures 4.4.7 Secure Sockets Layer (SSL)

Figure 4.16. A message path with multiple intermediary services representing gaps in the protection provided by transport-level security.

4.4.8 The WS-Security framework

End-to-end and message-level security Figure 4.17. The scope of end-to-end versus point-to-point security. Specifications Table 4.2. An overview of WS-Security specifications WS-Policy WS-Trust WS-Privacy WS-SecureConversation WS-Federation WS-Authorization

4.4.9 Concepts and syntax

Claims and security tokens Figure 4.18. WS-Security allows for claims to be represented within standard security tokens. Example 4.7. The security construct hosting a security token

4.5 WS-ReliableMessaging

4.5.1 WS-Addressing 4.5.2 Concepts

Figure 4.19. The WS-ReliableMessaging mechanism for communicating the successful delivery of a SOAP message. Sequences Delivery assurances Figure 4.20. In this scenario, the AtMostOnce delivery assurance allows the failed delivery of a message that is not followed up with another transmission attempt. Figure 4.21. The AtLeastOnce assurance allowing a message to be sent twice. Figure 4.22. Here, a failed delivery is followed by another delivery attempt, which this time succeeds. Figure 4.23. set of messages being transmitted in a predefined sequence.

4.5.3 Acknowledgements

Figure 4.24. The successful delivery of a message being confirmed with an acknowledgement. Figure 4.25. Only one acknowledgement is sent in response to receiving a number of messages in the same sequence.

4.5.4 Syntax

Sequence Example 4.8. The sequence construct SequenceAcknowledgement Example 4.9. A SequenceAcknowledgement construct providing a list of successfully delivered messages Example 4.10. The SequenceAcknowledgement construct hosting multiple AcknowledgementRange elements to communicate what parts of a sequence were delivered

4.6 WS-Policy

4.6.1 Concepts 4.6.2 Syntax

Example 4.11. The sequence construct from the WS-ReliableMessaging example Example 4.12. The PolicyAttachment construct establishing a policy and linking it to the sequence

4.7 WS-Attachments

Figure 4.26. A SOAP message delivering a set of data as an attachment. SOAP Messages with Attachments (SwA)

Part II: Integrating technology

Chapter 5. Integrating XML into applications

5.1 Strategies for integrating XML data representation

5.1.1 Positioning XML data representation in your architecture

XML as a data transport format within applications Figure 5.1. XML can establish a standard data transport format within and between application tiers. XML as a data transport format between applications Figure 5.2. XML documents can be used as the standard data transport throughout integrated environments. XML as a data bridge within applications Figure 5.3. An XML document capturing data retrieved from three data sources in a unique business context. XML as a data bridge across applications Figure 5.4. An XML document capturing data retrieved from three data sources across two applications.

5.1.2 Think "tree" (a new way of representing data) 5.1.3 Easy now… (don't rush the XML document model)

Figure 5.5. XML documents and databases both represent data for applications, using schemas.

5.1.4 Design with foresight 5.1.5 Focus on extensibility and reusability 5.1.6 Lose weight while modeling! (keeping your documents trim)

Figure 5.6. XML document is filtered by an XSLT style sheet.

5.1.7 Naming element-types: performance vs. legibility 5.1.8 Applying XML consistently 5.1.9 Choosing the right API (DOM vs. SAX vs. Data Binding) 5.1.10 Securing XML documents 5.1.11 Pick the right tools

Review auto-generated markup and code Identify proprietary markup and code Look for proprietary file types Understand the orientation of the tool Assess the quality of conversion features Evaluate functional features Understand programmatic extensions Look for quality feedback Consider existing toolsets

5.1.12 Don't try this at home (fringe optimization strategies)

Write your own, stripped down XML parser or XSLT processor Custom program everything Remove validation

5.2 Strategies for integrating XML data validation

5.2.1 XSD schemas or DTDs?

When to use DTDs instead of XSD schemas Figure 5.7. Using DTDs instead of XSD schemas. When to use XSD schemas instead of DTDs Figure 5.8. Using XSD schemas instead of DTDs. Another option: use both (side-by-side) Figure 5.9. Using XSD schemas alongside DTDs. Another option: use both (together) Figure 5.10. Combining the use of DTDs and XSD schemas. Another option: use neither Figure 5.11. Using an alternative schema technology.

5.2.2 Positioning DTDs in your architecture

Figure 5.12. XML documents and associated DTD schema definitions within an n-tier application environment. Figure 5.13. Some areas where DTD schema definitions may be found within integration architectures.

5.2.3 Positioning XSD schemas in your architecture

XSD schemas as a validation layer within an application Figure 5.14. XSD establishing a validation layer. XSD schemas as a validation layer for cross-application communication Figure 5.15. XSD schemas can establish and validate XML data models throughout integration architectures. Figure 5.16. XSD schemas validating incoming data for each application endpoint. XSD schemas as an ancillary data technology Figure 5.17. XSD features used by WSDL, XSLT, and SOAP.

5.2.4 Understand the syntactical limitations of XSD schemas 5.2.5 Understand the performance limitations of XSD schemas

Figure 5.18. Typical XSD schemas require a great deal of markup.

5.2.6 Other fish in the sea (more schema definition languages) 5.2.7 Supplementing XSD schema validation

Use XSLT to enforce validation Custom program validation routines within application components Application-specific annotations

5.2.8 Integrating XML validation into a distributed architecture

Figure 5.19. A physical architecture with redundant schema files. Figure 5.20. A physical architecture illustrating schemas stored in memory.

5.2.9 Avoiding over-validation

Figure 5.21. An application design wherein XML documents are over-validated. Figure 5.22. Before validation, XML documents are checked to determine whether they were altered since the last validation.

5.2.10 Consider targeted validation

Figure 5.23. A schema designed to validate only a specific part of an XML document.

5.2.11 Building modular and extensible XSD schemas

Figure 5.24. An application builds an XML document and the associated schema at runtime.

5.2.12 Understand the integration limitations of your database

Databases with no XML support Databases for which third-party products provide XML support Databases with XML extensions Databases with native XML support

5.3 Strategies for integrating XML schema administration

5.3.1 XML schemas and the silent disparity pattern 5.3.2 A step-by-step XWIF process

Figure 5.25. An XWIF process for integrating schema administration. Step 1: Assign ownership Step 2: Identify sources of auto-generated schemas and standardize the relevant tool set Step 3: Standardize on official XML schemas Step 4: Create an application review process Step 5: Create a development and maintenance process Step 6: Communicate the process, standards, and technology Step 7: Version control your schemas

5.4 Strategies for integrating XML transformation

5.4.1 Positioning XSLT in your architecture

XSLT as a transformation technology within an application Figure 5.26. XSLT is used to transform XML documents to and from different types. XSLT as a presentation unifier for a single application Figure 5.27. An application using XSLT style sheets to support two different aesthetic output formats. XSLT as a transformation technology between applications Figure 5.28. XSLT can perform dynamic structural transformations. XSLT as a presentation unifier for multiple applications Figure 5.29. Presentation centric transformations can be incorporated to output data for different mediums.

5.4.2 Pre-transform for static caching 5.4.3 Create dynamic XSLT style sheets 5.4.4 Simplify aesthetic transformation with CSS 5.4.5 Understand the scalability limitations of XSLT 5.4.6 Strategic redundancy

5.5 Strategies for integrating XML data querying

5.5.1 Positioning XQuery in your architecture

XQuery as a query technology within an application Figure 5.30. An XQuery module positioned to query multiple data sources within a single application environment. XQuery as a query technology across application data sources Figure 5.31. An XQuery returning results from multiple data sources across application domains.

5.5.2 Multi-data source abstraction

Figure 5.32. XQuery providing a central data access point for legacy repositories in support of a single application.

5.5.3 Establishing a data policy management layer

Figure 5.33. XQuery establishing a central data management layer for a number of applications.

5.5.4 Unifying documents and data

Figure 5.34. Traditional information segregation. Figure 5.35. Unified information access architecture.

Chapter 6. Integrating Web services into applications

6.1 Service models

6.1.1 Utility services

Figure 6.1. The utility service model. Figure 6.2. A utility service being shared by other Web services. Figure 6.3. A remote third-party utility service being incorporated by an application. Table 6.1. Typical characteristics of utility services

6.1.2 Business services

Figure 6.4. The business service model.

6.1.3 Controller services

Table 6.2. Typical characteristics of business services Figure 6.5. The business service model. Figure 6.6. A controller service interacting with various other services to execute a business function. Table 6.3. Typical characteristics of controller services

6.2 Modeling service-oriented component classes and Web service interfaces

6.2.1 Designing service-oriented component classes (a step-by-step XWIF process)

Figure 6.7. An XWIF process for modeling service-oriented components. Step 1: Take inventory of business component classes Figure 6.8. The planned set of application classes. Step 2: Identify logic for which Web service support is limited Figure 6.9. Two methods have been identified. Figure 6.10. The GetInvoiceHistory method is tagged with a different icon. Step 3: Identify opportunities for reuse Figure 6.11. A reusable class method is discovered and labeled. Step 4: Identify interface dependencies Figure 6.12. An internal dependency between class methods is highlighted. Step 5: Determine levels of interoperability Figure 6.13. A method that will most certainly be involved in an external data interchange is identified. Step 6: Create granular, task-oriented classes Figure 6.14. The methods in the original class have been distributed into three smaller classes. Step 7: Group methods based on type Figure 6.15. Three more classes now represent the original collection of methods. Step 8: Identify service encapsulation candidates Figure 6.16. Four candidates have been identified. Step 9: Review non-service classes Step 10: Identify cross-task consolidation opportunities Figure 6.17. Methods have been added to utility service candidates.

6.2.2 Designing Web service interfaces (a step-by-step XWIF process)

Figure 6.18. An XWIF process for modeling service interfaces. Step 1: Choose a service model Step 2: Establish the scope of the service's business function Step 3: Identify known and potential service requestors Step 4: Identify the required data bodies Step 5: Explore application paths Step 6: Define the encapsulation boundary Figure 6.19. The utility service boundary encapsulates one component class. Figure 6.20. The business service boundary encapsulates two component classes. Step 7: Model the service interface Figure 6.21. A utility service interface evolving out of its encapsulated functionality. Figure 6.22. A business service interface representing two component classes. Step 8: Map out interaction scenarios Figure 6.23. Executing the GetHistory operation requires interaction with the GetReports class' GetInvoiceHistory and GetPOHistory methods. Figure 6.24. The GetInvoice operation interacts only with the GetInvoice class, whereas the LastReviewed operation interacts with the ProcessInvoice class. Step 9: Design the message payload Step 10: Refine the service model

6.3 Strategies for integrating service-oriented encapsulation

6.3.1 Define criteria for consistent logic encapsulation and interface granularity 6.3.2 Establish a standard naming convention 6.3.3 Parameter-driven vs. operation-oriented interfaces

Figure 6.25. A generic parameter-driven operation provides a cleaner, but less user-friendly interface.

6.3.4 Designing for diverse granularity

Figure 6.26. Examples of coarse- and fine-grained service interfaces. Figure 6.27. A single service interface providing a coarse operation and several fine-grained operations.

6.3.5 Utilize generic services consistently 6.3.6 Establish separate standards for internal and external services

Internal services External services Structuring enterprise standards

6.3.7 Considering third-party Web services

6.4 Strategies for integrating service assemblies

6.4.1 Everything in moderation, including service assemblies

Dependencies Performance

6.4.2 Modeling service assemblies

Figure 6.28. With a coarse parent service, the requestor requires only one call to retrieve the invoice. Figure 6.29. A service requestor needing only the invoice status also receives the invoice header and details. Figure 6.30. Each service requestor receives only the data it needs. Figure 6.31. An assembly fronted by a parameter-driven controller service interface.

6.4.3 Compound service assemblies

Figure 6.32. A service assembly, where a service enlists services or components from different businesses processes. Figure 6.33. A service assembly, where a business service utilizes generic services or components.

6.5 Strategies for enhancing service functionality

6.5.1 Outputting user-interface information 6.5.2 Caching more than textual data 6.5.3 Streamlining the service design with usage patterns

Anticipated caching Process refinement Reducing usage errors Usage patterns for service requestors

6.6 Strategies for integrating SOAP messaging

6.6.1 SOAP message performance management 6.6.2 SOAP message compression techniques

Figure 6.34. The message size for the data request is much smaller than the response message containing the data. Figure 6.35. The message size for the data submission is much larger than the response message containing a return code. Figure 6.36. Only the response message is compressed. Figure 6.37. Only the data submission message is compressed.

6.6.3 Security issues with SOAP messaging 6.6.4 SOAP data types 6.6.5 Easing into SOAP

Chapter 7. Integrating XML and databases

Figure 7.1. Application components and databases have different data format preferences. 7.1 Comparing XML and relational databases

7.1.1 Data storage and security

Table 7.1. Data storage and security comparison

7.1.2 Data representation

Table 7.2. Data representation comparison

7.1.3 Data integrity and validation 7.1.4 Data querying and indexing 7.1.5 Additional features

Table 7.3. Data validation comparison

7.2 Integration architectures for XML and relational databases

Table 7.4. Data querying and indexing comparison Table 7.5. Comparison of various additional features 7.2.1 Storing XML documents as database records

Figure 7.2. A physical architecture illustrating XML documents being stored and retrieved from a relational database. Figure 7.3. A variation of this architecture, where schemas are stored alongside XML documents, within the database.

7.2.2 Storing XML document constructs as database records

Figure 7.4. A physical architecture where XML constructs are stored independently in a relational database, and then assembled into a complete XML document at runtime by the application. Figure 7.5. Schema modules are stored and assembled alongside XML document constructs in the database.

7.2.3 Using XML to represent a view of database queries

Figure 7.6. In this physical architecture, the requested data is returned in the format of an XML document by the database.

7.2.4 Using XML to represent a view of a relational data model

Figure 7.7. A physical architecture illustrating the use of a data map to represent relational data within an XML document.

7.2.5 Using XML to represent relational data within an in-memory database (IMDB)

Figure 7.8. A physical architecture in which XML data is cached in memory.

7.3 Strategies for integrating XML with relational databases

7.3.1 Target only the data you need

Performance Task-oriented data representation

7.3.2 Avoiding relationships by creating specialized data views 7.3.3 Create XML-friendly database models

Avoid granular tables and relationships Support preformatted XML views Consider descriptive column names Avoid composite keys

7.3.4 Extending the schema model with annotations 7.3.5 Non-XML data models in XML schemas 7.3.6 Developing a caching strategy 7.3.7 Querying the XSD schema

Figure 7.9. Application components can query the XSD schema file as they would any other XML document.

7.3.8 Control XML output with XSLT

Figure 7.10. The structure of an XML document is transformed to represent different sort orders.

7.3.9 Integrate XML with query limitations in mind 7.3.10 Is a text file a legitimate repository? 7.3.11 Loose coupling and developer skill sets

7.4 Techniques for mapping XML to relational data

7.4.1 Mapping XML documents to relational data

Table-based mapping Template-based mapping Class-based mapping

7.4.2 The Bear Sightings application

Figure 7.11. The application data model of the Bear Sightings database consists of two simple, related tables.

7.4.3 Intrinsic one-to-one and one-to-many relationships with XML

Figure 7.12. An intrinsic one-to-many relationship established within an element-centric XML document instance. Figure 7.13. An intrinsic one-to-many relationship established within an attribute-centric XML document instance.

7.4.4 Mapping XML to relational data with DTDs

Basic table mapping with DTDs Figure 7.14. A DTD containing a parent element for each table. Data type restrictions with DTDs Example 7.1. An element instance with a custom attribute identifying the original data type Null restrictions with DTDs Example 7.2. An element instance indicating a null value through the use of a pre-assigned code Representing relational tables with DTDs Primary keys with DTDs Example 7.3. An element type declaration with an ID attribute Example 7.4. A primary key represented by the ID attribute Foreign keys with DTDs Example 7.5. An element type declaration containing a foreign key reference Relationships with DTDs Figure 7.15. A one-to-many relationship using ID and IDREF. Figure 7.16. A DTD establishing ID and IDREF attributes. Figure 7.17. A different one-to-many relationship using ID and IDREF. Figure 7.18. DTD providing ID and IDREFS attributes. Example 7.6. An element type declaration restricting a child element to zero or one occurrence Referential integrity restrictions within DTDs

7.4.5 Mapping XML to relational data with XSD schemas

Basic table mapping with XSD schemas Example 7.7. An element declaration representing three columns from a relational table Null restrictions with XSD schemas Primary keys with XSD schemas Example 7.8. The XSD schema unique element Example 7.9. The XSD schema key element Foreign keys with XSD schemas Example 7.10. The XSD schema keyref element Composite keys with XSD schemas Example 7.11. A composite key created by multiple field elements Relationships with XSD schemas Figure 7.19. A document instance with a one-to-many relationship enforced by an XSD schema. Example 7.12. An XSD schema enforcing constraints with key and keyref Figure 7.20. A one-to-many relationship using key and keyref.

7.5 Database extensions

7.5.1 Proprietary extensions to SQL 7.5.2 Proprietary versions of XML specifications 7.5.3 Proprietary XML-to-database mapping 7.5.4 XML output format 7.5.5 Stored procedures 7.5.6 Importing and exporting XML documents 7.5.7 Encapsulating proprietary database extensions within Web services

7.6 Native XML databases

7.6.1 Storage of document-centric data 7.6.2 Integrated XML schema models 7.6.3 Queries and data retrieval 7.6.4 Native XML databases for intermediary storage

Figure 7.21. A native XML database acting as a physical cache for non-durable XML document data.

Part III: Integrating applications

Chapter 8. The mechanics of application integration

8.1 Understanding application integration

8.1.1 Types of integration projects 8.1.2 Typical integration requirements 8.1.3 Progress versus impact 8.1.4 Types of integration solutions

Extensions to an existing application Figure 8.1. Integration in a homogenous environment. Figure 8.2. Integration challenges with disparate applications. New business processes Figure 8.3. Integration challenges when imposing a new business process that involves disparate applications.

8.2 Integration levels

Figure 8.4. The fundamental integration levels. 8.2.1 Data-level integration

Figure 8.5. Data-level integration where application A directly accesses application B's repository. Figure 8.6. Data-level integration where application B replicates data to application A's repository.

8.2.2 Application-level integration

Figure 8.7. Point-to-point application-level integration.

8.2.3 Process-level integration

Figure 8.8. A basic EAI architecture.

8.2.4 Service-oriented integration

Figure 8.9. Integration layers establishing a service-oriented integration architecture.

8.3 A guide to middleware

8.3.1 "EAI" versus "middleware" 8.3.2 Shredding the Oreo 8.3.3 Common middleware services and products

Data access technology Distributed technology Message queues and message-oriented middleware Application servers and transaction monitors Integration brokers

8.3.4 A checklist for buying middleware

Understand the range of supported integration models Beware industry-specific middleware solutions Make sure the product manufacturer is progressive Business process mapping features are critical Deployment and integration effort Maintenance considerations Usability of administration tools are important Scalability considerations

8.4 Choosing an integration path

8.4.1 Two paths, one destination 8.4.2 Moving to EAI 8.4.3 Common myths

Myth #1: The sooner the better Myth #2: If you buy, you comply

8.4.4 The impact of an upgrade

Upgrading integration solutions is expensive Upgrading integration solutions is time-consuming Upgrading integration solutions is disruptive The value may not always outweigh the cost

8.4.5 Weighing your options

Chapter 9. Service-oriented architectures for legacy integration

9.1 Service models for application integration

9.1.1 Proxy services

Figure 9.2. A component represented by a proxy service. Table 9.1. Typical characteristics of proxy services

9.1.2 Wrapper services

Figure 9.3. A wrapper service encapsulating a legacy application and its adapter. Table 9.2. Typical characteristics of wrapper services

9.1.3 Coordination services (for atomic transactions)

Figure 9.4. A coordination service (such as the atomic transaction coordinator) is a controller representing an assembly of three additional services, each with a predefined role. Table 9.3. Typical characteristics of coordination services for atomic transactions

9.2 Fundamental integration components

9.2.1 Adapters

Figure 9.5. Three different adapters enabling three different integration channels.

9.2.2 Intermediaries

Figure 9.6. A message path consisting of an initial sender, intermediary services, and the ultimate receiver.

9.2.3 Interceptors

Figure 9.7. Service interceptors providing intermediary processing logic.

9.3 Web services and one-way integration architectures

Figure 9.8. One way data transfer. 9.3.1 Batch export and import

Traditional architecture Figure 9.9. The batch export and import architecture, which can be based on an automated or manual process. Encapsulating import and export functions within Web services Figure 9.10. A sample batch export and import architecture where services transport legacy data as SOAP attachments. Architectural comparison matrix Table 9.4. Typical characteristics of traditional and service-enabled batch export and import architectures

9.3.2 Direct data access

Traditional architecture Figure 9.11. Direct integration enabled by allowing an external application access to another application's repository. Encapsulating data access within a Web service Figure 9.12. An architecture incorporating a Web service that abstracts external data access functionality, and another that consumes it. Architectural comparison matrix Table 9.5. Typical characteristics of traditional and service-enabled direct data access architectures

9.4 Web services and point-to-point architectures

Figure 9.13. Synchronous request and response data exchange. 9.4.1 Tightly coupled integration between homogenous legacy applications

Traditional architecture Figure 9.14. Tightly-coupled integration between two homogenous applications. Encapsulating legacy interfaces within Web services Figure 9.15. Web services representing homogenous legacy applications. Architectural comparison matrix

9.4.2 Tightly coupled integration between heterogeneous applications

Table 9.6. Typical characteristics of traditional and service-enabled architectures for homogenous legacy applications Traditional architecture Figure 9.16. Tightly coupled integration between heterogeneous applications. Loosely coupled integration with service integration layers Figure 9.17. Service-oriented integration between heterogeneous applications. Figure 9.18. A business service interacting with multiple legacy adapters. Architectural comparison matrix Table 9.7. Typical characteristics of traditional and service-enabled architectures for heterogeneous legacy applications

9.4.3 Integration between homogenous component-based applications

Traditional architecture Figure 9.19. Homogenous component-based applications relying on an RPC protocol for remote communication. Component-based architecture with Web services Figure 9.20. Homogenous component-based applications relying on RPC-style SOAP messages for remote communication. Architectural comparison matrix Table 9.8. Typical characteristics of traditional and service-enabled architectures for homogenous component-based applications

9.4.4 Integration between heterogeneous component-based applications

Traditional architecture Figure 9.21. Heterogeneous component-based applications utilizing an adapter component for RPC protocol translation. Component-based architecture with Web services Figure 9.22. Heterogeneous component-based applications relying on proxy services for remote communication. Figure 9.23. SOAP servers act as a form of protocol adapter between SOAP messaging and native component technology communication. Architectural comparison matrix Table 9.9. Typical characteristics for traditional and service-enabled architectures for heterogeneous component-based applications

9.5 Web services and centralized database architectures

Figure 9.24. Two applications sharing a common repository. 9.5.1 Traditional architecture

Figure 9.25. A centralized database design, where one repository serves data to multiple applications (dashed lines indicate optional supplementary databases).

9.5.2 Using a Web service as a data access controller

Figure 9.26. A centralized database architecture utilizing a Web service to represent external data access to the shared database. Architectural comparison matrix Table 9.10. Typical characteristics for traditional and service-enabled centralized database architectures

9.6 Service-oriented analysis for legacy architectures

Figure 9.27. An XWIF process for analyzing the feasibility of service-enabling traditional integration architectures. Step 1: Define business requirements and expectations Step 2: Assess adapter quality Step 3: Identify required functionality Step 4: Evaluate development tool support Step 5: Estimate usage requirements Step 6: Identify additional integration opportunities Step 7: Define a high level test strategy Step 8: Gauge the required skill set Step 9: Estimate the impact Step 10: Determine the cost Step 11: Understand the alternatives Step 12: Justify the project

Chapter 10. Service-oriented architectures for enterprise integration

10.1 Service models for enterprise integration architectures

10.1.1 Process services

Figure 10.1. A process service coordinating and exposing functionality from three partner services. Figure 10.2. A process service assembly interacting with a nested process service assembly. Figure 10.3. Compatible process services interoperating across platform boundaries.

10.1.2 Coordination services (for business activities)

Table 10.1. Typical characteristics of process services Figure 10.4. A coordination service used to manage a coordination context for long running business activities.

10.2 Fundamental enterprise integration architecture components

Figure 10.5. A basic EAI architecture. Table 10.2. Typical characteristics of coordination services for long running business activities 10.2.1 Broker

Figure 10.6. Application-level integration involving an application broker. Data exchange with a broker component Figure 10.7. The key components involved in a simple data exchange scenario with an integration broker. Step 1: retrieve requested data from the source database (Figure 10.8) Figure 10.8. The request for data is received by application B. Step 2: validate source data using source schema (Figure 10.9) Figure 10.9. Application B retrieves and validates the requested data. Step 3: broker the data format (Figure 10.10) Figure 10.10. The broker service transforms, filters, and adds to the received data in order to produce a response acceptable to the requesting application. Step 4: validate target data using target schema (Figure 10.11) Figure 10.11. The transformed data is sent to application A, where it is validated. Step 5: insert data into target database (Figure 10.12) Figure 10.12. Application A accepts and stores the received data.

10.2.2 Orchestration

Figure 10.13. Process-level integration managed by an orchestration engine. Data exchange with orchestration Figure 10.14. The key components participating in a simple data exchange scenario involving process orchestration. Step 1: request data from orchestration (Figure 10.15) Figure 10.15. Application A requests data from the orchestration engine. Step 2: request data from application (Figure 10.16) Figure 10.16. Acting on application A's behalf, the orchestration engine relays the request for data from application B. Step 3: return response to orchestration (Figure 10.17) Figure 10.17. Application B returns the requested data. Step 4: process orchestration logic (Figure 10.18) Figure 10.18. Orchestration's business process manipulates the requested data. Step 5: forward data to requesting application (Figure 10.19) Figure 10.19. Orchestration returns the requested data to application A.

10.3 Web services and enterprise integration architectures

Figure 10.20. A new business process orchestrates the involvement of two applications.

10.4 Hub and spoke

10.4.1 Traditional architecture

Figure 10.21. A basic hub and spoke architecture.

10.4.2 Adding integration layers with Web services

Figure 10.22. A service-enabled hub-and-spoke architecture.

10.5 Messaging bus

10.5.1 Traditional architecture

Figure 10.23. The messaging bus architecture.

10.5.2 Messaging bus solutions that utilize Web services

Figure 10.24. The messaging bus architecture with service integration layers.

10.6 Enterprise Service Bus (ESB)

Figure 10.25. The enterprise service bus architecture (services are hosted by containers provided by the integration platform).

Chapter 11. Service-oriented integration strategies

11.1 Strategies for streamlining integration endpoint interfaces

11.1.1 Make interfaces more generic

Figure 11.2. An example of a service providing a generic operation that represents multiple component methods. Figure 11.3. A service achieving increased usability by providing a group of granular operations that all relate to the same component method.

11.1.2 Consolidate legacy interfaces

Figure 11.4. A single service operation utilizing four component methods.

11.1.3 Consolidate proxy interfaces

Figure 11.5. Typical out-of-the-box integration layers consisting of standard proxy services. Figure 11.6. A similar design where application A's proxy service layer has been replaced with an optimized business service.

11.1.4 Supplement legacy logic with external logic

Figure 11.7. A Web service operation making use of component methods from different applications. Figure 11.8. A service assembly where one controller service encapsulates functionality from business services representing legacy applications.

11.1.5 Add support for multiple data output formats

Figure 11.9. A business service extended to offer multiple output formats.

11.1.6 Provide alternative interfaces for different SOAP clients

Figure 11.10. A component-based application encased by different integration layers. Figure 11.11. A parent wrapper service that determines which underlying service interface is most appropriate, based on SOAP message format characteristics.

11.2 Strategies for optimizing integration endpoint services

11.2.1 Minimize the use of service intermediaries

Figure 11.12. A message path containing one intermediary service.

11.2.2 Consider using service interceptors

Figure 11.13. Service interceptors providing intermediary processing logic.

11.2.3 Data processing delegation

Figure 11.14. A service provider delegating data processing. Figure 11.15. A service requestor delegating data processing.

11.2.4 Caching the provider WSDL definition

Figure 11.16. A service requestor encapsulating the provider service definition.

11.3 Strategies for integrating legacy architectures

11.3.1 Create a transition architecture by adding partial integration layers

Figure 11.17. A transition architecture where components represented by proxy services coexist with components that still interact using RPC.

11.3.2 Data caching with an IMDB

Figure 11.18. A Web service utilizing an IMDB to cache XML document and schema files.

11.3.3 Utilizing a queue to counter scalability demands

Figure 11.19. A Web service utilizing a queue to manage overflow requests for the legacy application.

11.3.4 Adding a mini-hub

Figure 11.20. An example of the batch export and import architecture outfitted with a Web service hub. Figure 11.21. The business service acting as a controller service to outside applications could also be a process service.

11.3.5 Abstract legacy adapter technology

Figure 11.22. A utility service abstracting legacy adapter interaction.

11.3.6 Leveraging legacy integration architectures

Figure 11.23. A service representing an entire legacy integration architecture.

11.3.7 Appending Web services to legacy integration architectures

Figure 11.24. Preserving a traditional point-to-point architecture while exposing functionality from one application with a service integration layer. Figure 11.25. A (relatively) non-intrusive integration layer exposing functionality from two applications already bound by a point-to-point integration architecture.

11.4 Strategies for enterprise solution integration

11.4.1 Pragmatic service-oriented integration

Figure 11.26. A messaging bus supporting service-oriented and proprietary integration channels.

11.4.2 Integrating disparate EAI products

Figure 11.27. A distributed enterprise, consisting of integrated EAI solutions.

11.4.3 Respect your elders (building EAI around your legacy environments) 11.4.4 Build a private service registry

11.5 Strategies for integrating Web services security

11.5.1 Learn about the Web services security specifications 11.5.2 Build services with a standardized service-oriented security (SOS) model 11.5.3 Create a security services layer

Figure 11.28. An enterprise-wide security layer.

11.5.4 Beware remote third-party services

Figure 11.29. A remote third-party service assuming temporary control of your data.

11.5.5 Prepare for the performance impact 11.5.6 Define an appropriate system for single sign-on 11.5.7 Don't over-describe your services 11.5.8 Fortify or retreat integrated legacy systems

Figure 11.30. A comparison of new and established legacy communication channels.

11.5.9 Take advantage of granular security

Example 11.1. An encrypted XML element Example 11.2. The same construct with no encryption

11.5.10 Web services and port 80 11.5.11 SOAP attachments and viruses

Figure 11.31. A SOAP message delivering a potentially dangerous (and encrypted) attachment.

11.5.12 Consider the development of security policies 11.5.13 Don't wait to think about administration

Part IV: Integrating the enterprise

Chapter 12. Thirty best practices for integrating XML

12.1 Best practices for planning XML migration projects

12.1.1 Understand what you are getting yourself into

Figure 12.1. How business requirements can be mapped to XML features.

12.1.2 Assess the technical impact

A migration project is like a development project What to look out for Figure 12.2. Typical areas of an enterprise infrastructure that get hit by migration shockwaves. One more thing…

12.1.3 Invest in an XML impact analysis

One more thing…

12.1.4 Assess the organizational impact

Figure 12.3. Typical areas within an organization affected by the introduction of XML technologies and products.

12.1.5 Targeting legacy data

XML-enabling a legacy application Making legacy applications XML-compliant One more thing…

12.2 Best practices for knowledge management within XML projects

12.2.1 Always relate XML to data

Clarity of concepts Create a custom glossary One more thing…

12.2.2 Determine the extent of education required by your organization 12.2.3 Customize a training plan

Take a course to learn XML fundamentals Define roles before assigning further training Make resources available to your technical staff Spend your training budget wisely Bring outside experts in for specialized knowledge transfer

12.2.4 Incorporate mentoring into development projects

Arrange a consult-and-mentor program Get suitable mentors

12.3 Best practices for standardizing XML applications

12.3.1 Incorporate standards

Table 12.1. Common standards

12.3.2 Standardize, but don't over-standardize 12.3.3 Define a schema management strategy

Understand the importance of XML schemas Assign an XML data custodian Ownership of vocabularies Ownership of data models Namespace domain administration

12.3.4 Use XML to standardize data access logic 12.3.5 Evaluate tools prior to integration

12.4 Best practices for designing XML applications

12.4.1 Develop a system for knowledge distribution

Figure 12.4. A proposed knowledge distribution system for issues relating to XML technology.

12.4.2 Remember what the "X" stands for 12.4.3 Design with service-oriented principles (even if not using Web services) 12.4.4 Strive for a balanced integration strategy

Tightening the screw Stripping the screw

12.4.5 Understand the roles of supplementary XML technologies

Define a core technology set Identify second-tier technologies

12.4.6 Adapt to new technology developments

Chapter 13. Thirty best practices for integrating Web services

13.1 Best practices for planning service-oriented projects

13.1.1 Know when to use Web services 13.1.2 Know how to use Web services 13.1.3 Know when to avoid Web services 13.1.4 Moving forward with a transition architecture 13.1.5 Leverage the legacy

Build on what you have Understand the limitations of a legacy foundation

13.1.6 Sorry, no refunds (Web services and your bottom line) 13.1.7 Align ROIs with migration strategies

ROIs open eyes Iterating through ROI and migration strategy documents Figure 13.1. An iterative cycle between a migration plan and an ROI.

13.1.8 Build toward a future state

13.2 Best practices for standardizing Web services

13.2.1 Incorporate standards 13.2.2 Label the infrastructure

One more thing

13.2.3 Design against an interface (not vice versa)

Figure 13.2. Standardized integration endpoint services establishing a service-oriented integration architecture.

13.2.4 Service interface designer 13.2.5 Categorize your services

13.3 Best practices for designing service-oriented environments

13.3.1 Use SOAs to streamline business models 13.3.2 Research the state of second-generation specifications 13.3.3 Strategically position second-generation specifications 13.3.4 Understand the limitations of your platform

Proprietary extensions (the potholes) Exclusive proprietary extensions (the roadblocks)

13.3.5 Use abstraction to protect legacy endpoints from change

Use abstraction to improve configuration management Figure 13.3. Application A is upgraded without affecting application B. Use abstraction to support wholesale application changes Figure 13.4. Application A is replaced without affecting application B.

13.3.6 Build around a security model

Security requirements define boundaries, real boundaries Define the scope of the security model Figure 13.5. The service-oriented security (SOS) model. Figure 13.6. A separate security layer can implement the SOS model.

13.4 Best practices for managing service-oriented development projects

13.4.1 Organizing development resources 13.4.2 Don't underestimate training for developers

13.5 Best practices for implementing Web services

13.5.1 Use a private service registry

Centralize service descriptions in a service repository Make the use of a service registry mandatory Assign a resource to maintain the registry

13.5.2 Prepare for administration 13.5.3 Monitor and respond to changes in the service hosting environments 13.5.4 Test for the unknown

Chapter 14. Building the service-oriented enterprise (SOE)

Figure 14.1. This master view of the XWIF SOE model illustrates how closely business and technology architecture models relate (one no longer exclusively drives the other). 14.1 SOA modeling basics

14.1.1 Activities

Primitive business activity Process activity Business activity

14.1.2 Services

Primitive business service Process service Business service

14.1.3 Processes

Figure 14.2. A service-oriented process. Figure 14.3. A relationship between two processes. Figure 14.4. Two processes represented by a single business service.

14.2 SOE building blocks

14.2.1 SOE business modeling building blocks

Figure 14.5. Business modeling building blocks for the SOE. Primitive business activity Figure 14.6. The primitive business activity. Primitive business service Figure 14.7. The primitive business service. The primitive business process Figure 14.8. The primitive business process. Figure 14.9. A Retrieve Invoice Data service (acting as a process activity) executes a step within the Process Invoice process. The extended business process Figure 14.10. The extended business process. Figure 14.11. An extended process utilizing a new service. The enterprise domain business process Figure 14.12. The enterprise domain business process. Figure 14.13. An enterprise domain process uniting two related business processes. The enterprise business process Figure 14.14. The enterprise business process.

14.2.2 SOE technology architecture building blocks

Figure 14.15. Technology architecture building blocks for a SOE. Web service operation Figure 14.16. The Web service operation. Figure 14.17. A Web service operation exposing various levels of functional granularity. Web service Figure 14.18. The Web service. Figure 14.19. The Retrieve Invoice Data service encapsulated in the InvoiceData business Web service. Figure 14.20. The Month-End Sales Report process encapsulated in the SalesReport process Web service. Service-oriented application architecture Figure 14.21. The service-oriented application architecture. Figure 14.22. A simple SOA involving business Web services that, along with the legacy logic they represent, provide an implementation of the Process Invoice primitive business process. Service-oriented integration architecture Figure 14.23. The service-oriented integration architecture. Figure 14.24. An integrated SOA, where the Invoice Processing application implementing the Process Invoice process integrates with the Time Tracking application to access the Retrieve Timesheet Data business service from the Timesheet Reporting process. Service-oriented EAI architecture Figure 14.25. The service-oriented EAI architecture. Figure 14.26. A service-oriented EAI architecture implementing the combined Month-End Sales Report enterprise domain business process. Service-oriented enterprise integration architecture Figure 14.27. The service-oriented enterprise integration architecture. Figure 14.28. A service-oriented enterprise architecture in which two EAI solutions are integrated.

14.2.3 Service-oriented security model

Figure 14.29. The service-oriented security model.

14.3 SOE migration strategy

14.3.1 Overview of the Layered Scope Model (LSM)

Figure 14.30. The XWIF Layered Scope Model. Obstacles to using the LSM Applying the LSM Before you begin

14.3.2 Intrinsic Layer

Figure 14.31. The intrinsic layer and project phase. The service-oriented architecture (SOA) wedge So, why bother? Processes, best practices, and strategies Service models Technologies SOE building blocks

14.3.3 Internal layer

Figure 14.32. The internal layer and project phase. Building for a future state Figure 14.33. An application architecture designed to transition to an integration architecture. The service-oriented security (SOS) model wedge Processes, best practices, and strategies Service models Technologies SOE building blocks

14.3.4 A2A layer

Figure 14.34. The A2A layer and project phase. Building for a future state Figure 14.35. An integration architecture designed to transition to an EAI environment. Processes, best practices and strategies Service models Technologies SOE building blocks

14.3.5 EAI layer

Figure 14.36. EAI layer and project phase. Building for a future state Figure 14.37. An EAI solution designed to transition to an enterprise integration architecture. Processes, best practices and strategies Service models Technologies SOE building blocks

14.3.6 Enterprise layer

Figure 14.38. Enterprise layer and project phase.

14.3.7 The extended enterprise

Figure 14.39. The LSM for the extended enterprise. Figure 14.40. Standards are grouped into architectural zones.

14.3.8 Customizing the LSM 14.3.9 Alternatives to the LSM

About the Author About the Photographs Index

A B C D E F G H I J L M N O P R S T U W X

← Prev
Back
Next →

← Prev
Back
Next →