SOA and XML

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


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


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

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


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


Q&A SessionQ&A Session

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

Introduction to SOA


“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.”


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


“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.


SOA Myth #1SOA Myth #1

“An application that uses Web services

is service-oriented.”



“SOA is just a marketing term used to

re-brand Web services.”



“SOA is just a marketing term used to

re-brand distributed computing

with Web services.”



“SOA simplifies

distributed computing.”



“An application with Web services

that uses WS-* standards

is service-oriented.”



“If you understand Web services

you won’t have a problem

building SOA.”



“Once you go SOA,

everything becomes

interoperable.”


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.


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


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.


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.


XML in SOA: SOAP Message Payload

Standards


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

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

distributed environments.



Standards (cont...)


Standards (cont...)

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



Standards (cont...)


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.


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.


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.


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.


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.



(cont...)


(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


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.


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.


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.


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


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


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


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


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


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.


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

SOA and XML

Documents

Transcript of SOA and XML