opentravel advisory forum 2012 xml object suite lab

1 © OpenTravel Alliance

LAB PRESENTATION

2012 North American Advisory Forum (Miami Florida April 2012)

< build:2.0 name = "OpenTravel Lab" />

To address the changing way XML is consumed in

today’s global travel marketplace, a new OpenTravel

schema product called the “OpenTravel 2.0 XML Object

Suite” is being introduced Summer of 2012. The

architectural advantages of this new specification

facilitate light-weight and interoperable XML payloads—

with multiple extension points that support proprietary

business logic. This lab provides a developer’s view of

2.0 that will start with a brief presentation titled “Why 2.0”

and end with a demo of implementing a 2.0 web service.


2012 North American Advisory Forum (Miami Florida April 2012)

Lab Facilitators

DAVID MORLEY, Technical

Consultant, Marriott

International (moderator)

DAVE HOLLANDER,

Enterprise Architect, Sabre

Holdings

BONNIE LOWELL, Specification Architect, OpenTravel

STEVE LIVEZEY, Enterprise

Services Technology, Sabre

Holdings

STUART WALDRON,

Information Technology

Architect, Amtrak

< build:2.0

name = "OpenTravel Lab" />

2012 North American

Advisory Forum

Miami, Florida

<Aliases>

Why 2.0?

XML Component Overview

Terminology

Mechanics

Design Patterns

Implementation Best Practices </Aliases>


Why 2.0? DAVID MORLEY

Technical Consultant, Marriott International

Chair, OpenTravel Architecture Workgroup


Ongoing Challenges for Travel Distribution

The dynamic nature of travel

distribution poses IT design and

development challenges… and

this impacts XML standards.


OpenTravel’s 2.0 XML Object Suite

• Will be available in 2012

• Provides comprehensive

support for the newest XML

technologies

• Is freely available to all

implementers

• Is based on OpenTravel’s

travel industry CIEM (common

information exchange model)


2.0 Architectural Advantages

The architectural advantages of the new

OpenTravel 2.0 XML Object Suite allow trading

partners to construct light-weight and

interoperable XML payloads—with multiple

extension points that support proprietary

business logic and market innovations.

So let’s take a look at why

you should implement

2.0…


Why Should You Implement 2.0?

Built By and For Travel Companies

The OpenTravel member

community

—comprised of companies

in the electronic distribution

supply chain—

have worked together to

create the 2.0 specification

based on a specific set of

goals.


Maximized Out-of-the-Box Interoperability

The 2.0 architecture is based on

OpenTravel's CIEM, which

follows a “define once and reuse

everywhere” design pattern

• Minimized optional elements &

attributes

• Naming & structural pattern

consistency • Core travel industry concepts

described the same way

• Substantial reduction of

object model analysis

requirements



Light Weight Payloads

2.0 supports light-weight service

models by:

• Allowing implementers to use

only the XML component

“building blocks” needed for

their services

• Incorporating element &

attribute de-duplication into the

schema design process




#4) Built-In Extensibility

2.0 supports both your proprietary

business requirements/ innovation

and industry emerging requirements

through extensible structures:

• Open Enumerations

• Core Components

• Business Objects



#5) Reduced Binding Issues

With a focus on reduced binding

issues, 2.0:

• Minimizes namespace

intrusions

• Eliminates nested include files

• Eliminates nested attributes

• Replaces NMTOKEN with

atomic string (to alleviate .Net

issues)



#6) Faster Specification Releases

The 2.0 publication schedule is RAD-

friendly:

• Two “Candidate Releases” that

provide enough time for member

implementers to test implementation

• and submit enhancement

requests

• One final publication that includes all

features of Candidate Releases

RAD = rapid application development



#7) Easy to Learn and Use

2.0 is easy to learn and use

• Consistent architectural design patterns

• Established implementation best

practices • Published & included in “reference

implementation services”

• 2.0 publication add-ons • Component modeling tools

• Multiple learning resources on the

OpenTravel Developers Network (ODN)


Terminology

BONNIE LOWELL

Specification Architect, OpenTravel


OpenTravel CIEM (Common Information Exchange Model)

• A common representational model of all data

and data relationships contained in OpenTravel

specifications

• Precise atomic to component mapping

between all OpenTravel schema products

• Ensures precise (and consistent) data

exchange between parties

• OpenTravel libraries are modeled as packages

• Supports 2.0 OpenTravel Model

• XML structures are modeled as classes

• Structure name, type, relationships and

schema mapping

• Key OpenTravel specification architectural

component

• Minimizes data duplication

• Adds more meaning to data

• Semantics, relationships, mapping

between specifications, related

artifacts


OpenTravel Design Patterns

• An OpenTravel community determined set of XML

architectural design patterns that support the

requirements of modern messaging systems

• Incorporated into OpenTravel XML Architecture Model • XML schema constructs

• Naming

• Enumerations

• Repeating Groups

• Documentation

• Substitutions

• Namespaces

• Extensions

• Incorporated into OpenTravel CIEM


OpenTravel Implementer Best Practices

• An OpenTravel community determined set of

implementation guidelines for schema

implementation and data exchange between

trading partners

• Message Exchange Patterns

• Service Architectures (SOAP and REST)

• Encryption

• Data Policies


OpenTravel Model (OTM)

• A development environment for producing

“model driven” OpenTravel schema and creating

OpenTravel 2.0 Publications

• The OTM contains structured reusable XML objects

• Model objects are maintained in CIEM and library(s)

for reuse

• OTM Compiler creates WSDL and XML schemas for

XML services

• OTM model compiler created by SABRE for

OpenTravel


OpenTravel 2.0 Model

Included

XSD

Schema Compiler

WSDL

OTM

Model

Library Examples

OpenTravel

Publication

Model Development Tool User

Interface

OpenTravel 2.0 Development Environment


2.0 OpenTravel Model

Type Builders Constructs Used to Build 2.0 Components


Documentation

• Six levels of documentation supported

• All documentation strings up to 2048 characters

• All but Description up to 10 instances

Non-Contextual

• Description (required): The basic description of the XML structure.

• Developer: Implementer-specific textual information, which may contain tips and

warnings.

• Deprecated: A notification that the object has been marked for deprecation and the

publication version or date for the final object deprecation.

• Reference: URL(s) to additional reference information. For example, a link to an

OpenTravel best practice, an OpenTravel glossary definition and/or a third-party site and/or

standard.

• MoreInfo: URL(s) to additional documentation that includes links to publication schedules

and instructions for submitting publication comments.

Contextual

• OtherDoc: Other documentation (not included in any of the other Documentation types)

with a context-based indicator.


Equivalent

A (string-based) complex type that provides

a mechanism to relate a 2.0 element or

attribute to a proprietary implementer-

defined application standard, schema and/

or database

• Related mechanism identified by

@context


Facet

• Mostly used in Core Components and Business Objects

• Separate data into:

• ID (business objects only)

• Summary

• Attribute collection

• Element collection

• Indicator collection

• Detail

• Attribute collection

• Element collection

• Indicator collection

• Query:

• Custom

• Has Documentation


Alias

• Mechanism for providing alternate names

usable for valid element references for an

object or facet

• Typically used to provide alternate names for Core

Components and Business Objects within a travel

segment (2.0 Library) for ease of implementation


2.0 Built-Ins

Predefined 2.0 datatypes and structures defined

in one common 2.0 library

• Used to declare elements or attributes in

other 2.0 structures

• OpenTravel namespaced

• May be Simples, Enumerations, Value with

Attributes and Core Components


2.0 Types 2.0 Components Contained in Libraries and Used to

Construct Services & Service Operations


2.0 Type Library

Components

The 2.0 Library is built

from a hierarchy of

XML components….

…let’s take a look!


2.0 Simple/ Atomic Type

The most granular 2.0 XML structures

• Has atomic XML base type

• xsd:string, xsd:integer, xsd:date, etc.

• May also be comprised of lists

• May be 2.0 “Named” simple types

• Atomic base type with no Facets

• Provide easier implementations and schema readability

• May be 2.0 “Constrained” simple types

• Constrain the content of elements and attributes

• Contain one or more facets

• Pattern, MinLen, etc.


2.0 Enumerations

The 2.0 specification supports two

discrete types of enumerations:

• Closed Enumeration

• Open Enumeration

• Both may be used as base types for

Values with Attributes

• Code List strategy


2.0 Value with Attributes

A complex type with:

• One base value

• Base type may be a Simple Type, Closed

Enumeration or Open Enumeration

• One or more Attribute and/ or Boolean

Indicator collections

• Typically replace 1.0 attributeGroups

• Promotes re-use

• Has Documentation and Base Value

Documentation

• Has Example(s)


Core Component

A Complex Type:

• Containers for application data that defines common representations of

real world objects used by all supported OpenTravel sectors

• Address, Phone Number, Payment Card

• Typically used as building blocks for Business Objects

• Typically not implementer extensible

• But may extend another Core Components

• Have one or more Facets

• Summary Facet

• Detail Facet

• May have a Simple Form representation

• May have Roles

• May have Aliases


Business Objects

A Complex Type:

• Containers for application data (such as an itinerary or a traveler

profile)

• Implementer extensible

• Have Facets

• ID

• Summary Facet

• Detail Facet

• Query

• May have Roles

• May have Aliases


Services

A collection of 2.0 components that

support interoperable machine-to-

machine interaction over a network

specified in Web Services

Description Language (WSDL)

format

• Implementer extensible

• Have Equivalents

• Have Service

Operations

• OTM compiler produces trimmed

schema

Service Operation Patterns

• Request

• Response

• Notification


Sim

ple

Co

mp

lex

Base X

ML

Ato

mic

Typ

e

Base S

imp

le T

yp

e

Base E

nu

mera

tio

n

Co

nstr

ain

ing

Facets

Lit

era

l V

alu

es

Imp

lem

en

ter

Exte

nsib

le

Do

cu

men

tati

on

Exam

ple

(s)

Att

rib

ute

Co

llecti

on

Ele

men

t C

ollecti

on

Ind

icato

r C

oll

ecti

on

Sim

ple

Fo

rm

ID F

acet

Su

mm

ary

Facet

Deta

il F

acet

Qu

ery

Facet

Cu

sto

m F

acet

Eq

uiv

ale

nt(

s)

Alias(e

s)

Ro

le(s

)

Simple Types X X X X X X

Open Enumerations X X X X X X

Closed Enumerations X X X X X

Value with Attributes X X X X X X X X X X X X

Core Components X X X X X X

Business Objects X X X X X X X X X

Services X X

Summary


Demo

DAVE HOLLANDER

Enterprise Architect, Sabre Holdings

Co-Chair, OpenTravel Architecture Workgroup


Demonstration Goal

Let’s build a new “Journey” service

complete with Schema + WSDL in 5 minutes or less


Steps

Examine Profile Demo

Use tree filters

Expose children of Profile

Examine Service Example

data

Create Journey Library

Create Extensions

Extend Phone

Add a “preferedName”

Define extension point for

Profile_Summary

Add a “cvs” attribute

Create Journey Object

Flight, Profile, Hotel,

HotelType

Create Service Operations

Compile

Examine Results

Model schema

Service description

Generated Examples

Create Java classes


2.0 Mechanics

DAVE HOLLANDER

Enterprise Architect, Sabre Holdings

Co-Chair, OpenTravel Architecture Workgroup


OTM Primary Design Goals

1. Enhance OpenTravel’s CIEM (controlled vocabulary)

Owners of a data type define the names by which it is used

Code bound to a type can be written once and reused everywhere

2. Embody OpenTravel XML Schema Design Patterns

Developer-oriented to make it easier to program XML applications

3. Embody OpenTravel XML Implementation Best

Practices

Industry created and adopted data exchange and message

implementation guidelines

4. Provide a consistent structure that supports reuse


GOAL #1: CIEM Controlled Vocabulary

Vocabulary owners control the names by which objects

are known

Consistent object names

A “Phone” is the same real world object with the same recognizable

XML name where- and how-ever it is used

Approved names and aliases

Model developer defines and controls object names and aliases

New names, aliases and extensions defined within the model

Element references in the schemas enforces approved names


GOAL #1: CIEM Controlled Vocabulary

Why?

Without a consistent naming strategy, people who define an object will lose control of the names by which that object is known

Benefits

Increases understanding of what the data represents

Promotes collaboration and communication

Accelerates system design, development and integration

Code can be defined once and reused

OTM uses XML Schema element references to assure the object name is used whenever the object is used

Without this structure, we lose the benefits of everyone speaking the same “language”

Simplifies namespaces in XML messages (as described later)


GOAL #2: Embody OpenTravel Schema Design Patterns

The OpenTravel Model (OTM) embodies and enhances OpenTravel’s established practices

for schema architecture and design

XML schema constructs

Naming

Enumerations

Repeating Groups

Documentation

Substitutions

Namespaces

Extensions


GOAL #3: Embody OpenTravel Implementation Best Practices

The OpenTravel Model (OTM) embodies and enhances consistent practices for schema implementation

and data exchange between trading partners

Message Exchange Patterns

Service Architectures (SOAP and REST)

Transaction Initiator/ Authentication

Encryption

Data Policies

Code Lists


OpenTravel Schema Design Patterns and

Implementation Best Practices

Embodying best practices in the OpenTravel Model (OTM) and development environment makes it easier to create sophisticated schemas

The consistency and design makes it easier to write and reuse code that implement those schemas

2.0 Design Patterns and Implementation Best Practices

Are developed from real-world implementations and application knowledge the complexity of information needed in the travel industry

the broad range of 1.0 messages

Based on modern object-oriented tools bind code to schemas Object-oriented information objects

Encourages service oriented development

Supports REST and WSDL/SOAP Service Oriented Architectures

Provide a more direct communication between model designer and application developer


Design Pattern: Namespaces

Allow developers to track and manage

their application while updating and

extending services

Namespaces distinguish

Messages from reusable types

OpenTravel from Implementer Content

Versions

One Namespace = One Java Package

Once defined in a namespace the object

remains the same

Allows extensions to be used or ignored

Allows code to be reused

One Namespace = One Package


Design Pattern: Namespaces & Element References

Using element references to preserve the namespace of complex data

elements makes it easier to understand an XML message

OTM pattern is to make all complex objects global

Enables types to be defined consistently and reused

References to complex objects are by element reference

Enforces controlled vocabulary goals

Overcomes limitation of namespace specification (see example)

<Card effective="0412" type="A">

<ons:expire>expire</ons:expire>

<ons:holder>holder</ons:holder>

<ons:Issuer>Issuer</ons:Issuer>

</Card>

<Card effective="0412" type="A">

<expire>expire</expire>

<holder>holder</holder>

<Issuer>Issuer</Issuer>

</Card>

Why are card and its children in different

namespaces? Because of type reference.

OTM element reference assures parent and

children are in same namespace.


Design Pattern: Naming Conventions

Naming conventions support modular objects, consistently named

across many different services and messages while minimizing

XML file sizes Name your object for the real-world item it represents

Use Camel Case

Avoid compound words because they may

Make XML data larger without improving understanding

Describe multiple objects that will be more reusable if separated

Item Case Compound Word

Attribute lowerCamelCase Permitted

Element UpperCamelCase Permitted

Simple Type UpperCamelCase Discouraged

Simple Complex Type UpperCamelCase Discouraged

Core Complex Type UpperCamelCase Discouraged

Business Complex Type UpperCamelCase Discouraged


Design Pattern: Optional Elements

OTM design patterns provide design alternatives to “optional

elements”

Optional elements make it harder to understand what will be in a

message and complicate application design

While we can never eliminate optional elements,

OTM provides key alternatives:

Objects with multiple levels of detail allowing each level to

Mandate more properties

Act as a “contract” about what must be present

Customize levels specifying requirements of specific object usage

Query facets to identify query-able properties

Supporting the query use case without making everything in the object

optional when used as a data container


Design Pattern: Enumeration

To improve the OpenTravel 1.0 practice of using and

maintaining “code lists” (separate from the XML schema):

OTM provides open and closed enumeration objects for code lists

which get compiled directly into the XML Schemas

Using XML schema to describe code lists places them

directly into the developers code

Simplifying development when using tools with code completion

Reducing mistakes

Problems caused by external lists include

Developers may not have access to the lists

Developers must develop custom list handling code


Design Pattern: Roles

“Role” based object names and repeating groups simplify

development and implementation while assuring consistent

naming

• For example: a phone can have roles of: home,

work, mobile

OTM design patterns capture the various “roles” objects can

assume

Enforces consistent set of roles

May be an attribute on a list of repeating core objects


Design Pattern: Documentation

Understanding data objects requires consistent naming

With clear and consistent documentation describing the object, its

usage, examples and equivalents

OTM design patterns include with each object:

Description, developer documentation, reference links

Examples and equivalents

The OTM model

Provides a rich set of documentation elements

Supports development tools are easier to use than XSD Schema

documentation

Generates both human and machine readable documentation


Design Pattern: Substitutability

<Profile_ID Authority="MyCompany">

<ProfileID>123XyZ987</ProfileID>

</Profile_ID>

<Profile Authority="MyCompany">


<Address>3 Brooks Street, Somewhere, CA</Address>

<Name>Name</Name>

<Phone>999-555-1212</Phone>

</Profile>

<Profile_Detail Authority="MyCompany">



<Name>Name</Name>

<Phone>999-555-1212</Phone>

<Remarks>send email with changes</Remarks>

<Contact>Rick or Sally</Contact>

</Profile_Detail>

<Profile_Custom_Web Authority="MyCompany">



<Name>Name</Name>

<Phone>999-555-1212</Phone>

<Remarks>send email with changes</Remarks>

</Profile_Custom_Web>

When you use the object

name, any of these can be

found in a VALID XML file.

Profile_ID

ProfileID

Authority

Profile_Summary

Name

Address

Phone

Profile_Detail

Contact

Remarks

Profile_Custom_Web

Remarks

Just use the object name

whenever possible to allow

flexibility via substitution


Design Pattern: Substitution Groups –

Core Object

Core Object Sub-Group has 4 elements

Core Object SubGrp is head of substitution group

Use Summary and Detail to avoid substitution

Alias Sub-Group has 4 elements

Extension Sub-Group has 4 elements

Where this is in

the schema

This can be in the

data

And this

Core

PhoneSubGrp

Phone

PhoneDetail

PhoneSummary

Alias

TeleSubGrp

Tele

TeleDetail

TeleSummary

Extension

PhoneExSubGrp

PhoneEx

PhoneExDetail

PhoneExSummary


Design Pattern: Substitution Groups –

Business Object Business Object Sub-Group has 6 or more elements

Additional elements for Query and Custom facets

Business Object SubGrp is head of substitution group

Use Identifier, Summary, Detail to avoid substitution

Alias Sub-Group has 6 or more elements

Extension Sub-Group has 6 or more elements

BO SubGrp

BO

BO Identifier

BO Summary

BOID

BO Detail

BOCustom

BOQuery

Where this is in

the schema

This can be in

the data

And this

Alias SubGrp

Alias

Alias Detail

Alias ID

Alias Summary

Alias Identifier

Alias Custom

Alias Query

Extension

Ex SubGrp

Ex ID

Ex

Ex Summary

Ex Identifier

Ex Detail

ExCustom

ExQuery


Design Pattern: Versions

OTM’s versioning practices guide the model

designer on how to change the schemas and

standards to accommodate growth and

changing requirements

While giving the developer and their tools visibility

to the changes

The model includes version number and

scheme

Extension


Design Pattern: Imports and Includes

Modular model design supports team oriented development

and management

Import and include allow for modular development

Include –definitions in the same namespace from another file

Import –definitions from a different namespace in another file

OTM Model simplifies managing the relationships

Managed automatically

You just use the type, the tools will manage the Imports and

includes

Compiler consistently creates schema namespace import and

include


OpenTravel Implementation

Best Practices BONNIE LOWELL

Schema Architect, OpenTravel


Best Practice: Message Exchange Patterns

Two message exchange patterns

Request/ Response

Pull style starts an explicit request for information or

action

Notification

Push style – an unsolicited send of data

ACK (acknowledgement) response optional


Best Practice: Service Architecture

As a standards body, OpenTravel does not dictate web service architectural implementation style

2.0 provides two service naming and operations

Verb-noun naming pattern

REST

SOAP

SOAP: 2.0 Service Operation Verb, Noun, Operation

Verb Noun Service Name Operation Names

Read DemandTicket AirDemandTicket ReadRQ

Read DemandTicket AirDemandTicket ReadRS

Read Fare AirFare ReadRQ

Read Fare AirFare ReadRS


Best Practice: Data Encryption

Data encryption mechanism provided Supports PCI and other privacy

initiatives

Encryption indicator in payload

Repeating built-in included in header of message Xpath to encrypted element

Encryption method

Encrypted value

Encryption warnings in schema documentation

<Developer>Note that is it a best practice to encrypt all account access information using the Encryption element in the message header.</Developer>


Best Practice: Authentication

Multiple levels of

authentication

information

For identifying and

authenticating transaction

initiator ID

Booking Channel

Travel Agency

Airline

Company

Location

Time Zone

Travel Sector


Best Practice: Code Lists

Two methods to exchange code list information (OpenTravel and Third-Party)

Open Enumerations (provided in schema) Code List Metadata

opentravel advisory forum 2012 xml object suite lab

Education

opentravel lab

travel companiesthe

opentravel schema products

parties opentravel libraries

new opentravel schema

xml object suite

changing way xml

xml componentbuilding