SOA and XML

by Thomas ErlXMLTC Consulting Inc.

Vancouver, Canada

Copyright © 2004

Thomas Erl www.serviceoriented.ws “XML and SOA” Slide 2

OverviewOverviewContest DetailsIntroduction to SOAXML in Service-Oriented ArchitectureGuidelines for a Happy XML-SOA MarriageCommon SOA PitfallsBook Giveaway

Thomas Erl www.serviceoriented.ws “XML and SOA” Slide 3

Contest: Book GiveawayContest: Book GiveawayService-Oriented Architecture: A Field Guide to Integrating XML and Web Services(Prentice Hall/PearsonPTR)

We’re giving away 2 copies1 x draw the business card1 x guess the cover

Thomas Erl www.serviceoriented.ws “XML and SOA” Slide 4

Contest: Book GiveawayContest: Book GiveawayService-Oriented Architecture: Concepts and TechnologyPrentice Hall/PearsonPTRPlanned Release: Q1/2005

Contest Question:“What is being displayed on this cover?”

Thomas Erl www.serviceoriented.ws “XML and SOA” Slide 5

What this presentationdoesn’t cover

What this presentationdoesn’t cover

we don’t explain XML we don’t explain Web Services (agenda change) we don’t provide code samples

Thomas Erl www.serviceoriented.ws “XML and SOA” Slide 6

Q&A SessionQ&A Session

Meet-the-Author Session Conference Bookstore3:30 – 4:00 PM Today

Introduction to SOA

Thomas Erl www.serviceoriented.ws “XML and SOA” Slide 8

“SOA”, a definition“SOA”, a definition

“SOA is a form of technology architecture that adheres to the principles of service-orientation. When

realized through the Web services technology platform, SOA establishes the potential to support and

promote these principles throughout the business process and automation domains of an enterprise.”

Thomas Erl www.serviceoriented.ws “XML and SOA” Slide 9

Principles of Service-Orientation

Principles of Service-Orientation

Reusable logic is divided into services Services abstract underlying logic Services are composable Services are autonomous Services share a formal contract Services are loosely coupled Services are stateless Services are discoverable

Thomas Erl www.serviceoriented.ws “XML and SOA” Slide 10

“Primitive” vs. “Contemporary” SOA

“Primitive” vs. “Contemporary” SOA

Fundamental principles of service-orientation represent a primitive SOA.

Today’s SOA has been heavily influenced by the success of Web Services and the emerging WS-* standards.

We refer to this as “contemporary SOA”. Contemporary SOA is defined separately.

Thomas Erl www.serviceoriented.ws “XML and SOA” Slide 11

SOA Myth #1SOA Myth #1

“An application that uses Web services

is service-oriented.”

Thomas Erl www.serviceoriented.ws “XML and SOA” Slide 12

SOA Myth #2SOA Myth #2

“SOA is just a marketing term used to

re-brand Web services.”

Thomas Erl www.serviceoriented.ws “XML and SOA” Slide 13

SOA Myth #3SOA Myth #3

“SOA is just a marketing term used to

re-brand distributed computing

with Web services.”

Thomas Erl www.serviceoriented.ws “XML and SOA” Slide 14

SOA Myth #4SOA Myth #4

“SOA simplifies

distributed computing.”

Thomas Erl www.serviceoriented.ws “XML and SOA” Slide 15

SOA Myth #5SOA Myth #5

“An application with Web services

that uses WS-* standards

is service-oriented.”

Thomas Erl www.serviceoriented.ws “XML and SOA” Slide 16

SOA Myth #6SOA Myth #6

“If you understand Web services

you won’t have a problem

building SOA.”

Thomas Erl www.serviceoriented.ws “XML and SOA” Slide 17

SOA Myth #7SOA Myth #7

“Once you go SOA,

everything becomes

interoperable.”

Thomas Erl www.serviceoriented.ws “XML and SOA” Slide 18

SOA Tangible BenefitsSOA Tangible Benefits

“SOA leverages XML data representation.”

The XML technology platform is fundamental to SOA.

XML documents and schemas passed between services or components fully standardize format and typing of all data communicated.

Thomas Erl www.serviceoriented.ws “XML and SOA” Slide 19

SOA Tangible Benefits (cont...)

SOA Tangible Benefits (cont...)

“SOA fosters intrinsic interoperability.”

Standardized data representation lays the groundwork for intrinsic interoperability

Because of the vendor-neutral communications framework established by Web services, the potential is there for enterprises to implement highly standardized service descriptions and message structures.

XML in Service-Oriented Architecture

Thomas Erl www.serviceoriented.ws “XML and SOA” Slide 21

XML in Traditional Distributed Architectures

XML in Traditional Distributed Architectures

XML documents are often auto-generated by development tools.

XML documents are frequently inconsistent in structure and context.

XML documents are commonly RPC-centric in format.

XML schemas are often task specific.DTDs are still in use.

Thomas Erl www.serviceoriented.ws “XML and SOA” Slide 22

XML in SOA: Service Interface

Standards

XML in SOA: Service Interface

Standards“SOA requires that data representation and service

modeling standards now be kept in alignment.”

Service interface granularity must correspond to XML document granularity. The “WSDL first”

design approach will often conflict with existing XML document structures.

Thomas Erl www.serviceoriented.ws “XML and SOA” Slide 23

XML in SOA: SOAP Message Payload

Standards

XML in SOA: SOAP Message Payload

Standards“The big challenge: RPC-centric versus Document-centric message formats.”

Traditional data representation architectures incorporate XML as part of fine-grained

distributed environments.

Thomas Erl www.serviceoriented.ws “XML and SOA” Slide 24

XML in SOA: SOAP Message Payload

Standards (cont...)

XML in SOA: SOAP Message Payload

Standards (cont...)

Introducing SOA into RPC-centric distributed environments inhibits the potential of many WS-* standards that expect document-centric payloads.

Thomas Erl www.serviceoriented.ws “XML and SOA” Slide 25

XML in SOA: SOAP Message Payload

Standards (cont...)

XML in SOA: SOAP Message Payload

Standards (cont...)

RPC-centric approaches supported the transmission of granular XML documents with targeted data, XML documents within SOAs

often need to represent bundled data related to more than one data context.

Thomas Erl www.serviceoriented.ws “XML and SOA” Slide 26

XML in SOA:Metadata Abstraction

XML in SOA:Metadata Abstraction

“SOAP headers abstract metadata from XML document payloads.”

XML documents need to become purely “payload-centric”, however payload data-

derived metadata is still useful.

Thomas Erl www.serviceoriented.ws “XML and SOA” Slide 27

XML Schema in SOA: Payload Validation

Requirements

XML Schema in SOA: Payload Validation

Requirements“Increasingly intelligence-heavy SOAP payloads place a greater emphasis on advanced validation requirements.”

XML Schema becomes a central part of SOAP message payloads, but advanced features of XML

Schema are may be insufficient. For example, conditional validation is sometimes required.

Thomas Erl www.serviceoriented.ws “XML and SOA” Slide 28

XML Schema in SOA: WS-* Schema Requirements

XML Schema in SOA: WS-* Schema Requirements

XML Schema has become an intrinsic part of the Web services standards landscape. The use of

Document Type Definitions will inhibit XML documents within WS-* environments.

Thomas Erl www.serviceoriented.ws “XML and SOA” Slide 29

XML Schema in SOA: Payload Structure Definition

XML Schema in SOA: Payload Structure Definition

“Document-centric SOAP message payloads lead to a tendency to bundle groups of data into a single XML document.”

The use of extensible or redefined schemas may be required when building documents

that represent multiple data contexts.

Thomas Erl www.serviceoriented.ws “XML and SOA” Slide 30

XML Schema in SOA: Payload Structure Definition

(cont...)

XML Schema in SOA: Payload Structure Definition

(cont...)

The use of schema modules may be required to accommodate the assembly of

unique SOAP message payloads from differently standardized XML data sources.

Guidelines for a Happy XML-SOA Marriage

Thomas Erl www.serviceoriented.ws “XML and SOA” Slide 32

Create an SOA-friendly XML Data Representation

Architecture

Create an SOA-friendly XML Data Representation

Architecture

Standardization is key. Consistent XML document structures will accommodate

the runtime assembly of document-centric SOAP payloads.

Thomas Erl www.serviceoriented.ws “XML and SOA” Slide 33

Create an SOA-friendly XML Data Representation Architecture (cont...)

Create an SOA-friendly XML Data Representation Architecture (cont...)

XML schema modularization establishes flexibility and composability.

Entity-centric XML schema design supports the business-centric aspects of

contemporary SOA.

Thomas Erl www.serviceoriented.ws “XML and SOA” Slide 34

Designing for Key WS-* Standards

Designing for Key WS-* Standards

Accommodate the features of key WS-* standards that are or will be becoming part of your technical environment. This can typically

affect data placement and XML schema design.

Thomas Erl www.serviceoriented.ws “XML and SOA” Slide 35

Migrating Toward SOAMigrating Toward SOA

If transitioning an XML-heavy legacy environment, standardize data representation first.

If transitioning an RPC-centric legacy environment, use service abstraction to produce runtime, document-centric SOAP messages.

Common SOA Pitfalls

Thomas Erl www.serviceoriented.ws “XML and SOA” Slide 37

SOA Pitfall #1SOA Pitfall #1“Building service-oriented architecture like

traditional distributed architectures.”

The number one obstacle to realizing SOA, as it causes:proliferation of RPC-centric service descriptionsimproper partitioning of functional service boundariescreation of non-composable servicesentrenchment of synchronous communication patterns

Thomas Erl www.serviceoriented.ws “XML and SOA” Slide 38

SOA Pitfall #2SOA Pitfall #2“Not sufficiently standardizing XML and Web

services technologies.

This can lead to many problems, including:incompatible data representation resulting in disparate

schemas representing the same types of informationservice descriptions with irregular interface

characteristics and semanticssupport of different standards, or standards being

implemented in different ways

Thomas Erl www.serviceoriented.ws “XML and SOA” Slide 39

SOA Pitfall #3SOA Pitfall #3“Not creating a transition plan.

Examples of areas covered by a transition plan include:impact analysis that predicts the extent of change SOA will

impose on existing resources, processes, standards, and technology

the definition of transition architectures, where those environments identified as candidates for a migration to SOA evolve through a series of planned hybrid stages

speculative analysis which takes into account the future growth of Web services and its supporting technologies

Thomas Erl www.serviceoriented.ws “XML and SOA” Slide 40

SOA Pitfall #4SOA Pitfall #4“Not keeping in touch with product platforms and standards development.”

Specific developments to look out for include:which standards vendors choose to supportthe involvement vendors demonstrate with the standards

development process itselfwhich other organizations vendors choose to ally themselves

with (for a given standard)roadmaps published by vendors explaining how their product

or platform will support upcoming standards

Thomas Erl www.serviceoriented.ws “XML and SOA” Slide 41

SummarySummaryContemporary SOA introduces new concepts

and technology that affect the manner in which XML represents data.

The key to understanding how XML will be affected in your environment is to contrast SOA data representation requirements as related to SOAP messaging with the manner in which XML is currently being utilized.

Thomas Erl www.serviceoriented.ws “XML and SOA” Slide 42

Summary (cont...)Summary (cont...)The most effective way to migrate toward SOA is

to create a transition plan. This plan includes transition phases that specifically address XML compatibility issues.

A key part of this plan is also the introduction of custom standards that ensure an alignment between service models and XML data representation.

Thank You for Attending

Thomas ErlXMLTC Consulting Inc.

Vancouver, Canadawww.serviceoriented.ws