OpenTravel Advisory Forum 2012 XML Object Suite Lab
-
Upload
opentravel-alliance -
Category
Education
-
view
2.338 -
download
4
description
Transcript of 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.
2 © OpenTravel Alliance
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>
4 © OpenTravel Alliance
Why 2.0? DAVID MORLEY
Technical Consultant, Marriott International
Chair, OpenTravel Architecture Workgroup
5 © OpenTravel Alliance
Ongoing Challenges for Travel Distribution
The dynamic nature of travel
distribution poses IT design and
development challenges… and
this impacts XML standards.
6 © OpenTravel Alliance
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)
7 © OpenTravel Alliance
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…
8 © OpenTravel Alliance
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.
9 © OpenTravel Alliance
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
Why Should You Implement 2.0?
10 © OpenTravel Alliance
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
Why Should You Implement 2.0?
11 © OpenTravel Alliance
Why Should You Implement 2.0?
#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
12 © OpenTravel Alliance
Why Should You Implement 2.0?
#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)
13 © OpenTravel Alliance
Why Should You Implement 2.0?
#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
14 © OpenTravel Alliance
Why Should You Implement 2.0?
#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)
15 © OpenTravel Alliance
Terminology
BONNIE LOWELL
Specification Architect, OpenTravel
16 © OpenTravel Alliance
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
17 © OpenTravel Alliance
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
18 © OpenTravel Alliance
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
19 © OpenTravel Alliance
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
20 © OpenTravel Alliance
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
21 © OpenTravel Alliance
2.0 OpenTravel Model
Type Builders Constructs Used to Build 2.0 Components
22 © OpenTravel Alliance
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.
23 © OpenTravel Alliance
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
24 © OpenTravel Alliance
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
25 © OpenTravel Alliance
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
26 © OpenTravel Alliance
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
27 © OpenTravel Alliance
2.0 Types 2.0 Components Contained in Libraries and Used to
Construct Services & Service Operations
28 © OpenTravel Alliance
2.0 Type Library
Components
The 2.0 Library is built
from a hierarchy of
XML components….
…let’s take a look!
29 © OpenTravel Alliance
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.
30 © OpenTravel Alliance
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
31 © OpenTravel Alliance
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)
32 © OpenTravel Alliance
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
33 © OpenTravel Alliance
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
34 © OpenTravel Alliance
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
35 © OpenTravel Alliance
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
36 © OpenTravel Alliance
Demo
DAVE HOLLANDER
Enterprise Architect, Sabre Holdings
Co-Chair, OpenTravel Architecture Workgroup
37 © OpenTravel Alliance
Demonstration Goal
Let’s build a new “Journey” service
complete with Schema + WSDL in 5 minutes or less
38 © OpenTravel Alliance
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
39 © OpenTravel Alliance
2.0 Mechanics
DAVE HOLLANDER
Enterprise Architect, Sabre Holdings
Co-Chair, OpenTravel Architecture Workgroup
40 © OpenTravel Alliance
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
41 © OpenTravel Alliance
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
42 © OpenTravel Alliance
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)
43 © OpenTravel Alliance
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
44 © OpenTravel Alliance
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
45 © OpenTravel Alliance
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
46 © OpenTravel Alliance
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
47 © OpenTravel Alliance
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.
48 © OpenTravel Alliance
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
49 © OpenTravel Alliance
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
50 © OpenTravel Alliance
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
51 © OpenTravel Alliance
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
52 © OpenTravel Alliance
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
53 © OpenTravel Alliance
Design Pattern: Substitutability
<Profile_ID Authority="MyCompany">
<ProfileID>123XyZ987</ProfileID>
</Profile_ID>
<Profile Authority="MyCompany">
<ProfileID>123XyZ987</ProfileID>
<Address>3 Brooks Street, Somewhere, CA</Address>
<Name>Name</Name>
<Phone>999-555-1212</Phone>
</Profile>
<Profile_Detail Authority="MyCompany">
<ProfileID>123XyZ987</ProfileID>
<Address>3 Brooks Street, Somewhere, CA</Address>
<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">
<ProfileID>123XyZ987</ProfileID>
<Address>3 Brooks Street, Somewhere, CA</Address>
<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
54 © OpenTravel Alliance
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
55 © OpenTravel Alliance
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
56 © OpenTravel Alliance
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
57 © OpenTravel Alliance
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
58 © OpenTravel Alliance
OpenTravel Implementation
Best Practices BONNIE LOWELL
Schema Architect, OpenTravel
59 © OpenTravel Alliance
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
60 © OpenTravel Alliance
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
61 © OpenTravel Alliance
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>
62 © OpenTravel Alliance
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
63 © OpenTravel Alliance
Best Practice: Code Lists
Two methods to exchange code list information (OpenTravel and Third-Party)
Open Enumerations (provided in schema) Code List Metadata