OpenTravel Advisory Forum 2012 XML Object Suite Lab

2012 North American Advisory Forum (Miami  Florida  April 2012)

LAB PRESENTATION

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

1 © OpenTravel Alliance

2012 North American Advisory Forum (Miami  Florida  April 2012)

Lab Facilitators
DAVID MORLEY, Technical STEVE LIVEZEY, Enterprise
Consultant, Marriott Services Technology, Sabre
International (moderator) Holdings

DAVE HOLLANDER, STUART WALDRON,
Enterprise Architect, Sabre Information Technology
Holdings Architect, Amtrak

BONNIE LOWELL, Specification Architect, OpenTravel


2012 North American
Advisory Forum
Miami, Florida

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

<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

OpenTravel 2.0 Development Environment

Model Development Tool User OpenTravel
Interface OTM Publication
Model
WSDL
Compiler
Schema
Included Examples
Library
XSD


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
Service Operation Patterns
specified in Web Services
• Request
Description Language (WSDL)
• Response
format
• Notification
• Implementer extensible
• Have Equivalents
• Have Service
Operations
• OTM compiler produces trimmed
schema

Services
Simple Types

Business Objects
Core Components
Open Enumerations

Value with Attributes
Closed Enumerations
X
X
X
Simple

X
X

X
Complex

X
X
X
X
Base XML Atomic Type

X
Base Simple Type

X
Base Enumeration

X
Constraining Facets

X
X
Literal Values

X
X

X
Implementer Extensible

X
X
X
X
X
X

X
Documentation

X
X

X Example(s)

Attribute Collection
Summary

Element Collection
X

Indicator Collection
X

Simple Form
X

ID Facet
X

X

Summary Facet
X

X

Detail Facet
35
X

Query Facet
X

Custom Facet
X
X
X
X
X
X

Equivalent(s)
X

X

Alias(es)
X

Role(s)
© OpenTravel Alliance

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  Create Journey Object
 Use tree filters  Flight, Profile, Hotel,
 Expose children of Profile HotelType
 Examine Service Example  Create Service Operations
data  Compile
 Create Journey Library  Examine Results
 Create Extensions  Model schema
 Extend Phone  Service description
 Add a “preferedName”
 Generated Examples
 Define extension point for
 Create Java classes
Profile_Summary
 Add a “cvs” attribute


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 One Namespace = One Package
 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


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)

Why are card and its children in different OTM element reference assures parent and
namespaces? Because of type reference. children are in same namespace.

<Card effective="0412" type="A"> <Card effective="0412" type="A">
<ons:expire>expire</ons:expire> <expire>expire</expire>
<ons:holder>holder</ons:holder> <holder>holder</holder>
<ons:Issuer>Issuer</ons:Issuer> <Issuer>Issuer</Issuer>
</Card> </Card>


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">
When you use the object <ProfileID>123XyZ987</ProfileID>
name, any of these can be </Profile_ID>
found in a VALID XML file.
<Profile Authority="MyCompany">
<ProfileID>123XyZ987</ProfileID>
Profile_ID <Address>3 Brooks Street, Somewhere, CA</Address>
ProfileID <Name>Name</Name>
Authority <Phone>999-555-1212</Phone>
</Profile>
Profile_Summary
Name <Profile_Detail Authority="MyCompany">
Address <ProfileID>123XyZ987</ProfileID>
Phone <Address>3 Brooks Street, Somewhere, CA</Address>
Profile_Detail <Name>Name</Name>
Contact <Phone>999-555-1212</Phone>
Remarks <Remarks>send email with changes</Remarks>
<Contact>Rick or Sally</Contact>
</Profile_Detail>
Profile_Custom_Web
Remarks <Profile_Custom_Web Authority="MyCompany">
<ProfileID>123XyZ987</ProfileID>
<Address>3 Brooks Street, Somewhere, CA</Address>
<Name>Name</Name>
Just use the object name <Phone>999-555-1212</Phone>
whenever possible to allow <Remarks>send email with changes</Remarks>
</Profile_Custom_Web>
flexibility via substitution


Design Pattern: Substitution Groups – PhoneExSubGrp
Core Object
PhoneExSummary
 Core Object Sub-Group has 4 elements
PhoneEx
 Core Object SubGrp is head of substitution group
 Use Summary and Detail to avoid substitution
PhoneExDetail
 Alias Sub-Group has 4 elements
 Extension Sub-Group has 4 elements Extension

PhoneSubGrp
Where this is in TeleSubGrp
the schema
PhoneSummary TeleSummary
This can be in the Phone Tele
data

PhoneDetail TeleDetail
And this
Core Alias


Ex SubGrp
Design Pattern: Substitution Groups –
Ex ID
Business Object
Ex Identifier
 Business Object Sub-Group has 6 or more elements
Ex
 Additional elements for Query and Custom facets
Ex Summary
 Business Object SubGrp is head of substitution group
 Use Identifier, Summary, Detail to avoid substitution
Ex Detail
 Alias Sub-Group has 6 or more elements ExCustom
 Extension Sub-Group has 6 or more elements ExQuery Extension

Alias SubGrp
BO SubGrp

BOID Alias ID
Where this is in
the schema BO Identifier Alias Identifier

Alias
BO
This can be in
BO Summary Alias Summary
the data

BO Detail Alias Detail
And this BOCustom Alias Custom

BOQuery Alias Query

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

Recomendados

Recomendados

Mais conteúdo relacionado

Destaque

Destaque (6)

Semelhante a OpenTravel Advisory Forum 2012 XML Object Suite Lab

Semelhante a OpenTravel Advisory Forum 2012 XML Object Suite Lab (20)

Último

Último (20)

OpenTravel Advisory Forum 2012 XML Object Suite Lab